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

Status: RESOLVED FIXED

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

Description

[Justin Wood (:Callek)]

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"

    [[e-mail] panda-0291]$ nc -vz blobupload.elasticbeanstalk.com 443
    nc: connect to blobupload.elasticbeanstalk.com port 443 (tcp) failed: Connection timed out
     
    [[e-mail] ~]$ nc -vz blobupload.elasticbeanstalk.com 443
    nc: connect to blobupload.elasticbeanstalk.com port 443 (tcp) failed: Connection timed out
     
    [[e-mail] ~]$ nc -vz blobupload.elasticbeanstalk.com 443
    Connection to blobupload.elasticbeanstalk.com 443 port [tcp/https] succeeded!

Comment 1

[Dustin J. Mitchell [:dustin] (he/him)]

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

Comment 2

[Dave Curado :dcurado]

working on this

Comment 3

[Dave Curado :dcurado]

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]

Comment 4

[hwine]

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?

Comment 5

[Dave Curado :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.