Please be aware that if you are using multiple parallel links, in some
corner cases, you will create a RSVP error loop messages as seen in our
network and documented in PR 485509. Fortunately, there is already a
enhancement for this problem in junos 8.5S6.
I would suggest using link aggregation if
On Thu, May 06, 2010 at 02:44:25PM -0400, Phil Bedard wrote:
>
> It always adjusts the link agg RSVP interface bandwidth based on up
> member links unless you have it set statically. You do run into a
> problem however if you do not have aggressive session preemption
> turned on since the RSVP in
On May 6, 2010, at 10:42 AM, Richard A Steenbergen wrote:
>
>
> One big problem with link agg is that Juniper has no way to adjust the
> RSVP bandwidth of a bundle based on the actual capacity, so for example
> if you have a 60G bundle and you lose a 10G member (or two) RSVP will
> continue tryi
On Thu, May 06, 2010 at 03:09:20PM +1200, Kris Price wrote:
> Hi all,
>
> The subject is using link aggregation with RSVP. Or just generally the
> subject of how best to handle multiple parallel links between adjacent
> routers in a MPLS network. I'm hoping the list can provide guidance on
> th
Hi Kris,
Link aggregation is generally a good idea with RSVP. It's easier to
pack LSPs into one big chunk of bandwidth than to pack into multiples
of smaller bandwidths.
You'll need to turn on aggressive pre-emption as this enables the
transit LSR to signal ingress LSRs to move LSPs off a link w
Hi all,
The subject is using link aggregation with RSVP. Or just generally the
subject of how best to handle multiple parallel links between adjacent
routers in a MPLS network. I'm hoping the list can provide guidance on
the best practise for this, or point me to useful material.
The context
6 matches
Mail list logo
