EVPN connectivity breaks while using MX100003 as core where the customer is providing L2 services to their client running SDWAN. The same setup work on MX960 as core.

customer was migrating from MX960 running in Junos release 18.3 to MX10003 running in Junos version 21.4 and as an initial migration phase of single homed MX960 to multihomed MX10003 router he was unable to achieve the EVPN connectivity between remote PE devices ( MX960 and MX10003-1 and MX10003-2).

The MAC address is learned in Source PE (MX960) and its not getting reflected in remote PE ( MX10003).

Customer was running EVPN-Virtual switch instance type where no L3 will be learned on the DCI routers only L2 services were offered to his customer using these core routers.



In the EVPN-MPLS scenario, if router-id is not configured, after changing any configuration on the router, EVPN Type 3 (Inclusive Multicast Ethernet Tag route) routes are advertised with an invalid Ingress Replicator IP 0.0.0.0, the receiving PE will ignore these Type 3 routes and do not create dummy Egress-IM routes in mpls.0 table for that PE. This will result in Layer 2 Address Learning Daemon (L2ALD) not creating the mesh-group flood routes for the remote PE, causing all BUM packets to be dropped locally.

The following command could be used to check the EVPN type 3 route details:
root@device> show route table evpna.evpn.0 match-prefix "X:X:X::XXX::X.X.X.X" extensive

evpna.evpn.0: 4 destinations, 7 routes (4 active, 0 holddown, 0 hidden)
X:X:X::XXX::X.X.X.X/248 IM (1 entry, 1 announced)
        *EVPN   Preference: 170
                Next hop type: Indirect, Next hop index: 0
                Address: 0xXXXXXXX
                Next-hop reference count: 11
                Protocol next hop: X.X.X.X
                Indirect next hop: 0x0 - INH Session ID: 0
                State: <Active Int Ext>
                Age: 1w0d XX:XX:XX
                Validation State: unverified
                Task: evpna-evpn
                Announcement bits (1): 2-rt-export
                AS path: I
                Route Label: XXXXX
                PMSI: Flags 0x0: Label XXXXX: Type INGRESS-REPLICATION 0.0.0.0  <<<< this is not expected
                Thread: junos-main

Further investigation revealed that MX960 did not have the router-id defined under the routing-options. In the absence of the router-id definition , there was software defect in the code flow leading to the replicator IP getting set to 0.0.0.0 during the certain sequence of configuration changes. PR1576943 provides a fix to ensure that TYPE 3 route will never have Replicator IP set to 0.0.0.0 even in the absence of the router-id configuration. Hence the flood tokens were not generated due to this value.

To configure router-id on the routers running 18.3 and below , hence the remote PE router wil receive the Type 3 router with PMSI attribute set with router-id of remote router for any specific VLAN related Type 3 prefix. This route is further needed by L2ALD for creating the branches of the flood token.

Command :

set routing-options router-id X.X.X.X

This reported issue is resolved in below releases

Resolved-In

evo:20.4R3-S4-EVO evo:21.2R2-EVO evo:21.2R3-EVO evo:21.3R2-EVO evo:21.4R1-EVO junos:20.4R3-S4 junos:21.1R3-S3 junos:21.2R2 junos:21.2R3 junos:21.3R2 junos:21.4R1

Ref case - 2023-0920-773569

Related PR -1576943

https://prsearch.juniper.net/problemreport/PR1576943