Hej,
Czy ktoś z Was spotkał się może z problemem że QFX5100 wypakowując ruch z tunelu VTEP analizuje TTL pakietu wewnątrz tunelu i dropuje pakiety z TTL=1 ? I co ciekawe - tylko pakiety multicastowe. Ruch unicast udp/tcp leci poprawnie w ramach VXLAN nawet z TTL=1.
Ścieżka ruchu wygląda tak:
LEAF1 -> SPINE -> LEAF2
(to uproszczenie, bo mamy jeszcze sygnalizację evpn która leci do MXów, ale to raczej nie ma znaczenia w tym przypadku, gdyż temat nie dotyczy sygnalizacji control-plane, tylko - moim zdaniem - niepoprawnego działania data plane).
Ruch dociera do LEAF2, trafia w interfejs VTEP, po czym jest dropowany (nie jest wysyłany do serwera docelowego).
Wygląda mi to na jakiś błąd w obsłudze ścieżki ruchu, ale JTAC zanim się wypowie to pewnie jeszcze trochę minie, a może ktoś już dotknął tego problemu i zna rozwiązanie.
pozdr.,
Paweł
QFX5100 + EVPN + VXLAN + Multicasty
Re: QFX5100 + EVPN + VXLAN + Multicasty
Odpowiem sobie sam może komuś sie przyda. Okazało się, że problem dotyczył całego ruchu z TTL=1 (nie tylko multicastów).horhe358 pisze:Hej,
Czy ktoś z Was spotkał się może z problemem że QFX5100 wypakowując ruch z tunelu VTEP analizuje TTL pakietu wewnątrz tunelu i dropuje pakiety z TTL=1 ? I co ciekawe - tylko pakiety multicastowe. Ruch unicast udp/tcp leci poprawnie w ramach VXLAN nawet z TTL=1.
Ścieżka ruchu wygląda tak:
LEAF1 -> SPINE -> LEAF2
(to uproszczenie, bo mamy jeszcze sygnalizację evpn która leci do MXów, ale to raczej nie ma znaczenia w tym przypadku, gdyż temat nie dotyczy sygnalizacji control-plane, tylko - moim zdaniem - niepoprawnego działania data plane).
Ruch dociera do LEAF2, trafia w interfejs VTEP, po czym jest dropowany (nie jest wysyłany do serwera docelowego).
Wygląda mi to na jakiś błąd w obsłudze ścieżki ruchu, ale JTAC zanim się wypowie to pewnie jeszcze trochę minie, a może ktoś już dotknął tego problemu i zna rozwiązanie.
pozdr.,
Paweł
Jest to ograniczenie Broadcom-owego Trident-a II na którym zbudowany jest qfx5100. Trident II pakiety z TTL=0 lub 1 wyrzuca z przetwarzania do routing-engine-u, który z kolei przetwarza to w ścieżce pakietów kierowanych do RE (czyli w szczególności przez filtry). A że filtry bezpieczeństwa na Lo0 blokowały taki ruch tranzytowy (bo nie powinien on w ogóle dotykać RE) pakiety były dropowane. Obejściem problemu jest przepuszczenie w filtrach do RE pakietów z ttl=1 na port udp 5001 (vtep/vxlan) - i ruch wtedy jest obsługiwany prawidłowo.
pozdr.,
Paweł