Hi Bryce, You said, "involves VLAN tagging all possible VLANs to every server port" -- if you are trunking to the Nexus, I'm assuming you are using the IEEE 802.1q trunking protocol. In 802.1q, there is the notion of the "native VLAN", which if not otherwise defined on the Nexus, is set to VLAN 1 (ask your network folks about what the native vlan on the bundled interfaces on the Nexus is set to.) Frames sent from the switch to the native VLAN out the trunked interfaces are NOT tagged. Make sure that your server is also NOT tagging frames for that VLAN. Not definitely sure how that's handled in Linux, but I believe that the IP address on the NICs (the common subnet for the bundled NICs) defines the native VLAN. So the native VLAN on the Nexus ports (assuming a 1:1 mapping of VLAN to IP subnet, which is the norm) should be the same as the subnet on the NICs of your KVM host, and not necessarily the subnet of the PXE server (which might or might not be in the same subnet, you didn't say.)
If LACP is being used to negotiate the etherchannel, my understanding is that if it cannot negotiate the etherchannel, then the ports become regular access / trunk ports. You can ask the network guys to provide you with the output of "show int teX/X switchport" (X/X being mod/port#) which will show you all sorts of details on the switchport aspects of the connected interfaces. Here's an example from one of my switches which has a Linux host with a two-int etherchannel: Switch# sh int gi4/17 switchport Name: Gi4/17 Switchport: Enabled Administrative Mode: static access Operational Mode: static access (member of bundle Po5) Administrative Trunking Encapsulation: dot1q Operational Trunking Encapsulation: native Negotiation of Trunking: Off Access Mode VLAN: 200 (VLAN0200) Trunking Native Mode VLAN: 1 (default) Administrative Native VLAN tagging: enabled Voice VLAN: none Administrative private-vlan host-association: none Administrative private-vlan mapping: none Administrative private-vlan trunk native VLAN: none Administrative private-vlan trunk Native VLAN tagging: enabled Administrative private-vlan trunk encapsulation: dot1q Administrative private-vlan trunk normal VLANs: none Administrative private-vlan trunk associations: none Administrative private-vlan trunk mappings: none Operational private-vlan: none Trunking VLANs Enabled: ALL Pruning VLANs Enabled: 2-1001 Capture Mode Disabled Capture VLANs Allowed: ALL Unknown unicast blocked: disabled Unknown multicast blocked: disabled Appliance trust: none You can see that from the "Operational Mode" output, that the port is in a etherchannel ("bundle Po5") and, from the "Operational Trunking Encapsulation" line, that the port is not being trunked (it's in "native" mode.) This sort of output from the connected switch ports may be useful to you in troubleshooting. HTH, Will -----Original Message----- From: tech-boun...@lists.lopsa.org [mailto:tech-boun...@lists.lopsa.org] On Behalf Of Bryce T Pier Sent: Wednesday, December 28, 2011 3:28 PM To: t...@lopsa.org Subject: [lopsa-tech] PXE boot RHEL with native VLAN & LACP Our new design for RHEL KVM hosts involves VLAN tagging all possible VLANs to every server port and using LACP with dual 10Gb links to Cisco Nexus switches. Although everything in this configuration works once the OS is installed and configured, PXE booting the physical server for initial install is failing. We have the native VLAN on the switch port set to the VLAN/subnet that the DHCP/PXE server resides on but the DHCP requests never seem to hit the PXE server. The switch ports are set for LACP/port-channel and we're trying to use the first of these 2 links to PXE boot. I feel like we're missing something in the switch/port config but I'm not familiar enough with advanced network configurations to know. Our network guys think they've got everything set correctly but they haven't done anything like this before either. Is anyone successfully using this configuration and PXE booting? If so, would you mind sharing your port configuration or other bits of wisdom? Thanks, -- Bryce T Pier Unix Geek _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/ _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/