[c-nsp] RSVP bandwidths > 10G

[Oliver Boehmer (oboehmer)]

Richard A Steenbergen <mailto:ras at e-gerbil.net> wrote on Wednesday,
August 20, 2008 7:14 PM:

> On Wed, Aug 20, 2008 at 04:46:53PM +0200, Oliver Boehmer (oboehmer)
> wrote: 
>> Richard A Steenbergen <> wrote on Wednesday, August 20, 2008 4:30 PM:
>> 
>>> 7600router(config-if)#ip rsvp bandwidth ?
>>>   <1-10000000>  Reservable Bandwidth (kbps)
>>> 
>>> How is one supposed to configure RSVP bandwidths greater than
>>> 10Gbps, if say for example you're doing RSVP over a 8x10G
>>> port-channel. I see the same hard-coded limitatin for RSVP
>>> bandwidth in all 7600 code, including current SRC.
>> 
>> DDTS CSCsh56847 requests to bump up the limit. I guess for now you
>> might be able to do "ip rsvp bandwidth" without an argument to have
>> the router allocate 75% of the available BW dynamically. Haven't
>> tried this on a 10GE channel though.
> 
> Yeah the docs on the subject seem to indicate that it can sometimes
> work by using percent (well I assume they meant percent, they seem to
have
> neglected the actual keyword, but I don't think they mean 100Kbps :P):
> 
>
http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_bundle_i
nterface.html
> 
> And if left to its own devices the port-channel interface DOES seem to
> find correct bandwidth values:
> 
> Port-channel1 is up, line protocol is up (connected)
>   Hardware is EtherChannel, address is 001a.6c97.cab6 (bia
>   001a.6c97.cab6) MTU 9216 bytes, BW 40000000 Kbit, DLY 10 usec,

right.

> 
> However, it doesn't look like this handles layer 3 SVIs trunked over a
> port-channel switchport, which happens to be my configuration. The
> SVIs always come up with a bandwidth of 10Gbps, no matter what
interfaces
> they are trunked to:
> 
> Vlan60 is up, line protocol is up
>   Hardware is EtherSVI, address is 0018.741f.85c0 (bia 0018.741f.85c0)
>   MTU 9170 bytes, BW 1000000 Kbit, DLY 10 usec,

I guess this is expected with SVIs, they don't follow the physical link
bandwidth (which could be a challenge if you have more than one port
associated with it).
If you need to trunk multiple p2p vlans across the channel, I'd rather
use routed subinterfaces which do inherit the proper bandwidth.
 
> 
>> TE over a channel is a challenge anyway as RSVP doesn't take the
>> actual load-sharing into account.. I.e. RSVP might allow two 8G
>> reservations which end up being hashed over the same physical port,
>> resulting in packet loss..
> 
> Wouldn't this be a function of the port-channel hash algorithm, not
> RSVP? 
> Why would RSVP know or care about the individual L2 channel members,
> other than maybe not having a configured flow size biger than the
individual
> member capacity? I suppose you'd have a tough time achieving a good
> balance if you can only hash on the mpls label and not the payload
> when doing you hash calculation, but thats another story...

Right. My point is possibly a theoretical one: If you only run MPLS-TE
over non-bundled links (i.e. all your traffic uses tunnels) and use
adequate BW reservation, everything will be "fine", CSPF/RSVP will find
the right path for your traffic and you won't oversubscribe the links
(on the above assumption). On a channel, RSVP might grant a reservation
which can't be met based on the hashing within the forwarding plane.

> FWIW this is exactly how we do multi-10G parallel links on Juniper
> today, and it signals 80G RSVP across a single L3 interface on a 8x10G
LACP
> bundle then looks inside the labels for l3/l4 payload when doing hash
> calculation damn near perfectly. :)

right, and it would also work on a Cisco, however if you end up sending
a "huge" (i.e. >10G) IPSEC/L2TP/whatever tunnel across this link, the
forwarding will hash this to a single physical port and you see drops.
This also happens without RSVP/MPLS-TE, however with MPLS-TE folks have
the expectation of "I asked for this BW, I got this BW, and I want to
use it" ;-) 
As I said: a rather theoretical case, but one which needs to be kept in
mind..

	oli