Solved: Pinging across VLAN's with packet larger than 1500 bytes

johnpittman · ‎05-20-2008

Here is the root of my problem...I think. I have two vlans set up. Vlan1 and Vlan172. I can ping between them fine, unless the packet is 1501 bytes or larger. I am not setting the DF bit on any pings. I assume the packet should fragment if it is larger than the MTU. Instead I get a Destionation host unreachable if done from windows and timeouts if done from a router or switch. Where do i need to start looking? Here are the router VLAN code snippits.

interface FastEthernet0/1.1

bandwidth 10000000

encapsulation dot1Q 1 native

ip address 172.4.1.254 255.255.0.0

ip nbar protocol-discovery

ip pim dense-mode

ip virtual-reassembly

no snmp trap link-status

!

interface FastEthernet0/1.172

bandwidth 10000000

encapsulation dot1Q 172

ip address 172.31.251.250 255.255.255.0

ip pim dense-mode

no snmp trap link-status

And on the switch:

interface Vlan1

ip address 172.4.1.253 255.255.0.0

!

interface Vlan172

description VOICEVLAN

ip address 172.31.251.254 255.255.255.0

ip helper-address 172.31.251.254

ip helper-address 172.4.1.254

priority-group 1

And some assorted switchports:

interface FastEthernet0/21

switchport trunk encapsulation dot1q

service-policy input VOICE

srr-queue bandwidth share 10 10 60 20

srr-queue bandwidth shape 10 0 0 0

auto qos voip trust

storm-control broadcast level 1.00

random-detect

spanning-tree portfast

!

interface FastEthernet0/22

switchport trunk encapsulation dot1q

service-policy input VOICE

srr-queue bandwidth share 10 10 60 20

srr-queue bandwidth shape 10 0 0 0

auto qos voip trust

storm-control broadcast level 1.00

random-detect

spanning-tree portfast

!

interface FastEthernet0/23

switchport access vlan 172

switchport trunk encapsulation dot1q

switchport mode access

service-policy input VOICE

srr-queue bandwidth share 10 10 60 20

srr-queue bandwidth shape 10 0 0 0

auto qos voip trust

storm-control broadcast level 1.00

random-detect

spanning-tree portfast

Does anyone have any idea what may be the issue here. Basically what I am seeing, anytime windows (VLAN1) needs to send a packet larger than 1472 across the wan (the wan link is on VLAN172), the packet needs fragmented, but instead of doing that, it gets dropped/lost.

Thanks to all in advance.

Edison Ortiz · ‎05-20-2008

Can you send packets larger that 1500 on the same Vlan ?

Can you post the entire config from the router ?

__

Edison.

View solution in original post

andrew.prince · ‎05-20-2008

John,

You could try enabling jumbo frames on the WAN:-

http://www.cisco.com/en/US/products/hw/switches/ps700/products_configuration_example09186a008010edab.shtml

HTH.

johnpittman · ‎05-20-2008

I do not think that would help the local situation though, would it? I have devices plugged into the same switch that can't pass anything over 1500 bytes because they are on two different VLANS. All VLAN MTU's are at 1500.

Why will the packet not fragment is the root issue I think....

Thanks.

Edison Ortiz · ‎05-20-2008

Can you send packets larger that 1500 on the same Vlan ?

Can you post the entire config from the router ?

__

Edison.

johnpittman · ‎05-20-2008

Yes. I can send virtually any size packet on the same VLAN. Cisco Tac has finally touched base with me. He is having me try something right now. It requires a reboot so I will not know for an hour or so. If that bombs off I will go ahead and post the entire config.

Thank you

johnpittman · ‎05-21-2008

Thanks everyone. The issue is solved. The Cisco tech was having problems too. He was sharp cookie though. We first tried the Jumbo frame thing on the switch. That did not help. Finally we had to go line by line through the router code. There were a couple of lines that neither one of us could explain why they were there. "ip nbar protocol-discovery" and "ip virtual-reassembly" was applied to the interface of VLAN1. We removed both but the tech said he is sure it was the ip virtual-reassembly command causing the issue.

Everything seems to be working fine so far. It is one of those issues where I hope we didn't break something while fixing something else.

Thanks for everyone's help.