Routing

Hi Experts

I want to know the best practice to map RSVP LSP to BGP routes. I have one RSVP LSP configured between two routers say from R1 to R2. On R1,  same BGP routes are coming from R2 and some other router say R3. Due to some reasons say lowest router ID etc the BGP routes on R1 are active from R3.

So on R1, BGP routes will not pass through RSVP LSP because the protocol next hop of BGP routes should be the R2. What is the good approach to map the RSVP LSP to R2 BGP next-hop so that traffic will pass through LSP.

1- On R1, make one BGP import policy so that for routes coming from R3, it will change protocol next hop to R2

2- In the LSP configuration, put the protocol next hop of R3 using install keyword

Thanks

If you are getting same routes from R2 and R3, the better approach would be to set local-preference higher for R2 so that R1 selects R2's version of routes and would use the LSP established to R2. You can configure it in R1 as import policy.

Thanks Pavan. But lets suppose R1 is not getting the routes from R2 and R3. There are two RR. R1, R2 and R3 only neighbour with RR. In this what we have to do? I do not want to change the local preference on RR.

Thanks

ok, in that case can you do a community tagging on R2 and R3? then you can match on community at R1 and edit local-preference.

Hi Pavan Actually I tested this in my lab. What happening that RR getting the same routes from R2 and R3 and preffered the R3 routes. Now RR advertise the routes to R1 with next-hop of R3. So on R1 LSP is not mapped to these routes bcs LSP is from R1 to R2 not from R1 to R3.

Any other suggestion.

Sorry, I overlooked the RR aspect!  

I think the best way to address this is to create a LSP on R1 and have "install <prefix> active" like below

label-switched-path r1-r2 {
    to 2.2.2.2;
    install 100.1.1.0/24 active;
    no-cspf;
    primary P1;
}

Not sure if you have any ebgp peering at R1. If so, you will need an "advertise-inactive" or "mpls traffic-engineering mpls-forwarding" at R1 so that the prefix in question is advertised to your ebgp peer.

Hi Pawan

Thanks. But actually there are lot of routes coming and it is not feasible to do install active for all the routes. So in this case whats your suggestion? Should I do like this:

label-switched-path r1-r2 {
    to R2;
    install R3 ;
    no-cspf;
    primary P1;
}

Yeah, you can use. Only problem is that if there are any routes which are not common to r2,r3 (i.e given only by r3), they will also end up at r2.

Is there anyway for you to find out what are the prefixes that are common to r2&r3?  You can create a policy at r1 to install selective routes to take r1-r2 lsp.

policy-options policy-statement lsp-map

from route-filter *** <--- all common prefixes

then install-nexthop lsp r1-r2-lsp

set routing-options forwarding-table export lsp-map

Hi Pawan

Thanks for the reply. As you mentioned to configure the routing policy with forwarding table export is another solution to map the LSP to routes.

But corrent me if I am wrong. The if routes have next hop more than one LSP then in this case the above routing policy approach could help us to select the desired LSP as nexthop. If LSP is not the nexthop of routes then this will not work.

Thanks

Hi,

Sorry, I didnt understand the question properly. What do you mean by- "If LSP is not the nexthop for route"? Can you please elaborate?

Actually this is like adding a static route with nexthop, just that we are adding lsp as nexthop.

Hi Pavan

Thanks for your reply. Let me put in this way. In routing table you have like this:

* 110.110.0.0/16 next-hop LSP1

   110.110.0.0/16 next-hop LSP2

Then through routing policy and applied it in the [routing-options forwarding-table], you can change the next-hop for 110.110.0.0/16  as LSP2 instead of LSP1.

But for example you have like this in the routing table:

110.110.0.0/16 nexthop 192.168.1.2

Then it is possible to change the nexthop of this route 110.110.0.0/16 from 192.168.1.2 to LSP1 throuth the same routing poilcy? I did not test this but I think in the routing table if you do the show route 110.110.0.0/16 then it will show you still 192.168.1.2 as nexthop BUT for forwarding it will use LSP1.

Thanks

Hi,

> 110.110.0.0/16 nexthop 192.168.1.2

Assume your router learnt this route from iBGP.  When I add an lsp with install active, there will be 2 entries in the inet.0

110.110.0.0/16     *[RSVP/7/1] 00:00:04, metric 65535
                    > to 20.1.0.1  via ge-5/1/7.0, label-switched-path r1-r2

                    [BGP/170] 00:02:11, localpref 100, from 3.3.3.3

                      AS path: I
                    > to 20.1.0.1 via ge-5/1/7.0

Since RSVP has higher preference over BGP (or OSPF or RIP..),  that will be prefered and your forwarding will use LSP path.

As I explained in my earlier post, the caveat with this is that BGP route is inactive now. If you want the install route to be active *only* for forwarding, use "mpls traffic-engineering mpls-forwarding" knob. Then your BGP route will be active and your forwarding plane will show the LSP path as below..

inet.0: 84 destinations, 142 routes (84 active, 0 holddown, 0 hidden)
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both

110.110.0.0/16     @ [BGP/170] 00:02:11, localpref 100, from 3.3.3.3

                                AS path: I
                                > to 20.1.0.1 via ge-5/1/7.0

                                #[RSVP/7/1] 00:00:01, metric 2
                              > to 20.1.0.1  via ge-5/1/7.0, label-switched-path r1-r2

Hope this helps

Thanks pawan for your explaination. Actually in my last post I was not assuming to use install active key for LSP mapping. I was talking about using routing policy to change the nexthop of BGP routes from any nexthop (some IP) to LSP as nexthop and then apply this policy in [routing-options forwarding-table]. My question is that this will change the nexthop of BGP route from IP to LSP only in forwarding table or also in inet.0?

Hi,

I am sorry, I did not check the earlier "policy based" solution properly before replying. I quickly verified, and in your case policy based installation will NOT work. This is because for policy based installation JunOS does not allow any random prefix installation if nexthop does not match.

The route's nexthop (protocol nexthop) should match the LSP egress IP address. i.e if your prefix 110.110.0.0/24 is learnt from R3 and if you try to install prefix with LSP associated with R2, it will *not* work. Since you are using RR and only one version of prefix will come to your router it is not possible to use policy based approach

Can I suggest one more workaround? This time I verified and it works 🙂 Please see if you can use this as workaround

If you have 2 RRs in your network, you can configure RR1 to have local-pref set to 90 for R2 and RR2 to have local-pref set to 90 for R3. This way, both RRs will give both the versions of prefixes (with default local-pref) to your receiving router (Say R3).

Pavan@R3# run show route 220.220.0.0 logical-system R7    

inet.0: 97 destinations, 156 routes (97 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

110.110.0.0/24     *[BGP/170] 1d 05:41:55, localpref 100, from 3.3.3.3

                      AS path: 9875 I
                    > to 100.100.0.6 via ge-8/0/1.0

                    [BGP/170] 00:24:17, localpref 100, from 2.2.2.2

                      AS path: 9875 I
                    > to 100.100.0.6 via ge-8/0/1.0

[edit ]
Pavan@R3# 

Since both the version of routes are available in your router, you can now configure a policy "lsp-map" with install-nexthop lsp to-R2. 

Pavan@R3# show policy-options policy-statement lsp-map
from {
    route-filter 110.110.0.0/16 orlonger;
}
then {
    install-nexthop strict lsp r3-r2;
    accept;
}

[edit ]
Pavan@R3#

*Note* - Use "strict" keyword here. Without that, you may still end up selecting R3's version as that may be the active BGP route. "strict" will force it to use this LSP.

BTW, this will remove the other entry (of R3) from both control and forwarding plane.

Hope this helps..

WOW! This seems to be the great solution. I will test it. But if BGP route is active from R3 on R1 then offcourse R3 loopback interface is not there inet.3 becuase LSP is from R1 to R2 and consequently the route does not have LSP as next hop then still in this case we can use this forwarding policy to force LSP as next hop?? Strict keyword could you elaborate it?

Thanks