8

We're using VPLS and L2VPN on Juniper MX for L2 connections. Signaling is done via BGP and label distribution via LDP.

Now we want one L2VPN to use a specific path trough the network and not follow the IGP.

As we currently only use LDP we would have to introduce RSVP alongside LDP. Are there any caveats while doing that?

I'm looking for practical examples how this is done on the Juniper boxes.

Sebastian Wiesinger
  • 8,107
  • 3
  • 34
  • 60

1 Answers1

8

Short answer, just use Resource ReSerVation Protocol (RSVP).

Long answer, you could use multi-topology-routing and have multiple metrics in each interface and force some packets to different topology than another packets. But I would not really venture there.

You might want to talk to your account team that you want segment routing implemented: https://datatracker.ietf.org/doc/html/draft-previdi-filsfils-isis-segment-routing-02 (customer pressure will help resource development)

Segment routing would make it trivial to solve your problem while removing both LDP and RSVP from your network, relying only on IGP.


As my suggestion in comments did not actually work, I'll explain why not, and how to fix.
Problem is we need to have LSP installed in HW to be able to use it. And by my suggestion the RSVP LSP is not actually installed until LDP LSP goes away. So we cannot conditionally inject traffic there.

I couldn't find any way to force RSVP+LDP in ECMP, with equal preference LDP wins. But we still can achieve what is desired at least in two separate ways.

  1. Dual next-hops
    Add second next-hop in the l2circuit PEs. This next-hop will not be used by iBGP, so it draws no traffic at all.
    Now configure RSVP tunnel for this second loopback and use it as neighbor address for l2circuit.
    Net effect is, all traffic is using LDP except this l2circuit which is using RSVP
  2. RSVP only
    Create two RSVP tunnels, one using IGP path (i.e. will use same as LDP) another using your explicit path. These can be set to ECMP, i.e. all traffic will use both tunnels.
    Now as we've accomplished ECMP requirement, we can use 'routing-options forwarding-table' export policy to put some traffic on LSP_NORMAL and some traffic on LSP_EVPN. Essentially our export policy would be:

.

term EVPN {
    from community EVPN;
    then {
        install-nexthop lsp LSP_EVPN;
        accept;
    }
}
term NORMAL {
    from next-hop 1.2.3.4;
    then {
        install-nexthop lsp LSP_NORMAL;
        accept;
    }
}

Now none of the traffic would actually use the ECMP as all of the traffic would be forced to one or the other RSVP LSP.
I would prefer the 1st option.

ytti
  • 9,776
  • 42
  • 53
  • Okay, when I need to use RSVP I should perhaps rephrase the question on how I can do it with RSVP – Sebastian Wiesinger May 16 '13 at 12:18
  • 1
    This should point the way:http://kb.juniper.net/InfoCenter/index?page=content&id=KB22700&smlogin=true - essentially create RSVP tunnel, use community to discriminate what traffic enters it – ytti May 16 '13 at 12:35
  • Yes but wouldn't the other l2vpn instances also prefer the RSVP lsp instead of the LDP signalled one? – Sebastian Wiesinger May 16 '13 at 13:31
  • For that you use 'community' per l2circuit. You could make LDP the default then give specific 'community' in eahc l2circuit which needs to choose RSVP – ytti May 21 '13 at 14:18
  • Okay, HOW do I make LDP the default? :) – Sebastian Wiesinger May 21 '13 at 16:22
  • 1
    Make the RSVP tunnel preference greater than 9. 'set protocols mpls label-switched-path EVPN-BACKUP preference 10.' – ytti May 22 '13 at 07:00
  • 1
    Just a note, this seems not to work. When I give the RSVP a higher preference the label doesn't get installed in the mpls table and the path does not come up (l2circuit reports "OL" -> No outgoing label) – Sebastian Wiesinger Jul 01 '13 at 11:27
  • 1
    You're right. With higher preference it does not get installed in HW at all (show route forwarding-table matching EGRESS/32), so it cannot be accepted by forwarding-table export. I tried to think of solution to get both installed and RSVP used conditionally but drew black. One solution would be, to add another loopback for RSVP, which you only use for this, then you do the l2circuit towards the new 'RSVP loopback'. This way rest of the prefixes use the LDP loopback label and this one uses RSVP loopback labels. No need for community+forwarding-table export. – ytti Jul 01 '13 at 12:28
  • Yes, that is the same conclusion I came up with. Seems there is no way around it... – Sebastian Wiesinger Jul 01 '13 at 14:23
  • So, I did that and even now it will not work. The directed LDP session for the l2circut on the lo0 interface does not come up (the LDP session flaps). Traceoptions show that the other end tries to connect to the new (RSVP-Only) loopback IP via LDP (because that is the neighbor address in the l2circuit statement) but the router answers from its primary lo0 IP addresss... – Sebastian Wiesinger Jul 02 '13 at 09:23
  • Okay, I tried to establish the l2circuit with the primary lo0 addresses, which worked. I then tried to force the transport label to the RSVP path with the "install-next-hop lsp " but that is ignored completely. The transport label is still the LDP path to the primary loopback address of the other router. – Sebastian Wiesinger Jul 02 '13 at 09:57
  • And to conclude this: I couldn't get it working, so I switched to CCC "connections" and just configured a remote-interface-switch which directly specifies the incoming/outgoing RSVP LSPs for the connection. This seems to work. – Sebastian Wiesinger Jul 02 '13 at 10:24
  • 1
    I think you would have needed 'psn-tunnel-endpoint', http://www.juniper.net/techpubs/software/junos/junos85/swconfig85-vpns/id-12217017.html – ytti Jul 02 '13 at 11:39
  • Again, I have to thank you. I actually looked at this but I couldn't figure out the meaning. I find that documentation somewhat unclear. Thanks again, that totally works! – Sebastian Wiesinger Jul 02 '13 at 13:52