VCE - Trunked Channel Cisco Config?

[fishmn]

Sorry for the long description but these things get complex! note: I posted this to the Bladesystem forum as well. We have put a lot of work into creating a std configuration for our c7000 enclosures including documentation. We connect our VCE modules with multiple GiGE uplinks channeled to seperate physical Cisco 6509 switches. We then setup seperate SUS's in VCM for both "legs". We then create an A and B Ethernet Network for the same VLAN from each SUS. We assign Ethernet A to NIC1 and B to NIC2 on our Windows2k3 blades then setup a TLB with preference order and round robin LB team for balanced transmit traffic. This configuration works fine in function and throughput testing.. however it is going south when we do catastrophic network testing (shutting down distribution switches which should fail default gateway and subsequent traffic over to its redundant partner using HSRP). We find that a very similar physical and teaming configuration on our standalone DL servers will not fail. The key physical network differences are that we do not have channeled trunks to the DL like we do on the VCE modules. The following is running config on two of the channeled trunks. Could PORTFAST ON be an issue since the VCE is sort of a switch? interface Port-channel13 description Testing c7000 switchport switchport trunk encapsulation dot1q switchport mode trunk no ip address interface GigabitEthernet9/1 description C7000 Blades switchport switchport trunk encapsulation dot1q switchport mode trunk no ip address no snmp trap link-status no cdp enable spanning-tree portfast channel-protocol lacp channel-group 13 mode active ! interface GigabitEthernet9/2 description C7000 Blades switchport switchport trunk encapsulation dot1q switchport mode trunk no ip address no snmp trap link-status no cdp enable spanning-tree portfast channel-protocol lacp channel-group 13 mode active Thanks for any insight.. Ron

[David Billot]

Having portfast enabled on the channel group ports is okay, and is a best practice for VC solutions (you should treat VC as an endpoint), so that's not the issue. If you are failing the distribution switches, then neither VC nor the NIC Teaming driver will be affected since they are connected to the access layer (no failover). Instead, all failover would be at your distribution layer (I believe that is what you have indicated is happening.) My suspicion is that if you performed your test with non-channeled ports, you'd get the same affect. It would also be good to understand which direction is being affected during the failover -- traffic to the NIC, or traffic from the NIC. Feel free to post a graphic of your design if we need to continue the dialog. Thanks, Dave

[fishmn]

Hello Dave, This test is very reliable and happens on both inbound and outbound traffic. We have our VLAN's configured such that odd numbered VLAN's default as primary (default gateway) to Distribution switch A and Even numbered VLAN's to Dist B so we get more even traffic flow across all switches. We have done further testing this week and confirmed that When the blade server is configured on an odd VLAN and Dist A goes down our file transfer fails. When configured on an even VLAN and Dist B goes down the transfer also fails. The non primary dist switch has no affect when it goes down. I'm not sure what kind of graphic you think would be beneficial.. The Virtual Connect configuration or the network switch layout?

[fishmn]

I opened ticket 3600429464 with HP. They have supposedly escalated it to the networking group. Have not made contact yet. Bad time of the year to have difficult issues with everyone on vacation.

[fishmn]

We solved this issue with the assistance of HP. It is a case of RTFM.. or at least the VCE cookbook. We had failed to put the "trunk" keyword in our portfast commands. Once in place this works fine and we only lose a single ping. Thanks.