You can achieve that via below command

Vivek,

what exactly do you think you can achieve with that command? AFAIK this command is only relevant for something called the "RBSCP (Rate Based Satellite Control Protocol)". The tunnel bandwidth command seems to be somewhat underdocumented, perhaps you can provide with some new information?

---

I never configured a GRE tunnel between 2801s but between 3825s some time ago. Based on that experience I would expect at least 10 times more than your 3 Mbps. Of course this software-based routers are limited (Joseph asked for good reasons what the CPU looks like), but 3 Mbps seems to be much to low.

What about fragmentation? Remember that TCP MSS is negotiated only between the endsystems (transparent to intermediate routers) and that GRE doesn't copy the DF-bit of the original IP headers  into the GRE "transport header" by default. Have you tried if smaller MTUs in Iperf and perhaps UDP instead of TCP show better results?

HTH

Rolf

Rolf,

Pretty good point there MTU.

IP MTU 1400

IP TCP AD 1360

Check with these setup and lower or increase them with 40 bytes of difference.

I know you used iPerf, but when I don't have any other tool you can get robocopy with MT option to copy multiple files at time and check the usage again ( MT will open 8 stream at the same time ).

BTW, I'm sure both of you internet connection have more than 3M of upstream. Remember most of the time you received way much more download than upload. Just checking.

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Rolf, mentions a good point, that GRE tunnels don't copy original packet's DF by default.  Also, by default, they don't notify the sender if their DF bit is set and fragmentation is needed.  Both can be addressed by enabling PMTUD on the tunnel interface.

For a GRE tunnel, optimal IP MTU is generally MTU less 24 bytes.  (Your 100 less is Cisco's suggestion for IPSec, which has much more overhead.)

Adjust MSS is generally recommended as IP MTU less 40, for standard size IP and TCP headers, but keep in mind either or both headers can be larger than their minimal 20.  (Another reason to enable PMTUD.)

BTW, why are you using OSPF broadcast on a p2p tunnel?

Thanks for all your input. It looks like I'll have to open a case with TAC to see if they can be more forthcoming about GRE bandwidth.  

The short explanation I have found goes something like this:  A GRE Tunnel  is a virtual interface and only exists in memory and cpu with no real physical characteristics, so the tunnel performance is limited by those resources on the device.  Bigger routers have better performance.  Cisco limited GRE speed on smaller devices like my 2801 so the device would not be overwhelmed. Hence I would need to upgrade memory and then run an IOS that unlocks this feature.

Also I did apply the command you prescribed Vivek, however it only changes the speed in the show interface command and I presume what bandwidth it report up to routing protocols i.e. OSPF, EIGRP for path selection.

The link is over Verizon FIOS at both locations with the lower speed side being 50Meg.

interface Tunnel10
 description GRE_To_CPN2
 ip address 172.16.15.1 255.255.255.252
 ip mtu 1400
 ip tcp adjust-mss 1360
 ip ospf network broadcast
 ip ospf 100 area 0
 keepalive 10 3
 tunnel source FastEthernet0/1/0
 tunnel destination 172.16.5.14
end

I have seem some test with GRE tunnel with the same situation you have. I will post print screens as soon as I can but the result was even though you read the 8000 mbps the interface statistics at the bottom was giving us 2x mbps.

You need a no ip ospf network broadcast on both end.

If this generate a flap just do a IP ospf mtu-ignore and check the timers setups.

As Rolf stated there's no need for broadcast, just check mtu and timers if this bring you any problems after removin it at both end of tunnel.