1. Home
  2. Cisco Systems
  3. 802.1q Trunking & MTU

802.1q Trunking & MTU

I'm trying to migrate a Nokia-based Check Point firewall from connecting into multiple switch ports on a 4506 switch to using trunk ports over etherchannel.

I've configured four 10/100 ports over two blades on the switch to use Etherchannel, e.g:

interface Port-channel10 switchport switchport trunk encapsulation dot1q switchport mode trunk duplex full

interface FastEthernet5/39 switchport trunk encapsulation dot1q switchport mode trunk speed 100 duplex full no cdp enable channel-group 10 mode on

Interfaces 5/40, 6/39 & 6/40 have identical configuration to 5/39.

I've configured the Nokia to aggregate four 10/100 ports connected into the 4506 and configured a number of VLAN interfaces.

The 4506 connects into each of our core switches (6509s), which in turn connect into our four distribution switches (also 6509s) and finally into my access switches.

I'm experiencing a number of problems carrying out tasks on the Nokia over the new virtual interface (basic pings and web access work, but payloads over 1468 bytes time out, FTP transfers fail etc.) which suggested MTU problems. Having checked the Nokia docs it made a specific note of ensuring the switches support a MTU of 1504 bytes, so I made this change on the 4506 into which the Nokia connects; however the intermittent problems remain. When I check the interfaces linking the 4506 to the core switches, they show a MTU of 1500; however the

6509's will not let me configure a system-wide MTU of 1504 (it only lets me configure jumbo frames) or on the gigabit interfaces linking the 4506 (again, it only lets me configure a jumbo frame side). For reference, the 6509's are running IOS 12.1(13E11) and the 4506 is running IOS 12.2(25EWA1). Also for reference, this is the first device other than the switches themselves that have been configured as trunking ports (e.g. all other servers / routers connect into access ports).

It definitely appears to be an issue only when the traffic passes through the core/distribution/access layers - when I connect a laptop directly into the same 4506 as the Nokia, it is able to connect without any problems.

I'd appreciate any thoughts!

Cheers, Chris

Reply to
Can2002
Loading thread data ...

As a follow-up, it appears the problem only occurs with the combination of Etherchannel & 802.1q. I configured a single port on the 4506 switch as a trunk port using dot1q and configured another spare interface on the Nokia with a VLAN. This port worked fine, but as soon as I configured it as part of an Etherchannel group, it stopped working again.

I'm going to try configuring an Etherchannel access port next to see if the problem remains or if it's just a combination of the two that gives the problem.

Cheers, Chris

Reply to
Can2002

It definitely seems to be the combination of Etherchannel & 802.1q that's causing the problem. After I changed the port-channel interface on the 4506 switch from 'switchport mode trunk' to 'switchport mode access' and set it to the appropriate VLAN, I removed the virtual interfaces on my Nokia and then configured the native VLAN with the appropriate IP address, which was fine.

Still no closer to a solution though:-(

Chris

Reply to
Can2002

There are a few things that I notice here. In no special order apart from the first one.

  1. Are you sure that you want channel-group 10 mode on

I now forget exactly how "mode on" works. Have you applied the equivalent to the Nokia? If not the Nokia may be doing LACP (802.3ad) and the cisco will be ignoring it.

Try LACP on the Cisco unless the Nokia lets you turn it off. The current recommendation is to have Channel negotiation on, on Cisco anyway.

formatting link

  1. This is bread and butter to Cisco. Such a bug would almost certainly be fixed pretty quick.
  2. "but payloads over 1468 bytes time out" I presume that you mean Windows "ping -s 1468 x.x.x.x OK this will create frames 4 bytes smaller that the maximum ethernet frame size.
  3. You definately */do not/* need to change the MTU on the cisco.
802.1Q */requires/* that the extra 4 bytes be catered for. My view is that the .Q Tag is best thought of as being applied at the exit port and stripped at the entry port. If the exit port is not a trunk port /or/ if the frame is in the Native

VLAN of the (trunking) exit port the no Tag is applied.

  1. The Cisco config looks OK. I do though disagree with having the trunk configuration on the physical ports since I think that it adds confusion. I think that it does work (and I am not in fact sure that it works without it:-). There may be some failure scenarios where it might be handy. e.g Channel fails to come up, maybe you would at least have one working link???

interface Port-channel10 switchport switchport trunk encapsulation dot1q switchport mode trunk duplex full

interface FastEthernet5/39 !->> switchport trunk encapsulation dot1q !->> switchport mode trunk

  1. On the Cisco you can check that what you think is happening is really happening.

sh int ether sh int trunk

Hope some of the above ramblings are helpful.

Good Luck.

Reply to
anybody43

Hi there,

Thanks for your feedback!

snipped-for-privacy@hotmail.com wrote:

The Nokia documentation specifically requests that PAGP & LACP are disabled, hence my setting; however confusingly the interface configuration screen on the Nokia mentions it's running in 802.3ad mode! I'll give LACP a try on Monday when I get back in the office.

My core switches are not running particularly recent code, which might explain it; however I agree with your point.

You're spot on, I simply incremented the payload size until I stopped getting responses (so ping -l 1468 a.b.c.d worked, ping -l 1469 a.b.c.d didn't).

Thanks for that - I was starting to clutch at straws when I made that change...

Fair point - I'd not made a concious effort one way or the other.

Thanks, I'll give that a try. I've also got a call logged with Nokia now too, so I'll hopefully make some progress next week...

Cheers, Chris

Reply to
Can2002

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.