Routing

Hello, Below is my topology.

                       r6-----r5------r1
                        |                   |
                        |                   |
                        |                   |
                       r3-----r2------r4

OPSF areas:

r1 - area 0 & 1 (NSSA)
r2 - area 0 & 1 (NSSA) , 2 (normal area)

r3 - area 2

r4 - area 1 (NSSA) 

r5 - area 0

r6 - area 0 & 2 (normal area)

RSVP paths up from r4 to r1, r2, r4 and r6 up.

I'm running LDP on these boxes (except for r2 & r5) and LDP tunneling running on these RSVP paths. I don't find the lo0 of r3 in inet.table on R4. They are running cspf. 

Any ideas pls...

Thanks

Hi,

so if you are running CSPF, you need to populate the traffic engineering database (TED) with "set protocols ospf traffic-engineering". But that's not enough. The TE LSAs are onyl flooded within a single area, so traffic engineering across ABRs does not work by default. You must either explicitely define the ABR within the EROs OR you must configure "expand-loose-hop" on every transit router. 

Cheers,

Carsten

Hello,

---

@camtable wrote:

Hi,

 

 you must configure "expand-loose-hop" on every transit router. 

 

 

---

+ mark each inter-area LSP as "inter-domain".

Last time I tested, even with "inter-domain" and "expand-loose-hop" and CSPF ON, there are further restrictions - i.e. LSP cannot fully cross area 0, like area1-->area 0---> area 2. 

In this case, disable CSPF or use strict ERO hops.

HTH

Thanks

Alex

Hello everyone.
Have similar issue, but in my case R4 doesn't built end to end to R8 LSP using LDP, and vise versa.

R8 <- (area10) -> R6 <- (area0) -> R5 <- (area20) -> R4
R8 - LDP only
R6 - LDP in area 10, RSVP in area 0.
R5 - RSVP only.
R4 - RSVP in area 20 + LDP on loopback.

Though R4 sees labels to R8 in LDP DB, but can't install it in inet.3.
Is there any other way of installing them without much pain?

Can anybody please tell me the exact LDP order of operation of how it proccess its DB and decides whether to install the route to inet.3 or not? 

One more question. Is there any other way for LDP to ignore IGP DB in its computations? 

hi ,do you got a solution for this issue ? i have a simliar issue and wanna a solution for this,

i have added the knob "inter-domain" and "expand-loose-hop" , and the LSP, ldp tunnel session is up , but the loopback route on the inet.3 is hidden.

---

@xpguan wrote:

hi ,do you got a solution for this issue ? i have a simliar issue and wanna a solution for this,

 

 

---

Add an OSPFv2 virtual link between Your ABR and every nonzero area router where You have RSVP LSP+LDP tunneling configured, and You will see LDP tunneling working between routers in different OSPF areas.

HTH

Thx

Alex

@ aarseniev

On 16.1 vMX I cannot configure a virtual link crossing a NSSA area, commit fails. However, on vSRX it is totally possible and it works fine, all the FECs get installed in all routers. Do You know if on an earlier versions of Junos for MX hardware platform this is also possbile?

Other question I have that is related to this case is on what grounds LDP selects an RSVP tunnel as a next hop in "show ldp route" ?

When I lookup LDP database on one of the routers I can see that it has learnt a LDP label over ldp-tunnelling enabled RSVP, but it does not install it into inet.3 (and hence do not advertise it to its LDP native neighbor) because in "show ldp route" I can see that LDP chose the same interface as OSPF and selected a RSVP tunnel to the nearest next-hop over that interface (a node that doesn't do LDP or tunneling). Now if I force the RSVP path with ldp-tunneling to go through the same interfaces as OSPF would - nothing changes. In "show ldp route" still the RSVP tunnel with no ldp-tunneling is selected with information:"no LDP tunneling". If I set the mteric of that RSVP lsp to let's say 100 then in "show ldp route" it dissapears, but the LSP with ldp-tunneling enabled still doesn't get selected. Now there is only interface specified in the LDP route table.

If anyone could help it would be apprecieated. If more explanation is needed, please tell me.

Hello,

---

@kr3ator wrote:

@ aarseniev

 

On 16.1 vMX I cannot configure a virtual link crossing a NSSA area, commit fails. 

---

This is correct behavior as per RFC 2328.

---

@kr3ator wrote:

on vSRX it is totally possible and it works fine, all the FECs get installed in all routers. 

---

This is incorrect behaviour and shall be eventually fixed so do not rely on that in Your designs.

---

@kr3ator wrote:

 

 

Other question I have that is related to this case is on what grounds LDP selects an RSVP tunnel as a next hop in "show ldp route" ?

 

When I lookup LDP database on one of the routers I can see that it has learnt a LDP label over ldp-tunnelling enabled RSVP, but it does not install it into inet.3 (and hence do not advertise it to its LDP native neighbor) because in "show ldp route" I can see that LDP chose the same interface as OSPF and selected a RSVP tunnel to the nearest next-hop over that interface (a node that doesn't do LDP or tunneling).

---

Again, this is correct behaviour. LDP does not have own loop preventing mechanism and relies on OSPF loop prevention. In simple words: LDP choses the same outgoing logical interface as OSPF. If that interface does not belong to LDP, then LDP does not install this route.

As for Your other experiment with forcing the RSVP path over specific interface and expecting the LDP will get tunneled - I wonder what You are trying to achieve here? LDP does not tunnel own lo0 on the RSVP ingress LSR itself. Any LDP bindings that exist beyond ingress LSR are tunneled.

Please review the topology and LDP/RSVP relationship in the below link

https://www.juniper.net/documentation/en_US/junos16.1/topics/example/vpn-ldp-over-rsvp-topology-configuring.html

HTH

Thx

Alex

Hello,

In order for r4 to consider r3's loopback, or any other address redistributed by r3, is reachable via an rsvp lsp it checks it's ospf database. The issue here is that the routes from r3 are received in r4 by an ABR and not by r3, because they are on separate areas. In this case you can use the FA's that were recommended by other users previously, this will help because you will get to see the routes directly from r3, not via an ABR, and LDP requires and IGP route to match.