adrian, even if you found the solution already, here is a great reference document:
http://bradhedlund.com/2010/12/16/routing-over-nexus-7000-vpc-peer-link-yes-and-no/ bye 2011/4/27 Lincoln Dale <[email protected]>: >>> whether a device sends to the 'right' or 'wrong' N7K depends on which >>> physical link it chooses to use in a LAG bundle. as the neighboring >>> device has no idea its a point-to-multipoint bundle, its not really in a >>> position to choose the 'right' or 'wrong' link. >> >> This makes complete sense. It's just weird that when sourced from transit >> interfaces on the directly adjacent 6500s, traffic to the "wrong" N7K is >> actually dropped when the egress would be to another vPC, but when sourced >> from something beyond the 6500s, regardless of the physical link within >> the LAG that's chosen, all traffic appears to work. > > the example i was talking about was OSPF which uses link-local multicast and > TTL==1 packets - which means that if they arrive at the 'wrong' device, they > cannot easily just be sent to the 'right' device. > > i think what you're describing here is aspects of the vPC loop avoidance > mechanism. > >> >>> as to how vPC does loop avoidance, its sort of beside the point as to how >>> it actually does it - just that it _does_ do it. >>> i don't think its a secret per-se as to how we do it, but what you've >>> observed with routing protocols is somewhat orthogonal to that. >> >> Mostly curious as to why some scenarios appear to work even though the >> traffic is traversing links which are to the "wrong" N7K. vPC loop >> avoidance should be dropping these packets as well, so my assumption was >> that it is more involved than simply setting a bit when the packet >> traverses the peer-link and then filtering. > > the vPC loop avoidance system functions prevents loops by dropping > packets/frames that are destined to go out a vPC member port _if all of: > (a) that frame/packet arrived on the vPC peer-link > (b) the vPC 'peer' switch could have sent the packet out an operational vPC > member port itself > > e.g. lets say that a packet/frame arrived on Nexus-A Portchannel100 (vPC > peer-link) from Nexux-B. > if on making a forwarding decision Nexus-A determines that the packet/frame > is to be forwarded to vPC PortChannel150 _and_ it knows that Nexus-B has > operationally-up interfaces also in vPC PortChannel150, _then_ it will drop > the frame/packet to prevent a loop, as it knows that Nexus-B could have sent > it down that path itself. > > > if you're seeing drops in various scenarios, suggest you diagnose/debug what > the IP-address and MAC address is on where you are directing frames. > it may well be that whatever you are testing is already in violation of > RFC-791/RFC-826/RFC-5227 and are not associating a mac address with an IP > address correctly. > > over time, we have discovered numerous devices from a variety of vendors that > violate some very basic RFC behavior which has caused issues. introducing > things like vPC peer-switch addresses some of these misbehaving devices, but > are really addressing the symptom not the root cause. > > >> >> In any case, it's not a big deal. Unsupported, we won't do it, we'll >> leave it at that. :) > > if you absolutely must run a routing protocol over vPC there are ways you CAN > do it. e.g. run it as router-on-a-stick that has L2 hops via vPC. you can > achieve this on a single physical box on N7K by making use of VDCs. > > there's other ways too, e.g. run something like BGP with set-next-hop to the > FHRP address. > > > cheers, > > lincoln. > > > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > -- Lo hai detto hermano. No se escherza con Jesus! (Jesus Quintana) _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
