Solved

Metro E connection

Posted on 2009-07-03
6
598 Views
Last Modified: 2012-05-07
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. After looking at each interface the 1841 was at 100 and the 3620 was at 10, I could not set the speed to 100 on the 3620 so I set the speed on the 1841 at 10 instead.

Here is the show interface for each BEFORE making the changes

Here is the show interface for each:

Cisco 3620:
show interface ethernet1/0
Ethernet1/0 is up, line protocol is up
  Hardware is AmdP2, address is 00e0.1e84.7671 (bia 00e0.1e84.7671)
  Description: Metro E
  Internet address is 172.16.255.13/30
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:46, output 00:00:09, output hang never
  Last clearing of "show interface" counters 14:09:57
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     855 packets input, 302050 bytes, 0 no buffer
     Received 852 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     5952 packets output, 647820 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

Cisco 1841:
show interface FastEthernet0/1
FastEthernet0/1 is up, line protocol is up
  Hardware is Gt96k FE, address is 0022.5554.42d5 (bia 0022.5554.42d5)
  Description: Metro E
  Internet address is 172.16.255.14/30
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 100Mb/s, 100BaseTX/FX
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:04, output hang never
  Last clearing of "show interface" counters 14:25:36
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 8000 bits/sec, 17 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     1090008 packets input, 65815314 bytes
     Received 1090005 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog
     0 input packets with dribble condition detected
     6149 packets output, 625872 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

I have made a few changes, but would like to see if I have covered all areas before this network starts to get a lot more traffic on it. I have included each show interface and interface configuration out put as of now. Any suggestions would be great.

Cisco 3620:
show interfaces ethernet1/0
Ethernet1/0 is up, line protocol is up
  Hardware is AmdP2, address is 00e0.1e84.7671 (bia 00e0.1e84.7671)
  Description: Metro E
  Internet address is 172.16.255.13/30
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:34, output 00:00:00, output hang never
  Last clearing of "show interface" counters 1d10h
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 1000 bits/sec, 3 packets/sec
  5 minute output rate 1000 bits/sec, 2 packets/sec
     9428 packets input, 1674660 bytes, 0 no buffer
     Received 2070 broadcasts, 0 runts, 0 giants, 0 throttles
     5 input errors, 5 CRC, 3 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     19751 packets output, 2183182 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

Cisco 1841:
show interface fastethernet0/1
FastEthernet0/1 is up, line protocol is up
  Hardware is Gt96k FE, address is 0022.5554.42d5 (bia 0022.5554.42d5)
  Description: Cox P2P
  Internet address is 172.16.255.14/30
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 10Mb/s, 100BaseTX/FX
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:45:58
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 12000 bits/sec, 24 packets/sec
  5 minute output rate 2000 bits/sec, 5 packets/sec
     63293 packets input, 4127677 bytes
     Received 57746 broadcasts, 0 runts, 0 giants, 0 throttles
     4 input errors, 4 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog
     0 input packets with dribble condition detected
     8146 packets output, 1017549 bytes, 0 underruns
     0 output errors, 0 collisions, 6 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

Here is my 1841 ethernet interface configuration:

interface FastEthernet0/1
 description Metro E
 ip address 172.16.255.14 255.255.255.252
 speed 10
 full-duplex
end

Here is my 3620 ethernet interface configuration:

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

Thanks,
0
Comment
Question by:TermEcho
  • 3
  • 2
6 Comments
 
LVL 50

Expert Comment

by:Don Johnston
Comment Utility
In the Cisco world, Ethernet means 10mbps. FastEthernet means 10 or 100mbps. Your 3620 has and Ethernet interface so it's only capable of 10mbps. However the provider switching equipment should resolve any problems with the differening speeds on your end.

That said, setting both sides to 10mbps is a good idea.

There are no errors on the first show int output but on the second the 3620 has some incoming CRC errors and the 1841 has some interface resets.

I would clear the counters and see how it looks after and hour or so.
0
 

Author Comment

by:TermEcho
Comment Utility
I have cleared the counters, but after 45minutes to an hour I started getting errors again. This connection has all types of traffic including VoiP. I currently do not have any QoS setup on these routers. Could this cause the crc errors etc? I have not gotten any errors while using a T1 instead of the Metro E. Is there anything different from a T1 vs Metro E that would handle VoiP, WWW, etc differently or does this sound like a ISP issue?

Thanks,
0
 
LVL 50

Expert Comment

by:Don Johnston
Comment Utility
What's also curious is that before you changed the speed on the 1841, you didn't show any errors.

I'd be contacting the provider.



0
Better Security Awareness With Threat Intelligence

See how one of the leading financial services organizations uses Recorded Future as part of a holistic threat intelligence program to promote security awareness and proactively and efficiently identify threats.

 

Accepted Solution

by:
BinarySvant earned 125 total points
Comment Utility
CRC errors are an issue the telcom provider needs to sort out. QoS can not be used to resolve CRC errors.
0
 

Author Comment

by:TermEcho
Comment Utility
The errors was on the providers end. Now I am not getting any input errors or CRC's but what can you do about Unknown Protocol Drops? I am getting 302 Unknown Protocol Drops. Here is my sh int:

#sh int fastethernet0/1
FastEthernet0/1 is up, line protocol is up
  Hardware is AmdFE, address is 0011.929c.9ce1 (bia 0011.929c.9ce1)
  Description: METRO-E$ETH-WAN$
  Internet address is 172.16.255.17/29
  MTU 1500 bytes, BW 3000 Kbit, DLY 100 usec,
     reliability 255/255, txload 50/255, rxload 6/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 100Mb/s, 100BaseTX/FX
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 2d17h
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: Class-based queueing
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/2/256 (active/max active/max total)
     Reserved Conversations 4/4 (allocated/max allocated)
     Available Bandwidth 660 kilobits/sec
  5 minute input rate 77000 bits/sec, 77 packets/sec
  5 minute output rate 595000 bits/sec, 101 packets/sec
     10687680 packets input, 1349958277 bytes
     Received 5044908 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog
     0 input packets with dribble condition detected
     7135644 packets output, 4018770586 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     302 unknown protocol drops
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

Thanks,
0
 

Author Closing Comment

by:TermEcho
Comment Utility
This was on the isp's side.
0

Featured Post

Why You Should Analyze Threat Actor TTPs

After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

Join & Write a Comment

We've been using the Cisco/Linksys RV042 for years as: - an internet Gateway - a site-to-site VPN device - a leased line site-to-site subnet-to-subnet interface (And, here I'm assuming that any RV0xx behaves the same way as an RV042.  So that's …
Creating an OSPF network that automatically (dynamically) reroutes network traffic over other connections to prevent network downtime.
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…

744 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

14 Experts available now in Live!

Get 1:1 Help Now