cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1601
Views
0
Helpful
9
Replies

Incoming traffic way bigger than outgoing -on bandwidth monitor-

Suwandy.Ong
Level 1
Level 1

hi,guys,please help me to solve this..

I am using numerous routers in my office, mostly 3640. We also use tunneling. The problem is, when I saw my bandwidth monitor, there's this a pair of routers acting strange.

Example, router A tunneling to router B. but on the bandwidth monitor shows that traffic going out from router A is not the same size as incoming traffic to router B, which is supposedly the same, right? The incoming traffic to router B is way bigger..

Other routers are not having this problem. Only this pair.

Someone has any idea?

Thanks

9 Replies 9

miheg
Level 5
Level 5

Normally this means that the available bandwidth is not estimated right and the percentages become unreliable.

This can be caused by a bandwidth statement on the router and it can influence what the router replies on the ifspeed question.

You may wish to see what the routers report on their interfaces.

Cheers,

Michel

Hi, Michel, thanks for your reply. Will it help if I put the result of show interface tunnel1 here?

This is for the OUTGOING router:

Tunnel1 is up, line protocol is up

Hardware is Tunnel

Description: GRE Tunnel to 5678

Internet address is b.b.b.b/30

MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,

reliability 255/255, txload 233/255, rxload 12/255

Encapsulation TUNNEL, loopback not set

Keepalive set (10 sec)

Tunnel source y.y.y.y, destination x.x.x.x

Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled

Checksumming of packets disabled, fast tunneling enabled

Last input 04:18:17, output 00:02:32, output hang never

Last clearing of "show interface" counters never

Queueing strategy: fifo

Output queue 0/0, 442229 drops; input queue 0/75, 0 drops

5 minute input rate 1061000 bits/sec, 1082 packets/sec

5 minute output rate 890000 bits/sec, 1005 packets/sec

3930397818 packets input, 2614514682 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

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

0 packets output, 151609776 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

=============================================

this is for INCOMING router:

sh int tunnel1

Tunnel1 is up, line protocol is up

Hardware is Tunnel

Description: GRE tunnel to 1234

Internet address is a.a.a.a/30

MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,

reliability 255/255, txload 10/255, rxload 7/255

Encapsulation TUNNEL, loopback not set

Keepalive set (10 sec)

Tunnel source x.x.x.x, destination y.y.y.y

Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled

Checksumming of packets disabled, fast tunneling enabled

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

Last clearing of "show interface" counters never

Queueing strategy: fifo

Output queue 0/0, 505 drops; input queue 0/75, 0 drops

5 minute input rate 1967000 bits/sec, 1944 packets/sec

5 minute output rate 916000 bits/sec, 1038 packets/sec

134259053 packets input, 3590604820 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

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

71018216 packets output, 3565475856 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

==============================================

as we can see, the bandwidth setting is the same right? Yet, the incoming traffic is way bigger than the outgoing traffic.

I am really confused...

This does tell us much, although,

You have a high number of drops in the first interface.

You may wish the try and do a simultaneous clear interface on both machines to get the picture clearer.

can you show a screenshot from the bandwidth monitor application?

Cheers,

Michel

Ok, here you are, Michel

As we can see, the incoming from mid.jpg is 3.21 M right? while Out from cyber is only 1.31 M...

I really don't get it..

Well, my knowledge of the GRE tunnels is a bit rusty so maybe what I say is not possible, but I think it might be that another tunnel also ends the tunnel interface of mid so that it's output is basically the aggregate of the traffic of each tunnel. I don't recall the commands but you can make it print a list of all "peers".

Another possibility is that the monitoring application was setup a while ago and that some changes were made to the router causing the ifIndex of the interface to change, so that it now monitors another interface. I've seen that happen a couple of times as most of these application don't notice an ifIndex change.

I see the the monitoring application only shows a gauge but no interface description like tunnel0 but maybe it is willing to tell you what ifIndex it uses and you could compare that with a show ifIndex on the router.

If it is not one of those then I'm puzzled as well. :-)

Cheers,

Michel

If it normal that both gauges scale to 1G?

I would have expected it to scale to say 100% of you ifSpeed

Michel, thank you for your replies.

It's relieving to get help somewhere.

However...

I think we solved the problem already.

I can't believe it's IOS version difference problem.

Shoot, I spent the last two days reading, testing, and got a conclusion about fragmented packets. I was pretty sure it's fragmented because I did some tests regarding the MTU... sigh.. bad diagnose..

jimmyc_2
Level 1
Level 1

We have a similar problem; the tunnel interface is 10x the amount of packets coming into the serial interface. Even with compression and overhead, this doesn't make sense, does it?

jimmyc

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco