Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 632
  • Last Modified:

Metro E connection

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
TermEcho
Asked:
TermEcho
  • 3
  • 2
1 Solution
 
Don JohnstonCommented:
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
 
TermEchoAuthor Commented:
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
 
Don JohnstonCommented:
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
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
BinarySvantCommented:
CRC errors are an issue the telcom provider needs to sort out. QoS can not be used to resolve CRC errors.
0
 
TermEchoAuthor Commented:
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
 
TermEchoAuthor Commented:
This was on the isp's side.
0

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now