Only one vpc interface is used for communication ?

[Network_Sarovani]

Hi Experts , 

We have server connected to 2 Leaf switches in VPC mode .LEAF101 and LEAF102 ... We found CRC error on  LEAF101 eth1/10 interface .So we have replaced the Fiber cable and sfp port ..But now we could see CRC errors on LEAF102 eth1/10 interface (earlier crc was not there in this interface ) .

And also from the Solarwinds graph we could see traffic is now on LEAF102 only and error is also on LEAF102 .There is no traffic on LEAF101 eth1/10 interface and no CRC errors . 

On Vpc both interface should serve the traffic right ? do you see any issue on this ?

[Network_Sarovani]

But You can also observe on Pod-2 traffic is again not loadshared on the switch end ..Why it sends more packet on LEAF206 and less on LEAF205 ?

Even though , we have verified the fiber cable and reseated the sfp port , We are still receiving CRC input error on LEAF 101 nd 102 .

[Sergiu.Daniluk]

---

But You can also observe on Pod-2 traffic is again not loadshared on the switch end ..Why it sends more packet on LEAF206 and less on LEAF205 ?

That's most likely because you don't have a lot of flows. Again, any other discussion around this topic is pointless unless you fix the misconfig: either on server side - so you have a real port-channel on both sides, or one leafs side - remove the vpc so the mac addresses to be learned on only one leaf.

---

Even though , we have verified the fiber cable and reseated the sfp port , We are still receiving CRC input error on LEAF 101 nd 102 .

---

What do you mean you "verified" the fiber? Did you changed the fiber/sfps? If not, than try changing them, first the fiber and then the SFPs. If after the replacement, the CRCs persits, move the SFP to another interface on the leaf. If the problem persists, change the port on the server side. 

Cheers,

Sergiu

[Network_Sarovani]

@Sergiu.Daniluk thank you . 

Yes , We have performed light link verification of Fiber cable and replaced SFP port on the switch side .

Also we have asked server team to check with their vendor regarding teaming config . 

[Network_Sarovani]

This was answer from Server vendor on loadsharing : 

Note that link aggregation "balancing" does balancing with different TCP connections...a single TCP connection is always going to go across the same link (assuming no changes in link up/down status). To see balancing happening you need many TCP connections. FTP is not going to show that unless you do several of them.

Also, the customer may need to look at the link aggregation load balancing mode on the switch. If they are just balancing on IP addresses and not source or destination port then the switch is going to put all traffic to/from particular IP addresses on just one link. They should verify that mode on the switch is considering source/destination ports as well. They are good on the IBM i side..it is considering source/destination ports when deciding which link to use.

[Sergiu.Daniluk]

"a single TCP connection is always going to go across the same link" - since you have a single backup connection (single sIP/sPort + dIP/dPort), the traffic will only be sent across the same interface. 

Cheers,

Sergiu

[MHM Cisco World]

We will divide the issue into 
1- single Link why? 
we ask you check teaming, are you see mac address in one link of PO connect to Server ?
are you use Hashing algorithm using the Scr L4 port not destination ?

2- CRC 
if you run Cut-through NSK SW then there are chance that the CRC error not from SW or BAD cable but the NSK receive it from other neighbor SW how I check that ?
do show error counter 
check that Link to Server is show Xmit-Err 
if Yes, then check what other port show FCS-Err & Rcv-Err 
if Yes and see FCS-Err & Rcv-Err 
check the CDP see what is NSK SW connect via port you see these error on 
go to that SW and check the Xmit-Err 
if you see Err count in Xmit-Err in Second NSK meaning that second NSK is not issue but it also receive bad frame from other 
do same step above until you find 
NSKx-NSKy
NSKx has FCS-Err & Rcv-Err 
NSKy have Xmit-Err 
here the cable indicate that the cable is bad and need to change.

One more point, if the CRC come with giant error then this because of MTU mismatch.