cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6817
Views
0
Helpful
14
Replies
Highlighted
Beginner

VPC ISSUE

Hello..... please help!

I am having an issue with VPC, which I believe is set up correctly! Please see the attached diagram with config.    I have also pasted all the configs that are relevant below.. I hope.

Basically, communication between server 0 and servers 1 and 2 is fine when both SVI's are up, however, shutting down one SVI of VLAN 40 will result in Server 0 only being able to ping one of the servers - server 1 for example. Bringing that SVI up and downing another will result in the other server (server 2) being reachable and server 1 not being reachable.

It is also worth noting that the server's active nic's are facing different sides of the aggregation layer, so there is clearly a layer 2 issue but I just cant see where it is.

Can anyone suggest what it may be based on the configs attached? I'm happy to put any further config if required. Below are the SVI configs from each core.

If anyone can suggest anything it would be greatly appreciated.

Thank you

VPC Issue.jpg

2 ACCEPTED SOLUTIONS

Accepted Solutions
Highlighted

Anthony,

the more I think about my answer the more I believe it to be wrong for the following reasons:

  • I tested it in a pre production environment that is quite similar to your design. I did not encoutner any packet loss
  • With the SVI we don't have a pure layer 2 environment. The SVI is rather equivalent to a layer 3 port, where the frame is disassembled, routed and encapsulated again. I don't believe it is considered by the loop prevention logic to be the same frame like the one ingressing from the peer link .
  • The Cisco design guide clearly states: "vPC loop avoidance rule states that traffic coming from vPC member port, then crossing vPC peer-link is NOT allowed to egress any vPC member port; however it can egress any other type of port (L3 port, orphan port, …). " In this case the frame is egressing the SVI port and loop prevention should not kick in, right?

After having a closer look at your topology I am a little bit confused. I expected to see the classic double-sided vpc design, but I just realized you have,... well, I don't know, it's neither single sided nor double-sided vPC. I don't know if this is a supported design. Is spanning tree blocking one of your PCs? Your problem *may* somehow be related to your design.

Following the Cisco design guide one would aggregate all physical links from agg-layer to core-layer into 1 single port-channel, thus having only 1 port-channel (excluding peer-link) and 1 vPC interconnecting the 2 vPC-Domains.

Best Regards

View solution in original post

Highlighted

  • With the SVI we don't have a pure layer 2 environment. The SVI is rather equivalent to a layer 3 port, where the frame is disassembled, routed and encapsulated again. I don't believe it is considered by the loop prevention logic to be the same frame like the one ingressing from the peer link .
  • The Cisco design guide clearly states: "vPC loop avoidance rule states that traffic coming from vPC member port, then crossing vPC peer-link is NOT allowed to egress any vPC member port; however it can egress any other type of port (L3 port, orphan port, …). " In this case the frame is egressing the SVI port and loop prevention should not kick in, right?

Just want to comment on the about statements - packet went over the peer-link and then inter-VLAN routed by the SVI still subject to the vPC loop prevention check.

HTH,

jerry

View solution in original post

14 REPLIES 14
Highlighted
Enthusiast

Could you include the configurations for the interfaces/port-channels connecting to the servers?

Highlighted

Hi. Not at work anymore, but, server 0 is configured identically on 2 single homes fex.
Config is
switchport
Switchport mode trunk
Switchport trunk allow vlan 20 , 40 , 60
Spann port type edge

Server 1 and 2 are dual homed to 2 single homed fex
Switchport
Switchport mode access
Switchport access vlan 120
Spann port type edge

None are in port channels.

Sorry, I am on my iphone so tricky to get all the text formatting.

Thanks for looking.

Anthony


Sent from Cisco Technical Support iPhone App

Highlighted

Anthony,

Can you post vpc configs for agg1 and 2 connecting to servers?

Highlighted
Beginner

Hi

There is no vpc for the servers. They are just using active / standby nic teaming.

Thanks for looking

Anthony

Sent from Cisco Technical Support iPhone App

Highlighted

Then it will not work.  You are connecting a server to 2 different switches via 2 FEXs right? IF yes, you would need to put the links in a VPC.  You also have to make sure VPC is working between the 2 switches.

Are the FEXs connected to 2 5Ks?

HTH

Highlighted

Reza Sharifi schrieb:

Then it will not work.

That is not true. Active/standby without vpc is the same like a single homed server and is considered an orphan port form the vdc point of view. If neccessary this traffic will pass the peer link. It is a working and supported design.

Highlighted
Beginner

Hi, thanks for the response. I think it should work though. The servers are using nic teaming, so active standby managed by the server. Each 2k is connected to only 1 x 5k.
Traffic flow should be that the server uses its primary nic no matter what and when the server tries to reach its gateway it should be able to as that is how harp should work. Following a trace route, the server reaches the default gateway but never gets further. If I enable both svi's at the same time everything is fine. If only one is active then only half of the network works.
Basically, traffic hits the default gateway in all scenarios, but when one svi in the hsrp is shutdown, half of the servers fail and it depends on which 5k their active nic is going via.


Sent from Cisco Technical Support iPhone App

Highlighted

Can this be to do with the VLAN being allowed over the peer link?

I allow all vlans over the peer link for the situations when there is no other route to get to the other side of the network and am under the impression that this is acceptable and managed by the VPC feature itself.

Highlighted

This is definitely doable without the use of VPC, but this is also likely to be the source of your issues. Non-negotiated server NIC redundancy is way less reliable then LACP. Being that you have your servers connected to Nexus gear that is capable of VPC, why not configure VPCs to the servers?

Highlighted
Participant

As the server is attached in a non-vpc-way to the aggregation layer there shouldn't be any vpc trouble on that level. I guess it could have to do with the vpc loop prevention logic on the core layer.

Assuming a packet destined for the hsrp virtual mac is received by a core switch, it will be routed to the destination network and send back down a vpc link, weather it was received by the hsrp active or standby switch. If one svi is shut, the switch can't route the packet but instead has to switch it over the peer link to the remaining svi on the peer switch. Now the vpc loop prevention mechanism dictates, that the active core switch must not forward a packet via vpc link, if it was received via peer link, at least not as long as the corresponding vpc link on the peer switch is not down. As a result I belive the packet is dropped by the hsrp active switch.

Highlighted
Beginner

Thanks Pille

That is an invaluable response. Ive Been reading something similar today, what you say makes a lot of sense!

The thing is, is there a way around it? All I can think is that we must use a separate L2 trunk for affected vlans, however, in theory, that will be all of them! Will vpc still work properly if the peer link and standard L2 vlan link are separated?
Is there a better solution without using a separate link? There must be a way to do it, otherwise it seems like a serious limitation of vpc?

Thanks again for your response, its much appreciated.

Anthony



Sent from Cisco Technical Support iPhone App

Highlighted

Anthony,

the more I think about my answer the more I believe it to be wrong for the following reasons:

  • I tested it in a pre production environment that is quite similar to your design. I did not encoutner any packet loss
  • With the SVI we don't have a pure layer 2 environment. The SVI is rather equivalent to a layer 3 port, where the frame is disassembled, routed and encapsulated again. I don't believe it is considered by the loop prevention logic to be the same frame like the one ingressing from the peer link .
  • The Cisco design guide clearly states: "vPC loop avoidance rule states that traffic coming from vPC member port, then crossing vPC peer-link is NOT allowed to egress any vPC member port; however it can egress any other type of port (L3 port, orphan port, …). " In this case the frame is egressing the SVI port and loop prevention should not kick in, right?

After having a closer look at your topology I am a little bit confused. I expected to see the classic double-sided vpc design, but I just realized you have,... well, I don't know, it's neither single sided nor double-sided vPC. I don't know if this is a supported design. Is spanning tree blocking one of your PCs? Your problem *may* somehow be related to your design.

Following the Cisco design guide one would aggregate all physical links from agg-layer to core-layer into 1 single port-channel, thus having only 1 port-channel (excluding peer-link) and 1 vPC interconnecting the 2 vPC-Domains.

Best Regards

View solution in original post

Highlighted

  • With the SVI we don't have a pure layer 2 environment. The SVI is rather equivalent to a layer 3 port, where the frame is disassembled, routed and encapsulated again. I don't believe it is considered by the loop prevention logic to be the same frame like the one ingressing from the peer link .
  • The Cisco design guide clearly states: "vPC loop avoidance rule states that traffic coming from vPC member port, then crossing vPC peer-link is NOT allowed to egress any vPC member port; however it can egress any other type of port (L3 port, orphan port, …). " In this case the frame is egressing the SVI port and loop prevention should not kick in, right?

Just want to comment on the about statements - packet went over the peer-link and then inter-VLAN routed by the SVI still subject to the vPC loop prevention check.

HTH,

jerry

View solution in original post

Highlighted
Beginner

All

Just to updat you, this is resolved.

The last 2 statements by pille and Jerry are the reason why, plus something else.

First of all, in what scenario shoulw one half of HSRP be shut down? Not many! The VPC then goes into a type 2 consistency check error and wont allow that traffic over the peer link (I think!)

So, the VPC loop avoidance kicks in if the traffic traverses the peer link, but also, when the traffic goes from one vlan to another, there is nothing to say that it is not returning via the core with the vlan shut down, and the default gateway from the other vlan has no where to route the traffic as the next hop is admin down, which black holes the traffic.

Thanks for everyone's responses and help in resolving this!


Anthony

Content for Community-Ad