Routing

 View Only
last person joined: 2 days ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
  • 1.  Route Reflectors Design for L3VPN

    Posted 01-03-2012 22:19

    Hi Experts

     

    I have 6 PE and two P MX routers. Both P routers are route reflectors. There is L3VPN service is running in my network. On route reflectors why we need any of the below:

     

    1- Rib-groups to import IGP routes in to inet.3 table

    2-  Default route in inet.3 table

    3- RSVP LSP between clients and route reflectors

     

    Thanks



  • 2.  RE: Route Reflectors Design for L3VPN

     
    Posted 01-04-2012 13:22
    Hi,

    I don't think you would require these configs unless you have changed the BGP protocol NH to SELF in RRs.

    Regards
    Surya Prakash


  • 3.  RE: Route Reflectors Design for L3VPN

    Posted 01-04-2012 15:41

     

    Hey aeroplane,

     

     The RR will NOT advertise a BGP prefix if there's not a valid next-hop for it.

     

     In other words, if your RR's do not have LSP's (either RSVP or LDP) towards the clients (e.g. they are out-of-band RRs that are NOT part of transit traffic), the next-hop for a vpn prefix, coming from a client, will be hidden (due to unusable next-hop) and won't be advertised to the rest of the network.

     

     To get around this, you can configure a static route 0/0 with a discard next-hop in inet.3 in the RRs, so that there'll always be a route for a vpn prefix's next-hop. Importing igp routes into inet.3 table would also serve the same purpose.

     

    Hope this helps,

     



  • 4.  RE: Route Reflectors Design for L3VPN

    Posted 08-18-2021 13:34
    Edited by Juniper Community Admin 08-18-2021 13:34

    Hi @Erdem and Surya

     

    Thanks for the reply. So erdems you mean if RR has VRF configured then we need these settings to install the routes. Otherwise in normal scenario if there are no VRF configured on RR there is no need these settings?

     

    Thanks

    ​​​


  • 5.  RE: Route Reflectors Design for L3VPN
    Best Answer

    Posted 01-04-2012 23:40

     

    Hello aeroplane,

     

     Not quite, actually.

     

     You would need one of tems #1 to #3 in your original question ify ou have a MPLS cloud with a bunch of PE's, acting as RR clients (e.g. no full mesh iBGP) _and_ your RR's are outside of your MPLS cloud.

     

     If your RR's are outside your MPLS cloud (meaning they don't run mpls), this would mean that their inet.3 table is NOT populated. Since that is the case, any vpn prefix advertised by a PE would have an invalid mpls next-hop, and therefore won't be advertised to other PE's, breaking your vpn traffic across PE's.

     

     In the example below, C3PO and R2D2 are two PE routers, with "vpn1" in both. OBIWAN is a route-reflector with connections to both of them, but does NOT run MPLS.

     

     R2D2  has 10.10.1.0/24 to 10.10.5.0/24 inside routing-instance vpn1

     C3PO has 172.16.1.0/24 to 172.16.5.0/24 inside routing-instance vpn1

     

     

     Since OBIWAN is not part of MPLS cloud, its output of show bgp summary will look like this: (check the hidden routes)

     

    erdems@OBIWAN# run show bgp summary 
    Groups: 1 Peers: 2 Down peers: 0
    Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
    inet.0                 0          0          0          0          0          0
    inetflow.0             0          0          0          0          0          0
    bgp.l3vpn.0           12          0          0          0          0          0
    Peer               AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Damped...
    192.168.10.1    65007         26         23       0       0        6:49 Establ
      inet.0: 0/0/0
      inetflow.0: 0/0/0
      bgp.l3vpn.0: 0/6/0 <<<<<<<<<<<<<<<< prefixes are hidden
    192.168.10.10   65007         22         27       0       0        7:34 Establ
      inet.0: 0/0/0
      inetflow.0: 0/0/0
      bgp.l3vpn.0: 0/6/0 <<<<<<<<<<<<<<<< prefixes are hidden
    
    [edit]
    erdems@OBIWAN# run show route table bgp.l3vpn hidden terse

    bgp.l3vpn.0: 12 destinations, 12 routes (0 active, 0 holddown, 12 hidden)
    Restart Complete
    + = Active Route, - = Last Active, * = Both

    A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
      192.168.10.1:1001:10.10.1.0/24               
           B 170        100             Unusable        I <<<< NH is unusable because only IGP NH is available and nothing inet.3

    erdems@OBIWAN# run show route 192.168.10.1

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

    192.168.10.1/32    *[IS-IS/18] 00:11:45, metric 10
                        > to 1.1.1.2 via fe-0/0/2.0

    [edit]
    erdems@OBIWAN#

     

     As a result, neither C3PO nor R2D2 won't be able to exchange prefix information inside vpn1 and their respective routing table will be populated by local prefixes only. See the snippet from C3PO below:

     

    erdems@C3PO# run show route table vpn terse 
    
    vpn1.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both
    
    A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
    * 123.123.123.2/32   D   0                       >lo0.1        
    * 172.16.1.0/24      S   5                        Discard
    * 172.16.2.0/24      S   5                        Discard
    * 172.16.3.0/24      S   5                        Discard
    * 172.16.4.0/24      S   5                        Discard
    * 172.16.5.0/24      S   5                        Discard
    
    erdems@C3PO#

      Now, let's configure a static default in inet.3 in OBIWAN and check the results:

     

    erdems@OBIWAN# set routing-options rib inet.3 static route 0/0 discard 
    
    [edit]
    erdems@OBIWAN# commit 
    commit complete
    
    erdems@OBIWAN# run show bgp summary 
    Groups: 1 Peers: 2 Down peers: 0
    Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
    inet.0                 0          0          0          0          0          0
    inetflow.0             0          0          0          0          0          0
    bgp.l3vpn.0           12         12          0          0          0          0
    Peer               AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Damped...
    192.168.10.1    65007         42         40       0       0       13:42 Establ
      inet.0: 0/0/0
      inetflow.0: 0/0/0
      bgp.l3vpn.0: 6/6/0    <<<<<<<<< routes are no longer hidden.
    192.168.10.10   65007         37         44       0       0       14:27 Establ
      inet.0: 0/0/0
      inetflow.0: 0/0/0
      bgp.l3vpn.0: 6/6/0    <<<<<<<<< routes are no longer hidden.
    
    [edit]
    erdems@OBIWAN# 

     

       Also, routing table for vpn1 in both C3PO and R2D2 now have prefixes from other PE's too:

     

    vpn1.inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
    + = Active Route, - = Last Active, * = Both
    
    A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
    * 10.10.1.0/24       B 170        100            >2.2.2.1         I  <<<<<<
    * 10.10.2.0/24       B 170        100            >2.2.2.1         I <<<<<<
    * 10.10.3.0/24       B 170        100            >2.2.2.1         I <<<<<<
    * 10.10.4.0/24       B 170        100            >2.2.2.1         I <<<<<<
    * 10.10.5.0/24       B 170        100            >2.2.2.1         I <<<<<< There are coming from R2D2
    * 123.123.123.1/32   B 170        100            >2.2.2.1         I
    * 123.123.123.2/32   D   0                       >lo0.1        
    * 172.16.1.0/24      S   5                        Discard
    * 172.16.2.0/24      S   5                        Discard
    * 172.16.3.0/24      S   5                        Discard
    * 172.16.4.0/24      S   5                        Discard
    * 172.16.5.0/24      S   5                        Discard

     

     I hope this answers your question.

     

     Cheers,

     Erdem



  • 6.  RE: Route Reflectors Design for L3VPN

    Posted 01-04-2012 23:54

    Thank you very much . Great Explaination!



  • 7.  RE: Route Reflectors Design for L3VPN

    Posted 02-23-2013 21:45

    we can achive the goal by changing default resolution behavior of JunOS ie.

     

    set routing-options resolution rib bgp.l3vpn.0 resolution-ribs [inet.3 inet.0]