Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

2600s, VLANs, and MTU Size

Status
Not open for further replies.

Stormfollower

IS-IT--Management
Jun 18, 2010
7
0
0
US
Good day all,

This is the setup:
setup001.bmp

Using this setup I can pass VLAN 1 and 5 traffic. VLAN 1 can ping each of the switches with the command "pin 10.1.30.44 -t -l 1500" or similar. If I try the ping on the VLAN 5 side of things the max size I can get through is 1468. Go above and it dies.

Each of the routers has the following configuration in them. (Changes made for hostname, ip add, etc at each end.) I've tried various versions of IOS 12.1, 12.2, and 12.3 but I cannot figure out how to get them to pass a full VLAN tagged frame.

If I change the switch 1 ports to be untagged VLAN5 and tagged VLAN1 the problem moves to VLAN1 so I'm pretty sure the problem is one of MTU size and the additional bytes needed for VLAN tagging.

I posted this over on the cisco community site and I figure I'd try here also as I've not yet gotten an answer.

The question is simply; if the MTU size can be changed to allow the vlan tags through, how?

I know I can use the command mtu xxxx to change it on BVIxx and on S0/0 but not F0/0. To date this hasn't worked, so I'm missing something.

Code:
 Router1#sh run
Building configuration...
 
Current configuration : 855 bytes
!
version 12.1
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname Router1
!
!
!
!
!
!
ip subnet-zero
no ip routing
no ip finger
!
bridge irb
!
!
!
interface FastEthernet0/0
no ip address
no ip route-cache
no ip mroute-cache
speed 100
full-duplex
no cdp enable
bridge-group 1
!
interface Serial0/0
no ip address
encapsulation ppp
no ip route-cache
no ip mroute-cache
service-module t1 clock source internal
service-module t1 timeslots 1-24
no cdp enable
bridge-group 1
!
interface BVI1
ip address 10.7.200.3 255.255.255.0
no ip route-cache
no ip mroute-cache
!
ip classless
no ip http server
!
no cdp run
route-map rtr permit 10
!
bridge 1 protocol ieee
bridge 1 route ip
!
line con 0
password xxxxx    
transport input none
line aux 0
line vty 0 4
password xxxxx
login
!
end
 
I'm not sure f0/0 is relevant - the additional overhead that is pushing the actual MTU over the limit will be happening between s0/0 & s0/0.

What you should be looking at isn't how to increase the MTU at f0/0 but rather how to enforce a smaller MTU size at that point.

When you say, " the max size I can get through is 1468. Go above and it dies." you really need to be more specific. What happens, exactly - do you get a "must be fragmented" message or no response at all, or something else?

Have you tried this between two hosts that aren't running a firewall?
 
"max size...": when I ping from Windows XP using the following: ping xxx.xxx.xxx.xxx -t -l 1500 (of the controller on VLAN 5) I get a "Request timed out" reply. When I use ping xxx.xxx.xxx.xxx -t -l 1468 I get a reply with the times and such. (This is with VLAN 5 Tagged and VLAN 1 UNtagged on ports 1 of the switches. On the VLAN 1 side of things the first command (pinging the switch) goes thru and gives the reply response.) No firewalls on the computers on VLAN 5.

Using wireshark, I think I see the controller (from the diagram) sending out a large packet which cannot be fragmented. I don't think I can change the way the controller behaves (let's assume I cannot).



 
Your controller should be able to adjust its MTU size, or it would not be RFC-compliant.

Your problem seems to be the lack of reply to an oversized unfragmentable packet.

You can fix this in one of three ways:

1/ Enforce a *lower* MTU on f0/0 (The favourite bodge for people who don't know how to deal with their ISPs)

2/ Troubleshoot the network that lies between s0/0, find out why it is filtering out ICMP Type 3, Code 4 messages (which makes them non-compliant with RFC1191, a 30-year-old networking standard) and get it fixed. (The proper way to fix this issue).

3/ Manually attack the registry on your 2 servers to set a lower MTU. (OK, I guess, if you have a very small number of devices).
 
I guess 1 and 2 can be tested on the bench. The questions are:
1) Which commands to use as the mtu xxxx cannot be used on the F0/0 interface. I can use it on sub-interfaces and on the BVI and on S0/0.
2) The network between s0/0 is a simple T1 cable. I don't know what I can do to troubleshoot it as it's all in the routers.
3) This might be an option IF I was allowed access to this piece of equipment. (I'll check with the vendor and see if there is a way they've setup to do this.)
 
For 2), open a support call with them, demonstrate the issue (ping packets between 14?? and 14?? in size with the DNF bit set get no response), refer them to RFC 1191, and ask them to be RFC compliant.
 
For certain images and for layer 2 ports you can use the system jumbomtu command but there are criteria that must be met before you can use this command so its a long shot but its worth a try.
Cheers
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top