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/

Reply via email to