Accepted Solutions
Hi @Maurlai,
The IPN links are used Active/Active for the different traffic flows.
For Unicast traffic crossing the IPN:
Cisco Nexus 9000 Series Switches implement VXLAN in the way that a hash of the inner frame’s header is used as the VXLAN source UDP port. As a result, a VXLAN flow can be unique, with the IP addresses and UDP ports combination in its outer header while traversing the underlay transport network. Therefore, the hashed source UDP port introduces a desirable level of entropy for ECMP (Equal Cost Multi Path) which allows the Routing Table on each hop to leverage a different link depending on this hash.
As a note, VXLAN tunnels are end-to-end in Multi-Pod (i.e. from Leaf in Pod 1 to Leaf in Pod 2).
Conclusion: This is the default and expected behavior.
Link: VXLAN Overview: Cisco Nexus 9000 Series Switches
For Multicast traffic crossing the IPN:
An important design consideration should be made for the deployment of the Rendezvous Point (RP) in the IPN network. The role of the RP is important in a PIM Bidir deployment, as all multicast traffic in Bidir groups vectors toward the bidir RPs, branching off as necessary as it flows upstream and/or downstream. This implies that all the BUM traffic exchanged across Pods would be sent through the same IPN device acting as RP for the 225.0.0.0/15 default range used to assign multicast groups to each defined Bridge Domain. A possible design choice to balance the work load across different RPs consists in splitting the range and configure the active RP for each sub-range on a separate IPN devices, as shown in the simple example in the next Figure:
Conclusion: The strategy is to manually assign the Active RP role to all the IPN Routers involved for every "subnet" of the 225.0.0.0/15 default range. At the same time, the non-Active RPs for the subnets should follow the Phantom RP approach for redundancy.
Link: ACI Multi-Pod White Paper
HTHs
Hi @Maurlai,
The IPN links are used Active/Active for the different traffic flows.
For Unicast traffic crossing the IPN:
Cisco Nexus 9000 Series Switches implement VXLAN in the way that a hash of the inner frame’s header is used as the VXLAN source UDP port. As a result, a VXLAN flow can be unique, with the IP addresses and UDP ports combination in its outer header while traversing the underlay transport network. Therefore, the hashed source UDP port introduces a desirable level of entropy for ECMP (Equal Cost Multi Path) which allows the Routing Table on each hop to leverage a different link depending on this hash.
As a note, VXLAN tunnels are end-to-end in Multi-Pod (i.e. from Leaf in Pod 1 to Leaf in Pod 2).
Conclusion: This is the default and expected behavior.
Link: VXLAN Overview: Cisco Nexus 9000 Series Switches
For Multicast traffic crossing the IPN:
An important design consideration should be made for the deployment of the Rendezvous Point (RP) in the IPN network. The role of the RP is important in a PIM Bidir deployment, as all multicast traffic in Bidir groups vectors toward the bidir RPs, branching off as necessary as it flows upstream and/or downstream. This implies that all the BUM traffic exchanged across Pods would be sent through the same IPN device acting as RP for the 225.0.0.0/15 default range used to assign multicast groups to each defined Bridge Domain. A possible design choice to balance the work load across different RPs consists in splitting the range and configure the active RP for each sub-range on a separate IPN devices, as shown in the simple example in the next Figure:
Conclusion: The strategy is to manually assign the Active RP role to all the IPN Routers involved for every "subnet" of the 225.0.0.0/15 default range. At the same time, the non-Active RPs for the subnets should follow the Phantom RP approach for redundancy.
Link: ACI Multi-Pod White Paper
HTHs
