cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2457
Views
0
Helpful
7
Replies

Routing over vPC Peer

aeroliteflyer
Level 1
Level 1

Hello everyone,

I am running into a snag deploying our two new Nexus 56128P.  Both are utilizing vPC pairs for switch access.  I also have a vPC peer going to a 2960X which serves as a small aggregation for the core Nexus and FW and core router(4451).  The core router serves as the gateway for everything out.  The core router has a regular LACP port channel into the 2960X as well.  I want to start off by saying I have read many threads about routing over vPC peers, but with Nexus 7.2 it is suppose to be officially supported by Cisco.  So, my 56128's have several SVI's that I want to route, one in particular is forming the adjacency with the 4451.  The SVI's are HSRP'd.  The EIGRP neighbors seem to form good and actually work pretty stable.  The problem is when I ping from the 4451 to either the HSRP address of the SVI or the individual IP's of the SVI, it looks like packets are getting dropped.  It's not all the time, but it is most.  Smaller packet sizes seem to have a better time than larger ones.  So if I do a 1000ct ping, it may do 100% no issue.  Next time, it may get through half, then start dropping.  And it drops regularly, it's like every 24th packet or every 30th packet, not random.  It happens whether I disable EIGRP and do just a static route or leave EIGRP, so I don't think EIGRP is the issue.  Don't think it's HSRP necessarily since it happens when I ping the individual IP's of the switches.  I listed some config specifics below. Thank you in advance for any advice.

Chris

vPC domain is configured with peer-gateway, peer-switch, role priority is set, ip arp synchronize.

vPC peer link is dual 40GB adapters.  All VLAN's are allowed across that trunk, except 1. 

vPC port channels are mode active, trunked with appropriate VLAN's

Nothing fancy on HSRP, I have prempt on SW1 with priority of 105.  SW2 is left at defaults.  HSRP version is 2. 

1 Accepted Solution

Accepted Solutions

Hey Chris,

I must have missed this response. Ok, so if I understand correctly if you have traffic traverse teh N5k then there are no drops. Only when we ping to and from the N5k we see the drops correct? If that is the case, then yes, this is most likely CoPP blocking/rate-limiting our pings. Nothing to be concerned about as this was done on purpose to protect the N5k's CPU. 

Thanks,

Victor Hugo Acevedo

View solution in original post

7 Replies 7

Victor Acevedo
Cisco Employee
Cisco Employee

Hey Chris,

Just FYI, Routing over vPC is only supported on 7.2 code on F3 cards on the N7k platforms. All other platforms still do not support this:

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/7_x/nx-os/release/notes/72_nx-os_release_note.html#pgfId-1175814

Do you also see drops when you go through the N5k's instead of pinging them directly? 

Thanks,

Victor Hugo Acevedo

Victor,

Thanks for the info.  Clearly I assumed incorrectly that n7.2 on the 5600 series would function the same.  That's my bad.  To that end, do you have any thoughts on Cisco documentation that says unicast routing should work, although not recommended but multicast routing is not supported.  I think this guide is probably dated, but in this guide http://www.cisco.com/en/US/docs/switches/datacenter/nexus5000/sw/mkt_ops_guides/513_n1_1/n5k_L3_w_vpc_5500platform.pdf figure 5-8 on the right is probably closest to my current architecture.  Although, from my router to the 2960X is a port channel as well.  To answer about the pings, yes I am seeing the drop from any direction.  If I ping from the router to the HSRP VIP, I see drops.  If pinging to the individual 5k IP's for the SVI, those drop.  If pinging from either n5k to the gateway IP on the router those drop as well.  The mgt IP of the 2960X switch is also in the same VLAN/subnet, so I pinged to the n5k's from that and got the same results.  The 2960X's load balance is src-mac.  And, I do have the network qos for jumbo applied to the n5k's.  I usually use a set of 1000ct pings at 1500 byte payloads.  Funny thing is, I do that once or twice, and they will be 100%.  Then, I try a third set, and about half way through it will start dropping about every 30th packet or so, regularly.  If I let it sit for a while, then it seems to work a time or two again.  Again, thanks for your insight on this.

Hey Chris,

Unfortunately, I have not seen that documentation saying that. Will this scenario may work for unicast it is still deemed unsupported because of the instability factor. If it works fine now but a link flap occurs or something else in the network changes that causes the neighborship to go down, it may not recover correctly and leave you in a flapping scenario. Hence we deemed this unsupported. 

Regarding the ping issue, I meant to ping above the N5k's and not to or from the N5k. Your drops could be caused by CoPP. So I wanted to see if you also saw drops when the router pings something upstream of the N5ks so this would just be seen as data-plane traffic and not control-plane traffic - i.e. pings are control-plane traffic and policed heavily by CoPP.

Thanks,

Victor Hugo Acevedo

Victor,

Also, I may not have exactly understood last night what you were asking about pinging through the switch.  Since this is still dev, I only have one client on the switch actively.  And that is actually in a switch stacked that is uplinked to the 5k's through vPC and 10g, which the 5k's then uplink to 2960X through vPC and then the core router is connected to 2960X with port channel.  But, yes it seems if I ping from the core router, to the IP of my client PC it is 100%.  Even tried a 10000ct 1500 byte ping and it was 100%.  I have a continuous ping from my PC to a network that has be be routed, and it hasn't dropped. 

Hey Chris,

I must have missed this response. Ok, so if I understand correctly if you have traffic traverse teh N5k then there are no drops. Only when we ping to and from the N5k we see the drops correct? If that is the case, then yes, this is most likely CoPP blocking/rate-limiting our pings. Nothing to be concerned about as this was done on purpose to protect the N5k's CPU. 

Thanks,

Victor Hugo Acevedo

Victor, That is correct...only pings to/from the 5k's drop, going through to anything is 100%. I saw your first response that it is probably CoPP and that seems to be it. Thank you for clarifying...gives me some peace of mind to continue my deployment. Thanks, Chris

Hey Chris,

Not a problem, I'm glad we were able to get to the cause of these drops. 

Thanks,

Victor Hugo Acevedo

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: