cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1003
Views
5
Helpful
8
Replies

Input errors between PE - P

enriquebs
Level 1
Level 1

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.

8 Replies 8

enriquebs
Level 1
Level 1

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,

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
Level 5
Level 5

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

regards

shivlu

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".

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

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,

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!

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: