Input errors between PE - P

Unanswered Question
Nov 6th, 2007
User Badges:

Hi,


Here is the picture: two multimode direct fibers between PE - P


We are trying to figure out what is causing these erros. No physical issue, we changed both fibers and Gbics...

Here are the "sh int" outputs:


PE#sh int gi0/0

GigabitEthernet0/0 is up, line protocol is up

Hardware is Pinnacle GE, address is 0015.2bc1.7a00 (bia 0015.2bc1.7a00)

Description: "LAN-1"

Internet address is 10.9.128.162/29

MTU 1508 bytes, BW 1000000 Kbit, DLY 10 usec,

reliability 255/255, txload 1/255, rxload 6/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 1000Mb/s, link type is auto, media type is SX

output flow-control is unsupported, input flow-control is unsupported

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 never

Input queue: 1/75/154/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: Class-based queueing

Output queue: 0/40 (size/max)

5 minute input rate 26443000 bits/sec, 3260 packets/sec

5 minute output rate 826000 bits/sec, 757 packets/sec

62874619 packets input, 69579981142 bytes, 0 no buffer

Received 13516 broadcasts (12963 IP multicast)

0 runts, 0 giants, 8 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 13515 multicast, 0 pause input

9740618 packets output, 5499966337 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 PAUSE output

0 output buffer failures, 0 output buffers swapped out


PE#sh int gi2/0

GigabitEthernet2/0 is up, line protocol is up

Hardware is Pinnacle GE, address is 0015.2bc1.7a40 (bia 0015.2bc1.7a40)

Description: "LAN-2"

Internet address is 10.9.128.170/29

MTU 1508 bytes, BW 1000000 Kbit, DLY 10 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 1000Mb/s, link type is auto, media type is SX

output flow-control is unsupported, input flow-control is unsupported

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 never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: Class-based queueing

Output queue: 0/40 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 1789000 bits/sec, 927 packets/sec

27669 packets input, 2470375 bytes, 0 no buffer

Received 22503 broadcasts (30345 IP multicast)

0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 22502 multicast, 0 pause input

12522447 packets output, 9128204929 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 PAUSE output

0 output buffer failures, 0 output buffers swapped out


The "P" outputs are in the next post, no space here.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
enriquebs Tue, 11/06/2007 - 23:48
User Badges:

Here are the "P" outputs:


P#sh int gi1/1

GigabitEthernet1/1 is up, line protocol is up (connected)

Hardware is C6k 1000Mb 802.3, address is 0015.c674.6480 (bia 0015.c674.6480)

Description: LAN-1

Internet address is 10.9.128.161/29

MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

reliability 255/255, txload 6/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 1000Mb/s, media type is SX

input flow-control is off, output flow-control is off

Clock mode is auto

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:04, output 00:00:00, output hang never

Last clearing of "show interface" counters 09:09:59

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Packet Drop strategy: random early detection (DWRED)

Output queue: 0/40 (size/max)

5 minute input rate 855000 bits/sec, 763 packets/sec

5 minute output rate 26529000 bits/sec, 3249 packets/sec

L2 Switched: ucast: 5844 pkt, 409196 bytes - mcast: 11129 pkt, 960180 bytes

L3 in Switched: ucast: 9745644 pkt, 5540218698 bytes - mcast: 0 pkt, 0 bytes mcast

L3 out Switched: ucast: 62884542 pkt, 70124129829 bytes mcast: 0 pkt, 0 bytes

9764197 packets input, 5541857121 bytes, 0 no buffer

Received 12792 broadcasts (0 IP multicast)

0 runts, 0 giants, 0 throttles

3004616 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 0 multicast, 0 pause input

0 input packets with dribble condition detected

62889284 packets output, 69863793399 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 PAUSE output

0 output buffer failures, 0 output buffers swapped out


P#sh int gi2/1

GigabitEthernet2/1 is up, line protocol is up (connected)

Hardware is C6k 1000Mb 802.3, address is 0015.c674.6480 (bia 0015.c674.6480)

Description: LAN-2

Internet address is 10.9.128.169/29

MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

reliability 248/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 1000Mb/s, media type is SX

input flow-control is off, output flow-control is off

Clock mode is auto

ARP type: ARPA, ARP Timeout 04:00:00

Last input 00:00:01, output 00:00:00, output hang never

Last clearing of "show interface" counters 09:12:06

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Packet Drop strategy: random early detection (DWRED)

Output queue: 0/40 (size/max)

5 minute input rate 1672000 bits/sec, 941 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

L2 Switched: ucast: 5862 pkt, 410276 bytes - mcast: 11290 pkt, 1002420 bytes

L3 in Switched: ucast: 12556198 pkt, 9184360197 bytes - mcast: 1122 pkt, 107686 bytes mcast

L3 out Switched: ucast: 0 pkt, 0 bytes mcast: 8397 pkt, 791838 bytes

12575958 packets input, 9186038853 bytes, 0 no buffer

Received 14636 broadcasts (960 IP multicast)

0 runts, 0 giants, 0 throttles

5349221 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 0 multicast, 0 pause input

0 input packets with dribble condition detected

27594 packets output, 2571230 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 PAUSE output

0 output buffer failures, 0 output buffers swapped out


There are lots of input errors just in the P interfaces... we are running out of ideas about what is going on...


Thanks,

shivlu jain Wed, 11/07/2007 - 03:54
User Badges:
  • Silver, 250 points or more

This interface has had 5349221 'Input errors'. An input error includes runts,

giants, no buffer, CRC, frame, overrun, and ignored counts. Other input-related

errors can also cause the input error count to be increased. Some datagrams can

have more than one error. Therefore, this sum may not be equal to the sum of

enumerated input error counts.

shivlu jain Wed, 11/07/2007 - 03:55
User Badges:
  • Silver, 250 points or more

in pe you are having MTU 1508 and P MTU is 1500. This may solve your problem.


regards

shivlu


enriquebs Wed, 11/07/2007 - 04:01
User Badges:

Well... in that output is not showed, but the P has set the MTU with "tag-switching mtu 1508". Both devices have "IP MTU 1500".


william.caban Wed, 11/07/2007 - 08:28
User Badges:

If you change your MPLS MTU make sure you modify the interface MTU accordingly. Example, if you set your MPLS MTU to 1508 you should setup your P interface to an MTU equal or grater than 1508.


Hope this helps.


-William

enriquebs Wed, 11/07/2007 - 23:21
User Badges:

So... as far as I can understand my configuration is wrong, because:


mtu 1508

mpls mtu 1508

ip mtu 1500 <-- It should be 1508


By the way, anyone know the difference between that kind of MTUs? I have some documents but nothing clear enough


Thanks,

enriquebs Thu, 11/08/2007 - 00:08
User Badges:

So... I think I am a little closer to the light (maybe this expression makes no sense in English :S) anyway, here we go:


mtu (i.e mtu 1508)

This is the standar MTU in a GigabitEthernet interface. It is set in the global interface (i.e gi0/0). 1500 from Data, 6 from Destination Address, 6 from Source Address, 4 from FCS.

We have 1508 configured in all our MPLS interfaces, so... we are wrong! Is the right configuration 1518? I mean "mtu 1518"


ip mtu (i.e ip mtu 1500)

Well, that the maximum permitted in a GigabitEthernet interface and deals only with the Data portion, if the Data portion is bigger than 1500 it is going to be fragmented.


mpls mtu

When we have a frame bigger than mtu configured in the interface that fragment is not ruled out, in other words, it is checked against mpls mtu in order to know whether it is an MPLS packet (which included 4 bytes tags per VPN).


So... according ti our configuration...


mtu 1508

ip mtu 1500

mpls mtu 1508


looks wrong to me! It should be:


mtu 1518

ip mtu 1500

mpls mtu 1526 (we are going to carry two VPNs, so... 1518 + 4 + 4)


What do you think?


By the way, if 1500 is the maximum IP MTU permitted in a GigabitEthernet interface why can I configure until 1530 on my box?


Thanks a lot!

william.caban Thu, 11/08/2007 - 04:56
User Badges:

If you are a carrier, since you may have multiple stacked headers from your clients, the minimum recommended is 1568. I can not find the Cisco document where I found the full calculations but the number covers the scenarios 1500+L2TPv3 or 1500+Multisite VPNs (GRE+IPSec) or 1500+IPSec+QinQ on the client side. But again, you will need to add the MPLS VPN+MPLS TE+etc, headers.


My personal preference is to setup the uplink interfaces to Jumbo Frames or the maximum of the chassis. For example, MTU 9216 in the newer equipment and MTU 9000 in the devices that support old Jumbo definition.


With the Jumbo frames, then, globally activate the "ip tcp path-mtu-discovery".


If you do that, you will see that even your OSPF and BGP sessions send less packets during convergence. (Because they can pack more routes in less packets). Which is translated into faster convergence on huge routing tables. Something very much appreciated in any carrier network.


Also, I've seen that with the ip tcp path-mtu-discovery, in the 6500s and 7600s platforms, the MPLS MTU is set to the interface's MTU. So if you set it to 9216 your MPLS MTU will be 9216.


I haven't verify this in the smaller routers but I figure it should be the same.


In terms of the client perspective, they will always see their 1500 Bytes packets going by, no matter what combination of headers they use.



-W

Actions

This Discussion