RR and L3 VPNs

IOS2JUNOS

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

hoogen82

That would be it... 2nd one is a nice solution..

IOS2JUNOS

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?

hoogen82

I think you can always check with the proctor... This isn't exactly like a static route solution...

zoidberg

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.

IOS2JUNOS

cool..thanks guys!!

darry9502

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.

high1432007

Darry, did you pass JNCIE-M?

darry9502

high1432007 wrote: »

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.

octobraz

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...

aganguly

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.

fakhir2005s

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

Aldur

fakhir2005s wrote: »

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.

fakhir2005s

Thanks Aldur

RabeenZhu

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

RabeenZhu

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

RabeenZhu

……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

RabeenZhu

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

RabeenZhu

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

Aldur

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

RabeenZhu

Thanks Aldur.
Looking forward for your comments.

By the way, I envy your work on JNCIE-SP

RabeenZhu

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.

Aldur

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.

RabeenZhu

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 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

uncoil

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?

RabeenZhu

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