RR and L3 VPNs

IOS2JUNOSIOS2JUNOS Member Posts: 56 ■■□□□□□□□□
hi all- trying to figure out what are some of the ways to get vpn to work when only peering with RR.
1. setup LSP from RR to PE
2. add a route in inet.3 (found this on a website)
routing-options {
rib inet.3 {
static {
route 0.0.0.0/0 discard;
}
}
}


is there another way? thanks

Comments

  • hoogen82hoogen82 Member Posts: 272
    That would be it... 2nd one is a nice solution..
    IS-IS Sleeps.
    BGP peers are quiet.
    Something must be wrong.
  • IOS2JUNOSIOS2JUNOS Member Posts: 56 ■■□□□□□□□□
    hoogen82 wrote: »
    That would be it... 2nd one is a nice solution..

    thanks..generally staic routes are not allowed in the lab..would the 2nd solution be an accectable solution in case you run into this situation?
  • hoogen82hoogen82 Member Posts: 272
    I think you can always check with the proctor... This isn't exactly like a static route solution...
    IS-IS Sleeps.
    BGP peers are quiet.
    Something must be wrong.
  • zoidbergzoidberg Member Posts: 365 ■■■■□□□□□□
    i agree with hoogen82 there.

    if you wanted another option, instead of manually building rsvp lsps to the rr, turn ldp on everywhere... assuming it's use is not restricted. it will automatically build up the lsps that you need and the rsvp paths will still be preferred. maybe not the best option, but it is quick and effective. just set protocols ldp interface all on all the routers.

    another advantage of ldp everywhere, it can handle the return traffic for your rsvp lsps saving you time over building bi-directional rsvp lsps. again, this is something that would be exam specific and something to check with the proctor. perhaps the wording says you need to build a rsvp lsp from A to Z and another from Z to A, and maybe it doesn't require you to build a rsvp lsp the other way. this isn't really a best practice implementation either, but just another option that could save you a number of minutes if you're cramped for time.
  • IOS2JUNOSIOS2JUNOS Member Posts: 56 ■■□□□□□□□□
    cool..thanks guys!!
  • darry9502darry9502 Member Posts: 12 ■□□□□□□□□□
    hoogen82 wrote: »
    I think you can always check with the proctor... This isn't exactly like a static route solution...

    It depends on how one looks at it. IOS2JUNOS view the 2nd option as static route as the way to configure it is similar to static route. Hoogen viewed it differently as it is configured under the inet.3 table.

    Try using rib-groups igp-rib to import the IGP routes into the inet.3 table. There is an articule in Juniper documentation that mentioned this solution, it may be what you are looking for if you are concerned with points loss that is linked to static route.

    So plus zoidberg's LDP method (which is a common way of doing in ISP), you have a total of 4 sets of solution to the RR L3VPN scenario. This give you another headache of which is the BEST one to use :)

    Hmmm, I suggest you spend more time on your JNCIP topics and good luck.
  • high1432007high1432007 Member Posts: 37 ■■□□□□□□□□
    Darry, did you pass JNCIE-M?
  • darry9502darry9502 Member Posts: 12 ■□□□□□□□□□
    Darry, did you pass JNCIE-M?

    This question looks irrelevant to this solution. I did managed to pass JNCIE-M in my second attempt.

    I lost points in the IGP section during my first attempt. The JNCIE-M is a well thought out exam, much tougher than the CCIE R&S which i done 9 years ago.

    That's why it is recommended to go through more scenarios on the JNCIP topics as the troubleshooting is the real killer. Imagine that you need to solve one problem in order to generate the next problem, you really need to be tactful about the whole ideas.

    Whatever it is, it is a doable exam, just like ccie. Cheers and good luck to those attempting it.
  • octobrazoctobraz Registered Users Posts: 3 ■□□□□□□□□□
    IOS2JUNOS wrote: »
    hi all- trying to figure out what are some of the ways to get vpn to work when only peering with RR.
    1. setup LSP from RR to PE
    2. add a route in inet.3 (found this on a website)
    routing-options {
    rib inet.3 {
    static {
    route 0.0.0.0/0 discard;
    }
    }
    }


    is there another way? thanks

    Please can someone explain the 2nd solution to me? I cant seen to be able to relate the challenge with RRs & L3VPNs...

    Thanks...
  • agangulyaganguly Registered Users Posts: 1 ■□□□□□□□□□
    the best way to resolve this issue is to configure

    set routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0 if LDP is not allowed.
  • fakhir2005sfakhir2005s Registered Users Posts: 2 ■□□□□□□□□□
    What If there is no restriction in place for using either LDP or entry in inet.3.
    what is the best way of doing this either use LDP or make following entry in inet.3
    set routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0
  • AldurAldur Member Posts: 1,460
    What If there is no restriction in place for using either LDP or entry in inet.3.
    what is the best way of doing this either use LDP or make following entry in inet.3
    set routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0

    I prefer using LDP if that's an option. I can see adding in a default route in any form causing potential problems in a real network.
    "Bribe is such an ugly word. I prefer extortion. The X makes it sound cool."

    -Bender
  • fakhir2005sfakhir2005s Registered Users Posts: 2 ■□□□□□□□□□
  • RabeenZhuRabeenZhu Member Posts: 16 ■□□□□□□□□□
    IOS2JUNOS wrote: »
    hi all- trying to figure out what are some of the ways to get vpn to work when only peering with RR.
    1. setup LSP from RR to PE
    2. add a route in inet.3 (found this on a website)
    routing-options {
    rib inet.3 {
    static {
    route 0.0.0.0/0 discard;
    }
    }
    }


    is there another way? thanks
    I guess only peer with RR, means the PE speakers only peer with the RR.
    This question has been asked for a while, and some experts already answered this question,
    I have a question for a long time,
    I am curious, no one else point out,
    Am I wrong?
    Here is the question:
    for the L3 VPN, of course here I mean the Intra-domain L3VPN,
    ALL BGP sessions are IBGP,
    IBGP dont change next-hop, include the RR reflected routes,
    NH not changed, LSP not changed.
    which means, use RR or not,
    what you need to configure is the PE to PE LSP,
    no need for PE-RR lsp.

    By the way, the inner laber does not change as long as BGP next-hop not change,
    so RR is only on the control plane (sure it is possible it is also on the data plane)

    If I am wrong, please let me know my friends.

    Regards,

    RabeenZhu
  • RabeenZhuRabeenZhu Member Posts: 16 ■□□□□□□□□□
    Aldur wrote: »
    I prefer using LDP if that's an option. I can see adding in a default route in any form causing potential problems in a real network.
    Looking forward for your reply Aldur :)
  • RabeenZhuRabeenZhu Member Posts: 16 ■□□□□□□□□□
    ……I did a little work on this

    By default, routes in routing-table inet.0 can resolute NEXT-HOP by inet.0 and inet.3.
    The lower preference entry will be used, since RSVP-LSP preference is 7, LDP based LSP is 9, these two value is smaller than IGP preference, so generally speaking inet.3 is prefered. If the preference is equal for some reason, then prefern inet.3

    By default, routes in routing-table inet.3 can only resolute NEXT-HOP via inet.3. If the routes can not resolute the protocol next-hop in inet.3, then it is labeled as inactive, no matter you are on the data plane or not.

    So the solution for this problem is " to make the protocol next-hop resolution done", (the task is only on the control plane, has nothing to do with the data plane, so you can configure one reject or discard default route)

    Solution 1: manually configure a default route in inet.3. So all l3vpn next-hop can be resolved, so the VPNv4 routes will be active, so it can be reflect to other client PEs.
    advantage: most easy way, prefered if the RR is only on control plane, no need to enable mpls/ldp/rsvp.
    disadvantage: can not find the BGP next-hop is down. Convergence timer is a problem, should configue BFD at the same time, to faster bgp convergence.

    Solution 2: dynamically computed lsp in inet.3. we populate real lsp in inet.3, so it can be used to roselute the bgp next-hop. Enable ldp on all routers seems the most easy way. Rsvp-based lsp also works. Again, the inet.3 table in this senario is only for control plane, it is highly possible the data plane is a different path.

    Solution 3: copy the inet.0 table inco inet.3 with rip-group command, to solve the next-hop. NOT prefered, consume more resources.

    Solution 4: change the default resolution behavior, use the inet.0 directly for the next-hop resolution. just as aganguly said: set routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0. When the anycast bgp is used, then you may want use IGP metric to inluence the path selection rather than the default router-id. For example two CEs is anouncing the same VPNv4 routes to two RR, of course want the RR reflect the IGP shortest routes to its client PEs, then this method is the best solution.

    If I am wrong, please point out.

    Regards,

    RabeenZhu
  • RabeenZhuRabeenZhu Member Posts: 16 ■□□□□□□□□□
    one example:
    root@R4# run show route protocol bgp table bgp.l3vpn.0 hidden detail

    bgp.l3vpn.0: 2 destinations, 2 routes (0 active, 0 holddown, 2 hidden)
    64512:100:10.1.115.0/24 (1 entry, 0 announced)
    BGP Preference: 170/-101
    Route Distinguisher: 64512:100
    Next hop type: Unusable
    Next-hop reference count: 2
    State: <Hidden Int Ext>
    Local AS: 64512 Peer AS: 64512
    Age: 15:24
    Task: BGP_64512.1.1.1.1+61069
    AS path: I
    Communities: target:64512:100
    Accepted
    VPN Label: 299776
    Localpref: 100
    Router ID: 1.1.1.1


    [edit routing-options]
    root@R4# show
    max-interface-supported 7;
    rib inet.3 {
    static {
    route 0.0.0.0/0 reject;

    }
    }


    root@R4# run show route protocol bgp table bgp.l3vpn.0 detail

    bgp.l3vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
    64512:100:10.1.115.0/24 (1 entry, 1 announced)
    *BGP Preference: 170/-101
    Route Distinguisher: 64512:100
    Next hop type: Indirect
    Next-hop reference count: 2
    Source: 1.1.1.1
    Protocol next hop: 1.1.1.1
    Push 299776
    Indirect next hop: 2 no-forward
    State: <Active Int Ext>
    Local AS: 64512 Peer AS: 64512
    Age: 23:44 Metric2: 0
    Task: BGP_64512.1.1.1.1+61069
    Announcement bits (1): 0-BGP RT Background
    AS path: I
    Communities: target:64512:100
    Accepted
    VPN Label: 299776
    Localpref: 100
    Router ID: 1.1.1.1
  • RabeenZhuRabeenZhu Member Posts: 16 ■□□□□□□□□□
    change the default resolution table from the inet.3 to inet.0 example:

    [edit routing-options]
    root@R8# show
    max-interface-supported 7;
    autonomous-system 64512;
    resolution {
    rib bgp.l3vpn.0 {
    resolution-ribs inet.0;
    }
    }



    [edit protocols]
    root@R8# run show route table inet.3

    NULL



    root@R8# run show route table bgp.l3vpn.0 detail

    bgp.l3vpn.0: 6 destinations, 12 routes (6 active, 0 holddown, 4 hidden)
    64512:100:10.1.107.0/24 (2 entries, 1 announced)
    *BGP Preference: 170/-101
    Route Distinguisher: 64512:100
    Next hop type: Indirect
    Next-hop reference count: 4
    Source: 7.7.7.7
    Protocol next hop: 7.7.7.7
    Push 16
    Indirect next hop: 2 no-forward
    State: <Active Int Ext>
    Local AS: 64512 Peer AS: 64512
    Age: 1:43:03 Metric2: 10
    Task: BGP_64512.7.7.7.7+54836
    Announcement bits (1): 0-BGP RT Background
    AS path: I
    Communities: target:64512:100
    Accepted
    VPN Label: 16
    Localpref: 100
    Router ID: 7.7.7.7




    Note there is 4 hidden routes:
    root@R8# run show route table bgp.l3vpn.0 detail hidden

    bgp.l3vpn.0: 6 destinations, 12 routes (6 active, 0 holddown, 4 hidden)
    64512:100:10.1.107.0/24 (2 entries, 1 announced)
    BGP Preference: 170/-101
    Route Distinguisher: 64512:100
    Next hop type: Unusable
    Next-hop reference count: 4
    State: <Hidden Int Ext>
    Inactive reason: Unusable path
    Local AS: 64512 Peer AS: 64512
    Age: 1:46:09
    Task: BGP_64512.10.0.3.4+179
    AS path: I (Originator) Cluster list: 4.4.4.4
    AS path: Originator ID: 7.7.7.7
    Communities: target:64512:100
    Accepted
    VPN Label: 16
    Localpref: 100
    Router ID: 10.0.3.4


    By the way:
    in my lab setup, there are two RRs, RR-2 reflect some routes to RR1, I configured the cluster-id to a non-existed ip 4.4.4.4, the RR2 lo0.0 is 10.0.3.4. Then this route is inactive, change the cluster id to 10.0.3.4:

    root@R8# run show route table bgp.l3vpn.0 detail

    bgp.l3vpn.0: 6 destinations, 12 routes (6 active, 0 holddown, 0 hidden)
    64512:100:10.1.107.0/24 (2 entries, 1 announced)
    *BGP Preference: 170/-101
    Route Distinguisher: 64512:100
    Next hop type: Indirect
    Next-hop reference count: 8
    Source: 7.7.7.7
    Protocol next hop: 7.7.7.7
    Push 16
    Indirect next hop: 2 no-forward
    State: <Active Int Ext>
    Local AS: 64512 Peer AS: 64512
    Age: 2:06:12 Metric2: 10
    Task: BGP_64512.7.7.7.7+54836
    Announcement bits (1): 0-BGP RT Background
    AS path: I
    Communities: target:64512:100
    Accepted
    VPN Label: 16
    Localpref: 100
    Router ID: 7.7.7.7
    BGP Preference: 170/-101
    Route Distinguisher: 64512:100
    Next hop type: Indirect
    Next-hop reference count: 8
    Source: 10.0.3.4
    Protocol next hop: 7.7.7.7

    Push 16
    Indirect next hop: 2 no-forward
    State: <NotBest Int Ext>
    Inactive reason: Not Best in its group - Cluster list length
    Local AS: 64512 Peer AS: 64512
    Age: 4 Metric2: 10
    Task: BGP_64512.10.0.3.4+62951
    AS path: I (Originator) Cluster list: 10.0.3.4
    AS path: Originator ID: 7.7.7.7
    Communities: target:64512:100
    Accepted
    VPN Label: 16
    Localpref: 100
    Router ID: 10.0.3.4
  • AldurAldur Member Posts: 1,460
    Hi RabeenZhu,

    I'll take a detailed look at this next week. I'm in the middle of giving the JNCIE-SP bootcamp beta right now, so I'm a little busy at the moment. :)

    But just wanted to let you know that I saw your comments and I'll be getting back to you soon :)
    "Bribe is such an ugly word. I prefer extortion. The X makes it sound cool."

    -Bender
  • RabeenZhuRabeenZhu Member Posts: 16 ■□□□□□□□□□
    Thanks Aldur.
    Looking forward for your comments.

    By the way, I envy your work on JNCIE-SP icon_smile.gif
  • RabeenZhuRabeenZhu Member Posts: 16 ■□□□□□□□□□
    features on ALU 7750SR: (if you are not interested, please jump to the summary part, at the end of the post)

    Topology:

    PE1
    RR
    PE2


    Basic configuration on PE1: (PE2 is nearly identical)

    vprn 120 customer 1 create
    route-distinguisher 200:120
    vrf-target target:200:120
    interface "vprn" create
    address 200.200.130.130/24
    sap 1/1/3:100 create
    exit
    exit
    spoke-sdp 4 create
    the sdp to PE 2, if you are not familiar with sdp, then think sdp is lsp.
    exit
    no shutdown
    exit


    the MPLS LSP in this device:
    *A:PE1>config>service# show router tunnel-table

    ===============================================================================
    Tunnel Table (Router: Base)
    ===============================================================================
    Destination Owner Encap TunnelId Pref Nexthop Metric
    4.4.4.4/32 sdp MPLS 4 5 4.4.4.4 0
    4.4.4.4/32 rsvp MPLS 4 7 10.2.6.2 150
    ===============================================================================
    *A:PE1>config>service#


    NO TUNNEL to RR.


    ON the RR:

    *A:RR# show router tunnel-table

    ===============================================================================
    Tunnel Table (Router: Base)
    ===============================================================================
    Destination Owner Encap TunnelId Pref Nexthop Metric
    No Matching Entries.
    ===============================================================================
    *A:RR#

    There is no entry in the tunnel table,
    but the BGP is good:

    A:RR# show router bgp routes vpn-ipv4

    ===============================================================================
    BGP Router ID:2.2.2.2 AS:200 Local AS:200
    ===============================================================================
    Legend -
    Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
    Origin codes : i - IGP, e - EGP, ? - incomplete, > - best

    ===============================================================================
    BGP VPN-IPv4 Routes
    ===============================================================================
    Flag Network LocalPref MED
    Nexthop VPNLabel
    As-Path
    *>i 200:120:200.200.120.0/24 100 None
    4.4.4.4 131071
    No As-Path
    *>i 200:120:200.200.130.0/24 100 None
    6.6.6.6 131068
    No As-Path
    *>i 64496:10:200.200.200.0/24 100 None
    6.6.6.6 131065
    No As-Path
    Routes : 3
    ===============================================================================
    *A:RR#


    Because (as I have said) the RR does not need the next-hop for the service label (that is the route), so the RR just reflect the route to other clients.
    The ALU 7750SR deploy the same as I thought.


    Test:

    *A:PE1# show router 120 route-table

    ===============================================================================
    Route Table (Service: 120)
    ===============================================================================
    Dest Prefix Type Proto Age Pref
    Next Hop[Interface Name] Metric
    200.200.120.0/24 Remote BGP VPN 11h20m05s 170
    4.4.4.4 (tunneled) 0
    200.200.130.0/24 Local Local 11h20m08s 0
    vprn 0

    No. of Routes: 2
    ===============================================================================
    *A:PE1# ping router 120 200.200.130.130
    PING 200.200.130.130 56 data bytes
    64 bytes from 200.200.130.130: icmp_seq=1 ttl=64 time=3.92ms.
    ^C
    ping aborted by user

    ---- 200.200.130.130 PING Statistics ----
    2 packets transmitted, 2 packets received, 0.00% packet loss
    round-trip min = 3.80ms, avg = 3.86ms, max = 3.92ms, stddev = 0.073ms
    *A:PE1#

    Summary:
    Although the RR is on the data plane, it does not need the LSP.
    No need to resolve the BGP next-hop.
    For Juniper, you need extra configuration to make the BGP route active.
    For ALU, just the basic vpn-v4 bgp, by default it is active.
  • AldurAldur Member Posts: 1,460
    This is really a caveat that is specific to Junos, as mentioned by RabeenZhu. And the concern is only with the control plane in which BGP next hop resolution must occur.

    It might trip up the uninitiated, but once you understand what is going on it's pretty easy to work through.
    "Bribe is such an ugly word. I prefer extortion. The X makes it sound cool."

    -Bender
  • RabeenZhuRabeenZhu Member Posts: 16 ■□□□□□□□□□
    Thanks for your comments Aldur.

    Thanks IOS2JUNOS, your question makes me think.

    By the way, I have check the cisco deployment, RR also don't need next-hop resolution.

    I don't have a Huawei or other vendor's product, so I will stop here icon_smile.gif I guess they all follow this rule.


    The following is basic configuration and test. You expert can just bypass it :)

    Topology:

    R1(PE)
    R2(RR)
    R3(PE)

    R1:
    contains the vrf configure, bgp configure
    ip vrf vpna
    rd 65211:100
    route-target export 65221:100
    route-target import 65221:100
    !
    !
    interface Loopback0
    ip address 1.1.1.1 255.255.255.255
    !
    interface Loopback11
    ip vrf forwarding vpna
    ip address 11.11.11.11 255.255.255.255
    !
    interface FastEthernet0/0
    ip vrf forwarding vpna
    ip address 192.168.1.1 255.255.255.0

    router bgp 65221
    no bgp default ipv4-unicast
    bgp log-neighbor-changes
    neighbor 2.2.2.2 remote-as 65221
    neighbor 2.2.2.2 update-source Loopback0
    !
    address-family vpnv4
    neighbor 2.2.2.2 activate
    neighbor 2.2.2.2 send-community extended
    exit-address-family
    !
    address-family ipv4 vrf vpna
    redistribute connected
    no synchronization
    exit-address-family
    !



    RR:
    only contain the bgp RR configure

    interface Loopback0
    ip address 2.2.2.2 255.255.255.255
    !
    interface FastEthernet0/0
    ip address 10.1.12.2 255.255.255.0
    duplex auto
    speed auto
    mpls ip
    !
    interface FastEthernet1/0
    ip address 10.1.23.2 255.255.255.0
    duplex auto
    speed auto
    mpls ip

    !
    router bgp 65221
    no bgp default ipv4-unicast
    no bgp default route-target filter
    bgp log-neighbor-changes
    neighbor 1.1.1.1 remote-as 65221
    neighbor 1.1.1.1 update-source Loopback0
    neighbor 3.3.3.3 remote-as 65221
    neighbor 3.3.3.3 update-source Loopback0
    !
    address-family ipv4
    neighbor 1.1.1.1 activate
    neighbor 3.3.3.3 activate
    no auto-summary
    no synchronization
    exit-address-family
    !
    address-family vpnv4
    neighbor 1.1.1.1 activate
    neighbor 1.1.1.1 send-community extended
    neighbor 1.1.1.1 route-reflector-client
    neighbor 3.3.3.3 activate
    neighbor 3.3.3.3 send-community extended
    neighbor 3.3.3.3 route-reflector-client
    exit-address-family
    !


    R3
    identical as R1


    Test:
    R1#show ip rou vrf vpna
    check the vpn route

    Gateway of last resort is not set

    172.16.0.0/24 is subnetted, 1 subnets
    B 172.16.1.0 [200/0] via 3.3.3.3, 00:00:00
    11.0.0.0/32 is subnetted, 1 subnets
    C 11.11.11.11 is directly connected, Loopback11
    C 192.168.1.0/24 is directly connected, FastEthernet0/0

    R1#ping vrf vpna 172.16.1.1
    test the remote vrf interface ip reachability

    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 24/76/160 ms
    R1#

    Regards,

    RabeenZhu
  • uncoiluncoil Registered Users Posts: 1 ■□□□□□□□□□
    Hi Rabeen

    Good info in this thread!

    In the 7750 setup you still need to enable either rsvp or ldp on both transit interfaces of the RR as it is in the forwarding path. it is correct that no PE1<->RR, PE2<->RR SDPs are needed. But does having a label to the protocol next hop mean the routes can be resolved by the RR? Does it "try" to resolve? or does configuring as a RR change the default IBGP behaviour?

    On the other hand if the RR was off the forwarding path and did not have mpls enabled would the routes still get reflected?
  • RabeenZhuRabeenZhu Member Posts: 16 ■□□□□□□□□□
    Hi uncoil,

    In my understanding
    1. RR is only a control plane concept, only for MP-BGP routes reflect.
    2. LSP (RSVP based or LDP based)is for data plane

    They are different concept.

    Why people sometimes confues these two things? I guess because there are two famous rules before "bgp path selection rules": one is valid(no loop), another is next-hop reachable.

    Since RR is a IBGP concept, so no as-path loop, RR design will aviod RR loop, so generally speaking RR received routes are valid.
    Since RR can receive the bgp routes, of course it can reach the next-hop, via IP, (does not have to be MPLS!)
    So the RR received bgp routes will be considered as a candidate routes, sent to the bgp path selection algorithem,
    If it is considered best route, then it will be reflect to its clients/non-clients.

    Whether you need to enable RSVP or ldp on the RR transit interface depends on whether this router is on the data plane.

    For example, in real network, sometimes a small router will be used as a control-plane-only RR, use a GE/FE interface connect to a core router, in this case, no need to enable rsvp/ldp.

    If the RR itself is a core router, sure you need to enable RSVP/ldp on all interfaces.

    If the RR itself is a PE router, you need to enable the RSVP interface and set up path and lsp manually.

    For your last question, YES, it will be reflected.

    Regards,

    RabeenZhu
Sign In or Register to comment.