lisp pubsub diagnosis & t/s

[andy!doesnt!like!uucp]

team
please share any relevant source which would include diagnosis of the dynamic border from the edge node perspective (i.e. identify preferred BN for L2 or L3 VN, identify tunnel carrying external to fabric traffic etc) ....
thanks

[jedolphi]

Andy, please review these two presentations and then I'll try to respond to any outstanding questions you might have,

https://www.ciscolive.com/on-demand/on-demand-details.html?#/session/1686177770252001VXxo
https://www.ciscolive.com/on-demand/on-demand-library.html?#/session/1675722400509001tOYW

[andy!doesnt!like!uucp]

Hi Jerom
from what i derived from docs there is only way to verify which BN is in use is to use "sho ip cef <prefix> vrf <VN>".
in our case we have 2 BNs & i can see in output both of them

EN0010#show ip cef vrf ENTERPRISE_VN 10.XX.1.YY de
10.0.0.0/9, epoch 0, flags [subtree context, check lisp eligibility], per-destination sharing
SC owned,sourced: LISP remote EID - locator status bits 0x00000000
LISP remote EID: 116934 packets 42241054 bytes fwd action encap
LISP source path list
nexthop 10.XYZ.0.1 LISP0.4099
nexthop 10.XYZ.0.2 LISP0.4099
2 IPL sources [no flags]
nexthop 10.XYZ.0.1 LISP0.4099
nexthop 10.XYZ.0.2 LISP0.4099

does it mean that we cannot say which BN terminates active VXLAN tunnel?
thanks

UPD. after reading i have little bit more Qs like "how 2 external/anywhere BNs synchronize their switching to remote BNs for internet termination when they lose their local internet breakouts one by one?" etc. But it's different story...

[jalejand]

Unfortunately, CEF next hop hashing is just the software side of things, even using "exact route" will not give you the exact hashing for a specific traffic flow, as that depends on the equal-cost routing implementation in each hardware platform.

There was a command for cat9k that was like "show pla hard fed sw active forward exact-route..." that can provide a more accurate result when it comes to hashing. Other than that, doing an EPC capture in each  egress underlay port can give you the encapsulation details of which border was elected

[andy!doesnt!like!uucp]

ok... is there any mean to manipulate of the PETR "preference" from the Edge Node perspective within LISP-router configuration?

[jedolphi]

Yes, for the whole Fabric Site, not per Edge Node. In the SDA UI, on each Border Node, you can adjust the LISP Priority. If you change BN1 to LISP Priority 9 and leave BN2 as default (10), then BN1 will always be preferred over BN2. Regards, Jerome

[andy!doesnt!like!uucp]

Hi Jerom
what is tiebreaker if priorities are equal between 2 BNs? Or VXLAN-traffic just gets pinned to arbitrary BN based on the src-dst hash calculated & are the inner or outer src-dst used for hash?

Thanks

[jalejand · Accepted solution]

When a FE needs to encapsulate to a Border in VXLAN, the load balancing algorithm takes the inner header information (src-dst), it can either take BNx or BNy.

[andy!doesnt!like!uucp]

is it the same for the L2-handoff traffic? we have a deployment with 2 BNs each both L3&L2-handoff, but whilst for L3-handoff both BNs are able to forward traffic from/to fabric site for the L2-handoff (gateway outside the fabric) only one of them is active at a time for VXLAN-to-L2 switching & vice versa. My concern is if EN hashes L2 traffic to L2-standby BN such a traffic gets dropped bc there is no L2-switching path for the L2VNs between BNs.

[jalejand]

Overlay load balancing does not exist in L2 traffic, as one MAC registered by different ETRs is considered "mac-move". A destination MAC will always take the unicast routing path to the RLOC registering that MAC. 

There should not be a reason for the Fabric Edge to send traffic to the L2 "standby" BN in the first place (and if there it is, then we are talking about a L2 loop or a failure on duplicate address detection mechanisms in SD-Access).

[andy!doesnt!like!uucp]

true. i should think about default gw's MAC for out-of-fabric traffic gets registered only by Active L2-h/o BN. shame...