L2Flooding setup

[Sylvain_Che]

Hello,

When enabling L2Flooding, Underlay ASM must be configured either via LAN Automation or manually.

Whatever the method used, MSDP and a Loopback60000 used as Anycast-RP should be configured on redundant Border nodes. This is documented in various places and I've been able to see this in a lab environment.

Now in my production SDA environment (which was setup before I joined the company) where L2Flooding is enabled on some segments and where LAN Automation is used, strangely there is no Loopback60000 nor MSDP configured on the Border nodes. Fabric Edges have a RP address configured which points to the L2Border Lo0 IP address.

I don't understand where this setup comes from. Any idea?

Also, if this L2Border fails, my understanding is that L2Flooding within the infra will break and cause an impact to the endpoints located in L2Flooding-enabled segments. So I'd like to manually configure MSDP & Lo60000 on redundant Border nodes and migrate the RP-Address configured on Fabric Edges to point to the Anycast-RP address. Does it make sense? What would be the impact of this migration?

Thanks for your help.

Regards,

Sylvain.

[andy!doesnt!like!uucp]

the corner stone here is your L2-handoff BN which currently is RP as well. if it fails your L2VNIs will fail to communicate with external L2 domains. Then you need to equip your redundant BNs with both anycast RP, MSDP & L2-handoffs. It may be challenging because u would want to have new architecture for L2-handoff implementing Active/Standby mode. Meaning that your Standby L2-handoff shouldnt learn EIDs from external L2-domains until Active L2BN goes dead. I still believe the best approach is to have your current L2BN to be stackwise switch w/ 2 members. 

[jalejand · Accepted solution]

- I don't understand where this setup comes from. Any idea?

Chances are that the L2Handoff Border was the first device configured as seed + multicast enabled for a lan automation task, which resulted in this configuration (or manually configured), nonetheless,  It is fair to think on adding the RP as redundant on the L3 Borders is a good choice.

Does it make sense? What would be the impact of this migration?
If the RP/L2 Border fails, new PIM trees will not be able to be formed of course, already established S,G trees will be maintained though. If you have intermediate nodes then even better, very likely these will be the SPT tree/path.

Migrating the RP from one node to another might cause an interruption in some ASM related flows which are purely L2 flooding (unknown unicast, ARP flood based resolution, broadcast and link local multicast services).

The following things can be configured without impact:
Lo60000 in both L3 borders, ISIS/IGP announcement of this, PIM enablement, etc.
MSDP between L3 borders, using Lo0 as peer IP/connect-source/originator.

And finally the last step which can cause a bit of interruption:
RP change in all L3 nodes in the network: Borders, Intermediate nodes and Edges.

Regards

[Sylvain_Che]

Thanks for this answer. This is exactly what I was looking for.