Change Details

Currently we are running JunOS 20.4R3 on our EVPN switches in Eqiad rows E and F. We have one identified bug on 20.4, by which routed VXLAN overlay packets (i.e. those arriving to the VTEP IP with the inner MAC set to [[ https://datatracker.ietf.org/doc/html/rfc9135#name-evpn-routers-mac-extended-c | router MAC ]] of the switch, requiring a local IP lookup to find ultimate destination), are dropped unless there is an IRB interface on the local system in an "up" state. As soon as we've one server connected to a switch this condition is met, and things work as expected. Previously Juniper stated this was normal behaviour, after a lengthy TAC case, but it seems this limitation does not apply to 22.2 which we are using in codfw. Once we've have some servers moved in codfw and wait a few weeks to confirm everything is stable we should start planning to upgrade the eqiad devices to 22.2 to match.

Currently we are running JunOS 20.4R3 on our EVPN switches in Eqiad rows E and F. We have one identified bug on 20.4, by which routed VXLAN overlay packets (i.e. those using a L3VNI tied to a routing instance rather than L2VNI tied directly to a Vlan) are dropped unless there is an IRB interface on the local system in an "up" state. As soon as we've one server connected to a switch this condition is met, and things work as expected. Previously Juniper stated this was normal behaviour, after a lengthy TAC case, but it seems this limitation does not apply to 22.2 which we are using in codfw. Once we've have some servers moved in codfw and wait a few weeks to confirm everything is stable we should start planning to upgrade the eqiad devices to 22.2 to match.

Currently we are running JunOS 20.4R3 on our EVPN switches in Eqiad rows E and F. We have one identified bug on 20.4, by which routed VXLAN overlay packets (i.e. those arriving to the VTEP IP with the inner MAC set to [[ https://datatracker.ietf.org/doc/html/rfc9135#name-evpn-routers-mac-extended-c | router MAC ]] of the switch, requiring a local IP lookup to find ultimate destination),using a L3VNI tied to a routing instance rather than L2VNI tied directly to a Vlan) are dropped unless there is an IRB interface on the local system in an "up" state. As soon as we've one server connected to a switch this condition is met, and things work as expected. Previously Juniper stated this was normal behaviour, after a lengthy TAC case, but it seems this limitation does not apply to 22.2 which we are using in codfw. Once we've have some servers moved in codfw and wait a few weeks to confirm everything is stable we should start planning to upgrade the eqiad devices to 22.2 to match.