Closed Bug 1013029 Opened 8 years ago Closed 8 years ago

Foopies in panda-pods in scl3 need to be able to access elastic beanstalk

Categories

(Infrastructure & Operations :: NetOps: DC ACL Request, task)

x86_64
Windows 7
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Callek, Assigned: dcurado)

References

Details

So, this is scraped from IRC convo. Apparantly foopies in the migrated panda pod (*.p3) are no longer able to upload to elastic beanstalk (used for blobber).

I'm unsure where the ACL's live or even when the ACL's in the first place were added, but I wanted to get this documented in a bug in the "most likely place"

    [cltbld@foopy55.p3.releng.scl3.mozilla.com panda-0291]$ nc -vz blobupload.elasticbeanstalk.com 443
    nc: connect to blobupload.elasticbeanstalk.com port 443 (tcp) failed: Connection timed out
     
    [cltbld@foopy59.p3.releng.scl3.mozilla.com ~]$ nc -vz blobupload.elasticbeanstalk.com 443
    nc: connect to blobupload.elasticbeanstalk.com port 443 (tcp) failed: Connection timed out
     
    [cltbld@foopy45.p1.releng.scl1.mozilla.com ~]$ nc -vz blobupload.elasticbeanstalk.com 443
    Connection to blobupload.elasticbeanstalk.com 443 port [tcp/https] succeeded!
This was requested for scl1 in bug 928058.

I think there's already an address-set for foopies?  Then this is 

foopies
  ->
    10.134.84.128/27:443/tcp
    10.134.84.160/27:443/tcp
Assignee: network-operations → dcurado
working on this
Status: NEW → ASSIGNED
OK, should be fixed.
Apologies, I missed this policy when translating everything in SCL1 -- because the policy lives
in SCL3, not SCL1.  Doh!  Please let me know if there are any problems, and I'll fix it.
Thanks -- Dave

  From zone: pod, To zone: vpc
  Source addresses:
    any-ipv4: 0.0.0.0/0 
    any-ipv6: ::/0
  Destination addresses:
    blobupload-net: 10.134.84.128/26
  Application: junos-https
    IP protocol: tcp, ALG: 0, Inactivity timeout: 1800
      Source port range: [0-0] 
      Destination port range: [443-443]
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Dave - can you confirm this fix has been applied to all SCL3 panda vlans/pods? Or do I need to open a bug to catch the rest?
Flags: needinfo?(dcurado)
Hi Hal,
First, to answer your question: yes, this fix has been applied to all panda vlans.

Second, there is a "container relationship" that may be useful to know about.
There a bunches of panda hosts or foopies (or whatever they are called) on vlans.
(e.g. vlan p1, vlan p2, etc.)

Those vlans are all part of a "security-zone", called "pod"

Security policies are applied at a security-zone level.
So, when we create a policy like this, it works for all the vlans
in the security zone.
HTHs.
Flags: needinfo?(dcurado)
You need to log in before you can comment on or make changes to this bug.