Încercam să-mi dau seama de ceva vreme. Așa că acum îmi încerc norocul aici...
Am câteva VM-uri care ar trebui să comunice cu non-VM-uri. Există 2 cazuri de utilizare.
Primele sunt BareMetal Machines de pe subrețeaua pe care se află routerul extern. Al doilea sunt mașinile din afara și din spatele porții către care se adresează routerul extern.
Deci avem aceste două căi de conexiune:
VM --> gateway de router extern --> gateway de internet --> gateway în altă parte --> altă mașină de pe această subrețea
VM --> router extern gateway --> internet gateway --> baremetal machine pe această subrețea
Deci, pentru a-l face și mai vizual: routerul extern va avea gateway-ul, de exemplu, la 10.5.1.10, iar serverul la care trebuie să ajungă se află la 10.5.1.80.
Deci totul este bine până acum, pachetele curg, dar nu toate. Și aici devine ciudat și caut motivul.
Deci, aceste VM rulează kubernetes și ar trebui să se conecteze la alte mașini baremetal de pe acea subrețea. Rețeaua care rulează este calico, așa că pachetele BGP sunt transferate.Lucrul ciudat este că acele pachete nu ajung niciodată la mașinile baremetal, dar se descurcă bine cu mașinile din afara subrețelei de routere externe. Așa că m-am uitat în date și am observat că pachetele deja dispar pe hypervisorul VM. Ele sunt încă vizibile pe dispozitivul de atingere, dar după aceea sunt doar pierdute.
Deci este destul de evident, ceva filtrează acele pachete. Întrebarea rămâne acum: de ce? Am o configurație greșită, am înțeles ceva greșit? Sau există o modalitate de a face ca întreaga configurație să înghită acele pachete? Am avut problema asta. tot cu pachete de flanel vxlan... .
Configurația mea în general este: openstack prin kolla, openvswitch, rețeaua externă este configurată ca rețea plată.
Am verificat regulile iptable, dar nu există reguli deloc pentru subrețea. Și așa cum s-a descris mai înainte, pachetele care sunt direcționate nu către rețeaua 10.5.0.0/16, ci de exemplu către rețeaua 10.50.0.0/16 care se află în afara acestui centru de date și este necunoscut pentru openvswitch/openstack. Deci asta are de-a face cu rețeaua externă configurată pe 10.5.0.0/16, care elimină acele pachete în mod ilegal.
Mai multe informatii:
Aceasta este interfața mașinii virtuale afișată de ovs-vctl.
Port qvo503122c8-15
etichetă: 1
Interfață qvo503122c8-15
Punând tcpdump pe asta
tcpdump -i qvo503122c8-15 -vvv | grep bgp
tcpdump: ascultare pe qvo503122c8-15, tip link EN10MB (Ethernet), dimensiunea capturii 262144 octeți
Rezultă absolut nimic. Dar comunicarea în general este vizibilă acolo. Privind dispozitivul principal, sunt încă acolo
tcpdump -i qbr503122c8-15 -vvv | grep bgp
tcpdump: ascultare pe qbr503122c8-15, tip link EN10MB (Ethernet), dimensiunea capturii 262144 octeți
10.5.3.44.53969 > 10.15.0.91.bgp: steaguri [S], cksum 0x17b7 (incorectă -> 0x0748), seq 607368, win 64860, opțiuni [mss 1410,sack 1410,sack,sac 4219383867 val 42193867 , lungime 0
10.5.3.44.41505 > 10.15.0.92.bgp: steaguri [S], cksum 0x17b8 (incorectă -> 0x572f), seq 103292561, win 64860, opțiuni [mss 1410, TS4040, 4567, TS40, 4567] , lungime 0
10.5.3.44.53969 > 10.15.0.91.bgp: steaguri [S], cksum 0x17b7 (incorect -> 0xff67), seq 607368, win 64860, opțiuni [mss 1410,sack 1410,sack 0x17b7, TS967621OK] , lungime 0
10.5.3.44.49645 > 10.15.0.91.bgp: steaguri [S], cksum 0x17b7 (incorect -> 0xb20c), seq 137205467, win 64860, opțiuni [mss 1410, TS6720c, tsc7170, TS67071, TS67070, , lungime 0
10.5.3.44.49787 > 10.15.0.92.bgp: steaguri [S], cksum 0x17b8 (incorectă -> 0x9dee), seq 608997803, win 64860, opțiuni [mss 1410, 625367, TS 1410, 625367, 0x9dee] , lungime 0
Pentru comparație, aceeași mașină, diferită VM, are și ea aceeași problemă și acele pachete dispar, dar în acest caz există unele mașini în afara aceluiași centru de date. Și acestea sunt atinse foarte bine pe subrețeaua lor. Pachetele înregistrate aici nu vor dispărea:
tcpdump -i qbr2d9b68d1-b7: -vvv | grep bgp
tcpdump: ascultare pe qbr2d9b68d1-b7:, tip link EN10MB (Ethernet), dimensiunea capturii 262144 octeți
192.168.1.3.58395 > 10.5.0.177.bgp: steaguri [P.], cksum 0x0961 (corect), seq 2080765188:2080765207, ack 2634444892, opțiunile 2634444892, opțiunile 81765189, 81 TS 9253, 81 TS 929 653 : BGP
10.5.0.177.bgp > 192.168.1.3.58395: steaguri [.], cksum 0xcc82 (incorect -> 0x44c4), secv 1, ack 19, win 502, opțiuni [nop,nop,TS val 2587187, TS val 2587187]
Totuși, un lucru pe care îl pot vedea acum: al doilea tcpdump arată că VM-ul comunică cu exteriorul prin propria sa adresă. În timp ce ceilalți încercau să comunice cu ip-ul plutitor. Pachetele IP plutitoare par a fi filtrate.
