The tunnel headend is configured at R2 and the tailend was R1. The first tunnel that was setup was of 50 Meg ( which got successfully setup as expected ).The second tunnel that i tried to setup was of 700 Meg from R2 towards R1. As expected the tunnel didnt establish because of the bottleneck at R3_1/0 ( this interface has only 50 Meg left ). But there was one thing that i noticed. R2 had still sent a Path message towards R3 with the destination ip of R1. THe moment R3 received this message, it rejected the path message with Admission control error ( as it couldnt support the requested bandwidth on 1/0 interface ) and sent Path error message back to R2. This is something that i was not expecting. I can see in the TED on R2 that R3 had already updated its G1/0 now has only 50Meg remaining. I thought that R2 ( headend ) should be referring to this first to see if the tunnel can be setup by staisfying all the constraints. Once it knows that the bandwidth is not available, it should not send any path messages.

shreerampardhy · ‎01-02-2013

Hello All,

The below query is regarding the RSVP path messages that are sent from the head end towards the tail.

I have got below setup

R1(1/0) --------- (1/0) R3 (3/0)------------- (1/0) R2

The interface 1/0 on R3 has got a total rsvp reservable bandwidth of 100 Meg. While R1 and R2 interfaces have got the default value of 750 Meg ( all the interfaces are gig interfaces ).

All the tunnels are being setup by using the explicit path option.

The tunnel headend is configured at R2 and the tailend was R1. The first tunnel that was setup was of 50 Meg ( which got successfully setup as expected ).The second tunnel that i tried to setup was of 700 Meg from R2 towards R1. As expected the tunnel didnt establish because of the bottleneck at R3_1/0 ( this interface has only 50 Meg left ). But there was one thing that i noticed. R2 had still sent a Path message towards R3 with the destination ip of R1. THe moment R3 received this message, it rejected the path message with Admission control error ( as it couldnt support the requested bandwidth on 1/0 interface ) and sent Path error message back to R2. This is something that i was not expecting. I can see in the TED on R2 that R3 had already updated its G1/0 now has only 50Meg remaining. I thought that R2 ( headend ) should be referring to this first to see if the tunnel can be setup by staisfying all the constraints. Once it knows that the bandwidth is not available, it should not send any path messages.

Any idea if i missed out on anything?

Regards,

Shreeram

RSVP path message query