ProLiant Servers (ML,DL,SL)
cancel
Showing results for 
Search instead for 
Did you mean: 

VLAN issue on with dual port NIC NC7782 on BL25p Server Blade

 
Anna Fischer
Occasional Contributor

VLAN issue on with dual port NIC NC7782 on BL25p Server Blade

I have a problem with dual port NICs NC7782 on BL25p server blades:
I'm sending tagged VLAN packets between several blade servers which are all connected to the same switch which is forwarding those tagged VLAN packets unmodified. Now the issue that I'm seeing is that when I use the first port of that NIC, it seems as if the NIC is stripping off the VLAN tag while it does not strip off the tag if I use the second port. Within the OS (Linux) both ports use the same driver and configs (the ports appear as two separate NICs to the OS), and therefore I'm struggling to understand why tags are removed when coming in through one port, but not on the other.

Is it possible that the NIC only supports VLAN offloading (stripping off VLAN tags) on a single port? Is this a known issue?

Many thanks,
Anna
4 REPLIES
Blazhev_1
Honored Contributor

Re: VLAN issue on with dual port NIC NC7782 on BL25p Server Blade

Hi Anna,

Hi, I don't understand much from Linux, but:

http://h20000.www2.hp.com/bc/docs/support/SupportManual/c00429271/c00429271.pdf?jumpid=reg_R1002_USEN

Check the table for enahnced backplane on page 7(BL25p requires enhanced). The packets from the 2nd connection are routed through the signal backplane to the 2nd interconnect(B), from the 1st one are routed to switch A...this leads me to the point that the problem can be in the wnd switch configuration. Check the switch A VLAN configuration i it is the same as the 2nd switch...I hope that I understood right what you meant.

Ich hoffe, dass dies ist das Problem und mit der Konfiguration von dem ersten Switch die Stoerung weg wird :)

Regards,
Pac
Anna Fischer
Occasional Contributor

Re: VLAN issue on with dual port NIC NC7782 on BL25p Server Blade

Pac, thanks for your reply. I don't really get what you mean though. I am using 2 ports from the same physical (dual port) NIC (NC7782). When I connect the 1st port to the switch I do see tagged packets coming in while I see un-tagged packets when I connect the 2nd port to the switch. I am not connecting both ports at the same time, but only one at a time. I connect both to the same switch port, so the switch's VLAN configuration is the same. The switch is not stripping off the packets, this must happen when the packets go into the NIC - but only for one of the two NIC ports?
Blazhev_1
Honored Contributor

Re: VLAN issue on with dual port NIC NC7782 on BL25p Server Blade

Hi Anna,

I don't know about such issue, that only one of the ports supports VLAN offloading.
What I tried to explain you is that each port sents data to different switch, I'm not sure if you can confugre both ports to access only one of the switches. The technology of p-class is so made, so that for redundancy, one of the ports is routed to the left switch and the other one is routed to the right one(in the document above). This means, since this happens to only one port, the problem seems to be in the switch. In other words, every port of the NC7782 uses a different switch, by technology their packets are not routed to the same one. I said I'm not good at Linux and I'm not sure if you can make a configuration that both NICs use the same switch, but I'm quite sure that you can't.
Sorry if I didn't understand something...

Pac
Anna Fischer
Occasional Contributor

Re: VLAN issue on with dual port NIC NC7782 on BL25p Server Blade

I understand that in normal circumstances the two NIC ports are connected to two different switches for redundancy. However, just for finding out where the problem with the VLAN tagging is, we have unplugged one NIC port from the switch, and then connected the second port to exactly that switch instead. This was just for the purpose of diagnosing the problem we've seen.
We see VLAN tagged packets when the machine is connected with the second port, but not when it's connected with the first port, and we're trying to figure out why this is the case, as this is unexpected behaviour (to me).