1. RSVP reservations are just that - reservations. They don't actually police/shape/take away available bandwidth on the interface for other traffic.
LSPs ask for bandwidth reservations so that further/additional LSPs don't attempt to book their bandwidth on this interface if it's full. (See RSVP-TE) 2. Given no CoS on the LSP, and using the default JunOS Shapers; Network Control traffic (Queue 3 or Queue 7 depending on your device) will always have 5% of the available bandwidth/buffer space, regardless of the traffic on the LSP. This is the Juniper default. In other words, you can book the interface to 100% of line rate without having to worry about network control traffic getting starved. In fact, using the 'oversubscription' flag under RSVP, you can overbook the interface as much as you want (i.e. 400% = Sell 4Gig of services down a single 1G interface - and hope that all 4 LSPs don't try to use it at the same time). I don't see the advantage in keeping 2.5 Gigabit/sec of bandwidth for "control plane" traffic on a 10G link. =) - Chris. On 2011-09-13, at 3:42 PM, medrees wrote: > Dear Experts > > > > I'm wondering from the default behavior of RSVP in Juniper routers > (By default, RSVP allows 100 percent the bandwidth for a class type to be > used for RSVP reservations.) while other vendors like Cisco by default > reserve only 75% and keeps 25% for the control plane traffic (routing, L2 > protocols messages..) giving them the highest priorities (Priority 6, or 7) > and that is logic. > > > > so that what will juniper routers do for the control plane traffic if the > RSVP consumed the full 100% of the links? > > > > Thanks in advance > > > > Best Regards, > > Mohamed Edrees > > > > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
