tunnel transmit (and recieve) bandwidth statements

[Chris Ingram]

Should this command be used on a DMVPN multipoint interface (3845 router) where typically over 100 spokes have tunnels terminated?  Because the defualt is 8Mb.  All of our monitoring tools report that the mulitpoint tunnel interface is over utilized every work day.

I've looked for information about this command and pasted what I found below (which supports my question).  But I've found nothing about this in any DMPVN documentation I've seen.

tunnel bandwidth

{receive | transmit} bandwidth

receive

Specifies the bandwidth to be used to receive packets through the tunnel.

transmit

Specifies the bandwidth to be used to send packets through the tunnel.

bandwidth

Bandwidth, in kbps. Range is from 0 to 2147483647. Default is 8000.

http://www.cisco.com/en/US/docs/ios/interface/command/reference/ir_t2.pdf

[Jason Gervia]

Hello,

Tunnel bandwidth transmit and tunnel bandwidth receive are only used with RBSCP - rate based sattelite control protocol.  In the document link, in the usage guidelines, it says:

"Use the tunnel bandwidth command to specify the capacity of the satellite link."

So this doesn't apply to limiting bandwidth.

Set the 'bandwidth' command on the tunnel interface to be equal to your ISP link and see if that resolves your issue.  It won't change the throughput of  of the tunnel, but will allow more routing protocol traffic like EIGRP, which limits itself to 1/2 the defined bandwidth of the tunnel.  Hopefully your monitoring tool will see the increased bandwidth and get rid of the message for you.

If not, you need to determine what number your tool is pulling down for the 'bandwidth' of the tunnel so you can figure out why it says it's being exceeded.

Check out this link:

http://www.zdnetasia.com/clarifying-the-cisco-ios-bandwidth-command-39375724.htm

--Jason

[Chris Ingram]

Yes.  I'm familiar with how the bandwidth statement works to communicate with higher level protocols (which is what that article refers to).  But this is not the same command.  I use the bandwidth statement (in conjunction with the delay statement) to influence EIGRP in my DMVPN network because I want EIGRP to always have a better metric on my primary tunnel than the failover tunnel.

But, in this case, the tunnel bandwidth {receive | transmit} commands actually show a difference in the "show interface tunnel X" output.  Here's an example of someone else's effort to find the answer to the same question. He added these commands to his tunnel interface raising the bandwidth to 40Mbps:

tunnel bandwidth transmit 40000
tunnel bandwidth receive 40000

Then when he typed "show interface tunnel 0" it shows that exact amount of bandwidth....   Therefore, raising the question, if this does affect the bandwidth then why isn't it used on a DMVPN multipoint tunnel interface? 

http://www.cisco.com/en/US/docs/ios/interface/command/reference/ir_t2.pdf

Tunnel0 is up, line protocol is up
Hardware is Tunnel
Description: VPN site1
Internet address is 192.168.78.2/30
MTU 1514 bytes, BW 40000 Kbit

, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source xxx.xxx.xxx.xxx (FastEthernet0/0), destination
xxx.xxx.xxx.xxx
Tunnel protocol/transport IP/IP
Tunnel TTL 255
Fast tunneling enabled
Tunnel transmit bandwidth 40000 (kbps)
Tunnel receive bandwidth 40000 (kbps)
Last input 00:00:00, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 22463
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 21000 bits/sec, 17 packets/sec
5 minute output rate 41000 bits/sec, 14 packets/sec
898343729 packets input, 4132936756 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
742446090 packets output, 1496397797 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out

http://www.gossamer-threads.com/lists/cisco/nsp/61446

Also, if it's only used in the same way the "bandwidth" statement is used to communicate with upper level protocols, then why did Cisco publish documentation in July of this year stating that when used with the "transmit" keyword it is used to "set the transmit bandwidth used by the tunnel interface" and visa versa with the "receive" keyword.

http://www.cisco.com/en/US/docs/ios/interface/command/reference/ir_t2.pdf

[Jason Gervia · Accepted solution]

Chris,

1)  tunnel bandwidth is only used with RBSCP - see the usage guidelines in the documents you are posting and you will see the word 'sattelite', which indicates it's for RBSCP.  I'll see if I can get the command reference documents fixed.  Putting the commands in will change the display output, but will not actually change the transmit/receive rate unless you are using RBSCP.

2)  The second part of my message  about the 'bandwidth', was an effort o find a way to stop your  tool from reporting your tunnel (which is a virtual interface that has no *actual* bandwidth restrictions when not using rbscp) as being oversubscribed.

You'll need to work with your monitoring tool vendor to see where they are pulling the bandwidth/throughput number and how they're determining it's oversubscribed.  My best guess is they're looking at the bandwidth command/setting on the tunnel interface, but as it's a tunnel interface, that number shouldn't be used in determining whether a tunnel is 'oversubscribed'.

--Jason

[Chris Ingram]

Thanks Jason.  That helped.