Cisco Router / Metro E issues

[kerneldead]

I have two routers a Cisco 1841 and a Cisco 3620. We have just invested in a Metro e 3.0 meg connection to replace a T1. I have put this connection into production last week only to have to revert back to my T1. The metro e connection started acting sluggish, I could not print across it to my print server, access files etc. here is my configurations:

Cisco 1841:
interface FastEthernet0/1
description Metro E
ip address 172.16.255.14 255.255.255.252
speed auto
full-duplex

Cisco 3620:
interface Ethernet1/0
description Metro E
ip address 172.16.255.13 255.255.255.252
full-duplex

Any ideas on what would cause the connection to degrade/ It almost seems like I have a bottle neck.

Thanks,

 

[VinceWhirlwind]

In other words, *if* there's a problem, *then* think about not using auto/auto.

....and I'm only talking about today's technology - if you use older stuff, you'll have the usual old problems with auto-negotiation.

 

[burtsbees]

My sentiments exactly

/

tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!

 

[kbing]

I've done this many times and never had port speed/duplex issues. Here's my recommendation:

Set ports back to speed auto, full-duplex on interfaces of each router connected to MetroE UNLESS the vendor instructs you specifically to modify it. Since your MetroE is 3MB - worse case it will auto negotiate down to 10MB which is plenty more than 3MB. Next verify you don't have half-duplex. This will be a problem. If you have half-duplex - hard configure for full-duplex.

Next - Is this a fiber based service? If so set your MTU to 1300.

Can you ping across the network from host to host? If yes...then can you RDP or HTTP across from host to host? If this answer is no then you have a IP fragmentation issue.

issue "ip tcp mss-adjust 1340" on interfaces on both sides of the MetroE. If this 1340 value doesn't allow the Layer-4-7 application traffic lower the value until it works.

 

[VinceWhirlwind]

I'm with you kbing, except for the "TCP MSS-adjust".
Instead, I would get onto the WAN provider and tell them their link is non-compliant with RFC 1191, a core ethernet standard.
Then I would sit back and enjoy the fun.

 

[kerneldead]

The provider cleared up all of the errors that we were getting and had use set everything to auto. This has worked so far. The only issue I am currently having is we are not getting 3m. I have waited until there was no traffic on our network and performed bandwidth test between two host accross the metro-e and at most I am only able to get 1.55m and we are getting a lot of unknown protocol drops. I am guessing the unknown protocol drops are from STP packets and nothing to worry about.

 

[kbing]

Hmm STP is spanning tree. On a routed connection you shouldn't have spanning tree. Something else is amiss...

how are you seeing unknown protocol drops? sh int?

what I would do is "clear counters" now that everything appears to be working and monitor for any drops, errors, crc problems, etc.

Can you RDP or HTTP or FTP across the link? If not - ip fragmentation assuming ping works. That means you'll have to tweek the tcp mss-adjust parameters. If not and L4-7 still doesn't work then something on the router is still wrong.

 

[kerneldead]

We were thinking that the STP packets could be coming from the switch we were plugged into on the providers side. Basically they have us on our own VLAN on their switch to provide the 3m connections. Yes, I am seeing them when I sh int fastethernet 0/1 etc. No ping problems.

 

[kbing]

Can u RDP or HTTP across and that works ok?

Many times you can ping all over the place but to get a simple text message on http webserver to pass won't happen.

If this works then ip fragmentation is not a problem. If this does not work then ip fragmentation would be the first place to start until it's ruled out.

 

[VinceWhirlwind]

...or ping large packets with the DNF bit set and see what comes back.

 

[kerneldead]

Yes, I can RDP and HTTP across the metro-e. Any ideas?

Thanks

 

[kbing]

I would check again with the vendor on the speed issue. If you can get everything working (seems like it is) then either the vendor doesn't have it rate limited to 3MB or one of your routers interfaces in the path may be rate limited or misconfigured. Sounds like the interfaces connected to the MetroE side are fine...what about the interfaces that connect to the LAN on each side?

 

[burtsbees]

issue "ip tcp mss-adjust 1340" on interfaces on both sides of the MetroE. If this 1340 value doesn't allow the Layer-4-7 application traffic lower the value until it works."

You mean 1260, for MTU of 1300...

/

tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!

 

[VinceWhirlwind]

...or ping large packets with the DNF bit set and see what comes back.

This will tell you exactly what size is being enforced, very quickly and simply without having to muck around with applications and guessing what performance levels are caused by the WAN.

...and if you find that instead of getting "maximum MTU size" ICMP packets back, you get nothing, then you can present that evidence to your provider as evidence of a fault on their side.

 

[burtsbees]

Yes---I was replying to a previous post about this possibly being fiber handoff, as MTU would be 1300. Setting the DF bit in the TCP header in an extended ping will definitely drop packets, at which point one finds the proper MTU setting.

This is a good idea to help troubleshoot the ongoing issues in this post. I agree.

/

tim@tim-laptop ~ $ sudo apt-get install windows
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package windows...Thank Goodness!

 

[VinceWhirlwind]

A properly configured WAN shouldn't just drop any packets on account of MTU-size - you either get a proper ping reply, or you get an MTU-size ICMP reply.
If you get "dropped" (ie, no reply at all), that means your WAN provider is non-compliant with RFC 1191 and you can officially beat them with a heavy stick.