Routing/Layer3 over vPC

[@tonihimbeer8344]

nice and Short stripped down to the facts video. great troubleshooting commands... thx !

[@BloodyMer]

can you explain more about the drawbacks it has? PIM routing, ARP replys, and so on.

[@orglas]

Hi, thanks for the video. Does this setup support BFD?

[@CiscoSystems]

Hi there, thanks for your question! Yes, this does support BFD. When using vPC, BFD can be configured to monitor the health of the Layer 3 links and ensure rapid detection and failover in case of link failures. This helps in maintaining the stability and reliability of the network. We hope this information helps!

[@aliriozavarce2358]

The reason why n9k-4 absorbs the OSPF packet from from n9k-1 to n9k-3 (frame with destination mac n9k-3 VLAN 10) is because n9k-4 has peer-gateway enabled. Peer-gateway causes n9k-4 to listen for n9k-3’s VLAN 10 MAC address. When n9k-4 strips the Ethernet header and reads the destination IP, it realizes that the IP packet is not destined for itself and it tries to forward the packet to n9k-3; however, since the packet has a TTL of 1, this TTL is decreased by 1 and ultimately discarded.

[@chriscraddock743]

I dont think thats is entirely correct. The reason N9K4 receives the OSPF packet destined for N9K3 is because N9K2's Layer 2 hashing algorithm is load balancing between the two links. Remember, N9K2 believes that it is connected to one logical switch when it reality, it isnt. It doesnt know that N9K3 is only directly reachable via one physical interface, all it knows is that it has a single logical port channel interface made up of 2 links to forward packets/frames to. When N9K4 receives the OSPF packet that is destined for the VLAN 10 SVI MAC of N9K3, it decrements the TTL to 0 and has no choice but to drop the packet. The peer gateway command simply allows the vpc peers to forward traffic out other ports on behalf of its peer, negating the need to forward those frames over the vPC peer link instead.

[@aliriozavarce2358]

@@chriscraddock743 Yes, you’re right about why N9K-4 receives a frame destined to N9K-3. N9K-1’s port channel algorithm sends that frame to N9K-4 even though is destined to N9K-3. What I explained was the reason why N9K-4 “absorbs” the frame when the frame is destined to N9K-3, and that’s because of the peer-gateway feature. Peer gateway allows a switch to “impersonate” its peer by also listening for destination mac addresses that belong to that peer. Once N9K-4 absorbs that frame targeted to N9K-3 and strips off the Ethernet header, N9K-4 can route the packet to its destination. In the case of control plane traffic like OSPF, those packets have a TTL of 1, so to prevent the switch from decrementing it to 0 and discarding the packet, the layer3 peer-router feature must be enabled. That way, if N9K-4 receives a routing update for N9K-3 because N9K-1’s hashing algorithm decided to send the update through the link connected to N9K-4, N9K-4, after stripping the Ethernet off, doesn’t decrement the TTL from 1 to 0 and forwards the OSPF update packet out to multiple interfaces in the case of multicast or the peer link interface in the case of unicast.

[@ciN713]

Do you see any additional challenges with four switches? Looking to connect two 9k's to two 7710's with OSPF and Vlan trunking.

[@justinwilliams9377]

Hello, thank you for this video! It came just as I am working on this.

[@scottjohnson4031]

You should explain in the video that vlan 10 is on the interfaces PO10 on N9k-2 (eth1/3, 1/6) and on Eth1/1 on both N9k-1/2 otherwise people will not understand how N9k1 is able to even talk to 3 and 4 for an ospf adjacency.