MPLS-TE : some question

[Marcofbbr]

Hi,

I'm studing for MPLS exam and after reading the documentation some aspects about MPLS-TE are still not clear .

I hope you can help me to clarify some concepts:

1)Is RSVP a requirement on every router link of the ISP when we are using dynamic tunnel computation considering that a tunnel could change his path?

2)Is Constrant-based routing(CBR)used when the tunnel is configured using an explicit path?

[Giuseppe Larosa]

Hello Marco,

MPLS TE are unidirectional and also RSVP reservations are unidirectional.

Said this the answers are:

1) yes an alternate path can be used only if it has enough RSVP resources to satisfy the requests in the RSVP tunnel setup message.

resources are consumed outbound towards destination node

2) yes every possible path dynamic or explicit uses constrained based routing that means takes in account resources and resource current usage.

For this reason an MPLS TE with only a path option describing an explict path will fail if not enough resources are available on one of the specified links on the path

Hope to help

Giuseppe

[Marcofbbr]

Thanks for your reply.

About question 1 again:

Must RSVP parameters be configured on each link used by tunnel path?

What happens if the configuration of RSVP is not contiguous?

For QoS, if I remember correctly,both RSVP and non-RSVP routers forward RSVP messages towards the destination address but I think with MPLS-TE the non-RSVP router/link could break the TE LSP tunnel.

Salutami Tizzoni!

[vijaykumarArumugam]

Hi,

The Router which detects a non-RSVP 'router' will send path error message with value "MPLS being negotiated, but a non-RSVP-capable router stands in the path". If RSVP packet is received on non-RSVP link, it'll be dropped and if it's to be sent via a non-RSVP link, it'll send error with value "No route available toward destination" (not exactly sure about the exact error message).

Non-RSVP-Capable router is detected by comparing ip header ttl value with RSVP header "send ttl" value. Non-rsvp routers forward rsvp messages without processing it, so the "send ttl" value will not be decremented.

vijay

[Marcofbbr]

So....from you answer i gather that RSVP configuration is mandatory on each possibile TE link to have a working MPLS-TE architecture.

Please confirm.

Thanks for the detailed explanation

[vijaykumarArumugam · Accepted solution]

Yep, RSVP configuration is mandatory.

In Cisco, configuring "mpls traffic-eng tunnels" on a link will enable mpls as well as RSVP-TE (but with zero rsvp bandwidth). There is no separate cli to enable RSVP. "ip rsvp bandwidth " lets u decide the bandwidth to be allocated.

[Marcofbbr]

Really interesting,

so a tunnel is unusable until bandwidth is allocated with "ip rsvp bandwidth "

Thanks for the information!

[vijaykumarArumugam]

Nope, you can still signal tunnels for which bandwidth reservation is not needed. By default, tunnel's bandwidth is set to zero (unless you configure bandwidth for the tunnel "tunnel mpls traffic-eng bandwidth ").

i.e. RSVP message which requests for zero bandwidth will be admitted. All other non-zero bandwidth reservations will fail.

[devang_etcom]

Hi Marcofbbr,

If you will not configure IP RSVP BANDWITDH command then there will not be any reservation for bandwidth so technically your tunnel will not come up at all. and If you have configured IP RSVP BANDWIDTH and forgot to configure bandwidth value then it will assign 75% of the bandwidth for reservation.

mpls traffic-eng tunnel on global config and interface configuration mode will enable the MPLS traffic engineering support on router as well as interface.

thanks,

Devang Patel

[ciscoguy]

Hello,

I am confused, if I don't enter the following command under the tunnel interface :

tunnel mpls traffic-eng bandwidth

but configure IP RSVP bandwidth command, what will the bandwidth requirement to setup this tunnel, or if the tunnel is up what bandwidth will it be alloted ?

Thanks,

[Harold Ritter]

zohebsarwar,

If you don't include the bandwidth on the tunel interface then no bandwidth will be reserved. Bear in mind that MPLS TE is not only used for bandwidth reservation. In fact most customer I have helped deploying MPLS TE was for fast reroute (FRR), in which case you don't necessarily care about bandwidth reservation.

Regards

[ciscoguy]

Speaking or FRR, I have another question :)

I have a circular topology( hub on the top) and Primary one hop tunnels to the adjacent left & right node. I also have backup tunnels to these left & right nodes through the opposite direction (for FRR).

My question is will the backup tunnel will ever be used to forward traffic, whereas another primary path exist for the same node to reach the hub through the other side of the ring? If not that what is the purpose of backup tunnels in this scenario.

Thanks,

[tarjeet85]

yes it is compulsory to configure RSVP on each interface of each backbone router. TE tunnel find automaticaly or explict path with reserve bandwidth as you have define in tunnel interface.

so tunnel will only able to get this bandwidth if backbone router have enough reserved bandwidth in RSVP to allocate.

for example R1--->R2--->R3--->R4--->R5

srs R1 to dest R5

if RSVP badwidth is not configured on R3 then ur tunnel1 cannot go accross this path it has to find new path.