Category Archives: BGP

vrf-table-label on Juniper JunOS

In this blog we will discuss about one important knob in JunOS i.e vrf-table-label.

Vrf-table-label is useful for 2 purposes in Junos

  1. Save label space
  2. Perform 2 lookup on packet

So let’s understand it more. We will start with 1st point above

Junos by default allocates same VPN Label to prefixes recieved from one CE Interface. So for example if you have 2 CEs connected via 2 different interfaces and they are in same VPN on PE then Junos will allocate 2 different VPN labels to the prefixes recieved. In Cisco this is different where VPN label is allocated on per prefix which according to some is not optimal but we are not comparing anything here.

Currently in our configuration vrf-table-label is not configured. If you see below, we have 2 CEs connected to Juniper M320 PE1 via 2 different interfaces and we have Ebgp relationship between them and we are receiving some routes over it.

PE1-re1> show route 10.203.20.6
MVPN-1.inet.0: 46 destinations, 77 routes (46 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, – = Last Active, * = Both

10.203.20.4/30 *[Direct/0] 3d 00:21:55
> via ge-0/3/2.20

PE1-re1> show route 10.203.12.2
MVPN-1.inet.0: 46 destinations, 77 routes (46 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, – = Last Active, * = Both

10.203.12.0/30 *[Direct/0] 00:10:26
> via so-1/0/0.12

PE1-re1> show route receive-protocol bgp 10.203.12.2 table MVPN-1.inet.0
MVPN-1.inet.0: 46 destinations, 77 routes (46 active, 0 holddown, 0 hidden)
Restart Complete
Prefix                              Nexthop              MED Lclpref AS path
* 10.1.225.128/32          10.203.12.2                                 65012 I
10.203.12.0/30               10.203.12.2                                 65012 I

PE1-re1> show route receive-protocol bgp 10.203.20.6 table MVPN-1.inet.0
MVPN-1.inet.0: 46 destinations, 77 routes (46 active, 0 holddown, 0 hidden)
Restart Complete
Prefix                              Nexthop             MED Lclpref AS path
* 10.0.233.0/30               10.203.20.6                                65020 I

Now if we look at the VPN label which is being tagged by this PE1 for the routes received by CE, we can see that Junos is allocating separate VPN Labels to both of the routes which is what I mentioned earlier.

PE1-re1> show route advertising-protocol bgp 10.198.123.236 10.0.233.0/30 extensive
MVPN-1.inet.0: 46 destinations, 77 routes (46 active, 0 holddown, 0 hidden)
Restart Complete
* 10.0.233.0/30 (2 entries, 1 announced)
BGP group mvpn-rr type Internal
Route Distinguisher: 10.198.123.203:32764
VPN Label: 300448
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [65004] 65020 I
Communities: target:65000:321 src-as:65004:0 rt-import:10.198.123.203:16

PE1-re1> show route advertising-protocol bgp 10.198.123.236 10.203.12.0/30 extensive
MVPN-1.inet.0: 46 destinations, 77 routes (46 active, 0 holddown, 0 hidden)
Restart Complete
* 10.203.12.0/30 (2 entries, 1 announced)
BGP group mvpn-rr type Internal
Route Distinguisher: 10.198.123.203:32764
VPN Label: 300480
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [65004] I
Communities: target:65000:321 src-as:65004:0 rt-import:10.198.123.203:16

Now if we configure the vrf-table-label under routing instance on PE1, we can see the difference.

[edit routing-instances MVPN-1]
PE1-re1# set vrf-table-label

edit routing-instances MVPN-1]
PE1-re1# commit
re1:
configuration check succeeds
re0:
commit complete
re1:
commit complete

See the difference below, now only one VPN label is being allocated for the whole VRF and this really saves the label space.

PE1-re1> show route advertising-protocol bgp 10.198.123.236 10.203.12.0/30 extensive
MVPN-1.inet.0: 46 destinations, 77 routes (46 active, 0 holddown, 0 hidden)
Restart Complete
* 10.203.12.0/30 (2 entries, 1 announced)
BGP group mvpn-rr type Internal
Route Distinguisher: 10.198.123.203:32764
VPN Label: 39
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [65004] I
Communities: target:65000:321 src-as:65004:0 rt-import:10.198.123.203:16

PE1-re1> show route advertising-protocol bgp 10.198.123.236 10.0.233.0/30 extensive
MVPN-1.inet.0: 46 destinations, 77 routes (46 active, 0 holddown, 0 hidden)
Restart Complete
* 10.0.233.0/30 (2 entries, 1 announced)
BGP group mvpn-rr type Internal
Route Distinguisher: 10.198.123.203:32764
VPN Label: 39
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [65004] 65020 I
Communities: target:65000:321 src-as:65004:0 rt-import:10.198.123.203:16

So this completes one part. Now moving over to 2nd part.
Junos by default looks at the incoming MPLS packet, Pops the label and sends the underlying packet to CE without looking at IP packet at all. This situation is fine in case you have PE connected to CE via P2P links like Serial links however if you have Broadcast medium like Ethernet in between then router can’t just send the packet like this without first building the frame and to build frame it needs to do ARP lookup to get the MAC Address of the CE. So it needs to do extra lookup apart from MPLS lookup.
Vrf-table-label actually allows the router to do 2 lookups. The first lookup is done on the VPN label to determine which VRF table to refer to, and the second lookup is done on the IP header to determine how to forward packets to the correct end hosts on the shared medium. This can be useful for number of applications like ingress firewall filters, CoS etc. Now a days VT interface (tunnel-pic) is also used to do the same however if router doesn’t support tunnel-pic then vrf-table-label can be used in its place to do the same thing. With VTL, lsi interface is created which allows it to handle the first lookup before a second ARP/IP lookup is carried out through the PFE.

Lets rollback the changes we did above and come back to same situation where unique label is assigned per CE port.

VPN Label 300560 is assigned for the route by PE1 and when mpls table is checked for that particular label we can see action is Pop plus to send the packet directly to interface.

PE1-re1> show route advertising-protocol bgp 10.198.123.236 10.203.12.0/30 extensive
MVPN-1.inet.0: 46 destinations, 77 routes (46 active, 0 holddown, 0 hidden)
Restart Complete
* 10.203.12.0/30 (2 entries, 1 announced)
BGP group mvpn-rr type Internal
Route Distinguisher: 10.198.123.203:32764
VPN Label: 300560
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [65004] I
Communities: target:65000:321 src-as:65004:0 rt-import:10.198.123.203:16

PE1-re1> show route table mpls.0 label 300560
mpls.0: 57 destinations, 57 routes (57 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, – = Last Active, * = Both
300560 *[VPN/170] 00:00:41
> via so-1/0/0.12, Pop

If we enable the vrf-table-label now and check the same route and corresponding label. Lets see what we see.

PE1-re1> show route advertising-protocol bgp 10.198.123.236 10.203.12.0/30 extensive
MVPN-1.inet.0: 46 destinations, 77 routes (46 active, 0 holddown, 0 hidden)
Restart Complete
* 10.203.12.0/30 (2 entries, 1 announced)
BGP group mvpn-rr type Internal
Route Distinguisher: 10.198.123.203:32764
VPN Label: 40
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [65004] I
Communities: target:65000:321 src-as:65004:0 rt-import:10.198.123.203:16

PE1-re1> show route table mpls.0 label 40
mpls.0: 53 destinations, 53 routes (53 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, – = Last Active, * = Both

40 *[VPN/0] 00:00:12
to table MVPN-1.inet.0, Pop

So we can see, label 40 is basically pointing to routing-table now and not to interface as in our previous case. You can see the corresponding LSI interface allocated by looking at following command

PE1-re1> show route instance MVPN-1 detail
MVPN-1:
Router ID: 10.14.233.1
Type: vrf State: Active
Restart State: Complete Path selection timeout: 300
Interfaces:
lsi.24
so-1/0/0.12
ge-0/3/3.50
ge-0/3/2.20
vt-1/2/0.20
Route-distinguisher: 10.198.123.203:32764
Vrf-import: [ __vrf-import-MVPN-1-internal__ ]
Vrf-export: [ __vrf-export-MVPN-1-internal__ ]
Vrf-import-target: [ target:65000:321 ]
Vrf-export-target: [ target:65000:321 ]
Fast-reroute-priority: low
Tables:
MVPN-1.inet.0 : 77 routes (46 active, 0 holddown, 0 hidden)
Restart Complete
MVPN-1.inet.1 : 11 routes (9 active, 0 holddown, 0 hidden)
Restart Complete
MVPN-1.mvpn.0 : 77 routes (42 active, 7 holddown, 0 hidden)
Restart Complete

Ok so that’s all. I hope you liked the blog and I was able to resolve some of your confusion on this command. If you still have any queries, please let me know and I would be happy to discuss.

Regards
Mohit Mittal

 

 

Advertisements

L2VPN using Kompella – Junos

In my earlier blog on L2VPN via CCC https://networkzblogger.com/2017/04/23/l2vpn-via-ccc-in-junos/ we saw in that method customer interface needs to be bind with LSP and for each customer we need to have separate LSP configured which is not ideal from operational perspective. In this blog we will look at another method of achieving this where BGP is used as signalling protocol which automates the connections, so manual configuration of the association between the LSP and the customer edge interface is not required.

This config is also called Kompella after its author (https://tools.ietf.org/html/draft-kompella-l2vpn-l2vpn-00) where BGP is used to signal the control plane and it uses a two label stack as Martini. The VC (VPN) label is signalled via BGP and transport label can be signaled via either RSVP or LDP.

We would be looking at below topology where we will be configuring the MPLS L2VPN or Juniper L2CIRCUIT between M10i and MX960 PEs. M320s in between are just acting as Transit P/PE nodes and no configuration specifically needed on them for L2VPN however normal RSVP/LDP/MPLS/IGP config needs to be configured for transport label same as how L3VPN works.

L2VPN Kompella

MX104s are acting as RR so BGP neighborship will appropriate family needs to be activated between PEs-RRs.

For BGP based L2VPNs, following configuration needs to be configured

  1. BGP group with family l2vpn signalling
  2. Routing instance using instance type “l2vpn”
  3. Ethernet link needs to be established with Customer and same needs to be defined under Routing-instance.

Let’s start with Juniper l2vpn configuration.

First BGP Group where l2vpn signalling family needs to be enabled for PE-RR group.

BGP neighborship between M10i and one of the RR.

M10i-PE> show configuration protocols bgp group L2VPN-RRs
type internal;
family l2vpn {
    signaling;
}
authentication-algorithm md5;
authentication-key-chain BGP-L2VPN-key-chain;
neighbor 10.198.123.234;  <<<<<<<<< Loopback of RR1
neighbor 10.198.123.237;  <<<<<<<<< Loopback of RR2

BGP neighborship between M10i and one of the RR.

M10i-PE > show bgp neighbor 10.198.123.234
Peer: 10.198.123.234+179 AS 65004 Local: 10.198.123.213+50453 AS 65004
 Group: L2VPN-RRs Routing-Instance: master
 Type: Internal State: Established Flags: <Sync>
 Options: <Preference LocalAddress GracefulRestart LogUpDown AddressFamily Rib-group Refresh>
 Address families configured: l2vpn-signaling
 Local Address: 10.198.123.213 Holdtime: 90 Preference: 170
 Peer ID: 10.198.123.234 Local ID: 10.198.123.213 Active Holdtime: 90
 NLRI for restart configured on peer: l2vpn
 NLRI advertised by peer: l2vpn
 NLRI for this session: l2vpn
 Peer supports Refresh capability (2)
 Restart time configured on the peer: 120
 Stale routes from peer are kept for: 300
 Restart time requested by this peer: 120
 NLRI that peer supports restart for: l2vpn
 NLRI peer can save forwarding state: l2vpn
 NLRI that peer saved forwarding for: l2vpn
 NLRI that restart is negotiated for: l2vpn
 NLRI of received end-of-rib markers: l2vpn
 NLRI of all end-of-rib markers sent: l2vpn.
.
.

Even though customer facing config is not part of MPLS L2VPN, I will define it here which is using l2vpn encapsulation vlan-ccc.

M10i-PE > show configuration interfaces fe-0/1/1
description "Connected to CE-1";
vlan-tagging;
link-mode full-duplex;
encapsulation vlan-ccc;
unit 2 {
 encapsulation vlan-ccc;
 vlan-id 1001;
 family ccc;
}

Fairly simple configuration which is using encapsulation vlan-ccc.

OK, lets move to 2nd and 3rd part which is routing-instance configuration. I have highlighted important bits below. Off course for this L2VPN type you need to define RD, RT, and Interface which I am not mentioning specifically but you can see below.

M10i-PE > show configuration routing-instances L2VPN
instance-type l2vpn;
interface fe-0/1/1.2;
route-distinguisher 10.198.123.213:2;
vrf-target target:65004:2;
protocols {
 l2vpn {
 encapsulation-type ethernet-vlan;
 site Audi {
 site-identifier 2;
 interface fe-0/1/1.2 {
 remote-site-id 3;
 }
 }
 }
}

Important bit is instance-type l2vpn which enables this routing-instance for L2VPN. Under protocols l2vpn we have to enable the encap type as ethernet-vlan and then under site parameters we need to be define local site-identifier which is in our case is 2 and an optional remote-site-id. I have defined remote-site-id as 3 which will be configured on MX960 Remote-PE as its local site-identifier.

In same way we will be configuring the MX960 PE

MX960-PE> show configuration interfaces ge-1/1/9.700
encapsulation vlan-ccc;
vlan-id 700;
family ccc;

MX960-PE> show configuration routing-instances L2VPN
instance-type l2vpn;
interface ge-1/1/9.700;
route-distinguisher 10.198.123.205:3;
vrf-target target:65004:2;
protocols {
 l2vpn {
 encapsulation-type ethernet-vlan;
 site Bentley {
 site-identifier 3;
 interface ge-1/1/9.700 {
 remote-site-id 2;
 }
 }
 }
}

Once this is configured, let’s check the routing table on M10i

M10i-PE > show route table L2VPN.l2vpn.0
L2VPN.l2vpn.0: 3 destinations, 5 routes (3 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

10.198.123.205:3:3:1/96 <<<<<<<<<------------ Learnt from MX960
 *[BGP/170] 13:56:58, localpref 100, from 10.198.123.237
 AS path: I, validation-state: unverified
 > via so-0/0/0.0, Push 299888
 [BGP/170] 13:56:58, localpref 100, from 10.198.123.234
 AS path: I, validation-state: unverified
 > via so-0/0/0.0, Push 299888
.
.
.
10.198.123.213:2:2:3/96 <<<<<<<<-------------- Local route on M10i
 *[L2VPN/170/-101] 16:56:08, metric2 1
 Indirect

This output is showing us RD value of 10.198.123.205:3 plus value of remote-side identifier which is 3 as well plus label-offset value which is 1

In same way, local route has RD value of 10.198.123.213:2 plus value of remote-side identifier which is 2 and label-offset value of 3. Will explain label-offset later.

So this completes our BGP control signalling path.

L2VPN connection state is up between both PEs

M10i-PE > show l2vpn connections up
Layer-2 VPN connections:

Instance: L2VPN
Edge protection: Not-Primary
 Local site: Audi (2)
 connection-site Type St Time last up # Up trans
 3               rmt  Up May 2 20:53:51 2017 1
 Remote PE: 10.198.123.205, Negotiated control-word: Yes (Null)
 Incoming label: 800006, Outgoing label: 800003
 Local interface: fe-0/1/1.2, Status: Up, Encapsulation: VLAN

Now we can move over to forwarding path where we will see MPLS labels. As in case of L3VPNs, we have 2 Labels on each packet i.e. VPN Label and other is transport label.

Transport label is calculated in same way where label is assigned for next-hop which in our case is remote-PE MX960 loopback address and this label can be learnt by any method LDP or RSVP and will be advertised to M10i PE by its immediate neighbour which in our case is M320.

So to check the label stack which is being pushed at M10i, we can see the MPLS.0 table.

M10i-PE > show route table mpls.0
mpls.0: 25 destinations, 25 routes (25 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both
.
.
.
fe-0/1/1.2 *[L2VPN/7] 14:27:18, metric2 1
 > via so-0/0/0.0, Push 800003, Push 299888(top) Offset: 252

So you can see two labels are being pushed, TOP (transport) label is 299888 which is advertised by M320

M320-Transit-P-1> show ldp database session 10.198.123.213
.
.

Output label database, 10.198.123.202:0--10.198.123.213:0
 Label Prefix
 306336 10.198.123.100/32
 299808 10.198.123.201/32
 3      10.198.123.202/32
 299792 10.198.123.203/32
 308832 10.198.123.204/32
 299888 10.198.123.205/32
 304288 10.198.123.211/32

VPN Label is 800003 which is calculated little bit differently in case of L2VPNs and not directly advertised by Remote-Pes.

Formula to calculate VPN label is

L2VPN label = Label-Base (remote) + Site-Id(Local) – Label-Offset (remote)

Label-base (remote) value is what we can get from MX960 by looking at its L2VPN.l2vpn table

MX960-PE > show route table L2VPN.l2vpn.0 extensive
L2VPN.l2vpn.0: 3 destinations, 5 routes (3 active, 0 holddown, 0 hidden)
.
.
 Advertised metrics:
 Flags: Nexthop Change
 Nexthop: Self
 Localpref: 100
 AS path: [65004] I
Path 10.198.123.205:3:3:1 Vector len 4. Val: 0
 *L2VPN Preference: 170/-101
 Next hop type: Indirect, Next hop index: 0
 Address: 0xa5d246c
.
.
.
 Label-base: 800002, range: 2, status-vector: 0x0, offset: 1
 Secondary Tables: L2VPN.l2id.0

You can see above that label-base is 800002 on MX960 and Label-offset value is 1

So as per our equation above,

L2VPN Label = 800002 + 2 (Site-id local on M10i)  – 1  = 800003

Once this VPN Label reaches MX960, it is pop as per normal MPLS procedures and out to CE-2 interface.

800003 *[L2VPN/7] 14:37:16
 > via ge-1/1/9.700, Pop Offset: 4

In same way, MX960 will also calculate the VPN label for traffic flowing from MX960 to M10i.

So that’s all for this blog. I hope you enjoyed it and let me know if you still have any issues.

 

Regards

Mohit Mittal


eBGP using IPv6 in Juniper JunOS

Hi All

In my earlier post on VRRP https://networkzblogger.com/2017/04/15/vrrpv6-and-tracking-in-junos/ we looked at VRRPv6 and how VRRP tracking is working on receiving the Ipv6 default route. As that blog was mainly focusing on VRRP, so didn’t explained anything on Ebgp relationship over Ipv6 and IPV6 default route however in this post I will be mainly focusing on it.

Let’s start.

We will be using same Model as we used in earlier post, but in condensed form. Rather than looking at redundant configs, we will concentrate on one EBGP between 2 neighbors.

Below mentioned topology will be used where MX104 CE is connected to Juniper CE-1 ISP and we will have EBGP over IPV6 running between them and MX104 CE in turn receiving Ipv6 default route from ISP.

eBGP_IPv6

Lets look at Interface configs first on both sides.

MX104_CE> show configuration logical-systems LS1-Tower
interfaces {
    ge-0/0/4 {
        unit 600 {
            description "Connected to ISP-CE-1_ge-0/2/0.600";
            vlan-id 600;
            family inet6 {
                address 2a00:2380:3013:1000:0:0:0:3/127;
            }
        }
    }

ISP_CE-1> show configuration interfaces ge-0/2/0
description "Connected to MX104 CE_ge-0/0/4 ";
vlan-tagging;
mtu 1600;
hold-time up 0 down 1000;
link-mode full-duplex;
unit 600 {
    vlan-id 600;
    family inet6 {
        address 2a00:2380:3013:1000:0:0:0:2/127;
    }
}

Fairly straightforward configuration where we used statically configured IPV6 addresses. We could have also used 128-bit IPv6 addresses or we can use link local addresses but only requirement is that with link-local addressing we need to use statement “local-interface”. You can also use eui-64 address where we just need to know the /64 subnet and router auto calculates the ipv6 addresses by concatenating the subnet address with 48 bit mac-address and 16 bit 0xFFFE

Once this is done, let’s see the Ebgp config.

MX104_CE > show configuration logical-systems LS1-Tower protocols bgp group btnet6
type external;
authentication-algorithm md5;
authentication-key-chain IPv6-key-chain;
export [ Main_Subnets_IPV6 Backup_Subnets_IPV6 ];
local-as 65004;
neighbor 2a00:2380:3013:1000:0:0:0:2 {
    peer-as 2856;
}

ISP_CE-1> show configuration routing-instances Internet-600 protocols bgp group btnet6
type external;
authentication-algorithm md5;
authentication-key-chain IPv6-key-chain;
local-as 2856;
neighbor 2a00:2380:3013:1000:0:0:0:3 {
       peer-as 65004;
}

Again a straightforward configuration on the same lines as Ipv4 where we defined separate group btnet6 for IPV6 config and added the neighbor command with corresponding peer autonomous system.

Now let’s see the bgp status

MX104_CE > show bgp summary logical-system LS1-Tower
Groups: 2 Peers: 2 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0
                       1          1          0          0          0          0
inet6.0
                       0          0          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
2a00:2380:3013:1000::2  2856          3                      4       0       1           3 Establ
  inet6.0: 0/0/0/0

BGP is up on MX104 CE however it is not receiving anything so let’s advertise IPV6 default route from ISP CE.

We need to manually add the static route under routing-options with discard or reject option (one will send ICMP unreachable and other will silently reject). You can notice the difference from IPV4 static route where there was no need to define the rib.

ISP_CE-1> show configuration routing-instances Internet-600
instance-type vrf;
interface fe-0/1/2.0;
interface ge-0/2/0.600;
interface ge-0/2/0.602;
route-distinguisher 2856:1;
vrf-target target:2856:1;
routing-options {
    rib Internet-600.inet6.0 {
        static {
            route ::/0 discard;
        }
    }
}

Once this is done, configure this under policy-statement and reference that policy as export under neighbor statement.

ISP_CE-1> show configuration policy-options policy-statement default-export-ipv6
from {
    route-filter ::/0 exact;
}
then accept;

ISP_CE-1> show configuration routing-instances Internet-600 protocols bgp group btnet6
type external;
authentication-algorithm md5;
authentication-key-chain IGUK-IPv6-key-chain;
local-as 2856;
neighbor 2a00:2380:3013:1000:0:0:0:3 {
    export default-export-ipv6;
    peer-as 65004;
}

Now let’s check the default route on MX104:

Ok we see some activity now.

MX104_CE> show bgp summary logical-system LS1-Tower
Groups: 2 Peers: 2 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0
                       1          1          0          0          0          0
inet6.0
                       1          1          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
2a00:2380:3013:1000::2   2856                 7                       8       0       2             2:03              Establ
  inet6.0: 1/1/1/0

MX104_CE> show route logical-system LS1-Tower receive-protocol bgp 2a00:2380:3013:1000::2 extensive
inet6.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden)
* ::/0 (1 entry, 1 announced)
     Accepted
     Nexthop: 2a00:2380:3013:1000::2
     AS path: 2856 I

So we have this default route under MX104 and we used this to under VRRP tracking to track outgoing interface towards ISP.

So that’s all for this blog. If you have any queries, please let me know.

Regards

Mohit


	

BGP Route Distinguisher vs Route Target

In this post I will try to clarify the difference between route distinguisher and route target within the Cisco world of MPLS VPN’s. The main confusion comes from the fact that in most Cisco Press books they always show the route distinguisher value and route target value as the same.
They are not the same and are used for completely different things.
In simple terms the route distinguisher is used to create a unique 96 bit address called the VPNv4 address.
This ensures that even if two customers are running the 10.0.0.0/8 address space their addresses remain unique within the MPLS network.
The Route Target is a 64 bit BGP community used to tag prefixes. It tells the Remote PE routers which prefix it can import.

Route Distinguisher

The route distinguisher has only one purpose, to make IPv4 prefixes globally unique. It is used by the PE routers to identify which VPN a packet belongs to, e.g to enable a router to distinguish between 10.0.0.1/8 for Customer A and 10.0.0.1/8 for Customer B. The route distinguisher is made up of an 8 byte field prefixed to the customer 4 Byte IPv4 address, the resulting 12 byte field makes a unique VPNv4 address.

RD

R1(config)#ip vrf Customer_A

If we type “rd ?” you can see 2 options for configuring the RD..

R1(config-vrf)#rd ?
ASN:nn or IP-address:nn VPN Route Distinguisher

For the purpose of this description I will configure the RD value as 65355:10 which AS number 65535 and Unique value 10 combinatin

R1(config-vrf)#rd 65355:10

To verify this value enter the command sh ip vrf
R1#sh ip vrf
Name Default RD Interfaces
Customer_A 65355:10

Route Target

The route target on the other hand is an 8 byte field which is a BGP extended Communities Attribute and it defines which prefixes are exported and imported on the PE routers.

RT

So for example consider Router R3 has 2 VRF’s configured on it “Customer_A” and “Customer_B” so you would define under each vrf a unique route target value, these take the same format as the route distinguisher, but for the purpose of this explanation we are going to use 1:1 for Customer_A and 2:2 for Customer_B. On R3 we want to export and import the prefixes for Customer A and B, however on router R1 we only want to import and export the prefixes for Customer_A and on router R2 we only want to import and export the prefixes for Customer_B

To conclude, the route distinguisher and route target values perform two completely separate functions, and although in a lot of cisco books the values are the same (which they can be) it is confusing to someone learning MPLS for the first time as they assume they do the same thing.
The route distinguisher makes a unique VPNv4 address across the MPLS network and the route target defines which prefixes get imported and exported on the PE routers.

 

Regards

Mohit Mittal

 

Route-Reflection in JunOS

Let’s talk about one important concept in Route-reflection configuration in Junos.

To start with, there are 2 main IPv4 routing-tables in Junos which are inet.0 and inet3.0. inet.0 is main global routing table and inet3.0 is used in MPLS Layer 3 VPN and this table stores the egress address of an MPLS label-switched path (LSP), the LSP name, and the outgoing interface name. Only BGP accesses the inet.3 routing table. BGP uses both inet.0 and inet.3 to resolve next-hop addresses.

Now let’s configure the Route-reflection in Network. We will using 2 PEs and 1 RR

MPLS Network_1

Config on PE1:

PE1-re0> show configuration protocols bgp
local-address 10.198.123.204;
group L3VPN-RRs {
type internal;
family inet-vpn {
unicast;
}
authentication-algorithm md5;
authentication-key-chain BGP-L3VPN-key-chain;
export L3VPN-Export;
vpn-apply-export;
neighbor 10.198.123.235;   <<<<<<<<<<<<<<———- Router ID of RR
}

Config on PE2:

PE-2-re0> show configuration protocols bgp
local-address 10.198.123.205;
group L3VPN-RRs {
type internal;
family inet-vpn {
unicast;
}
authentication-algorithm md5;
authentication-key-chain BGP-L3VPN-key-chain;
export L3VPN-Export;
vpn-apply-export;
neighbor 10.198.123.235;
}

Config on RR (relevant configs only):

RR.re0> show configuration logical-systems l3vpn-RR
interfaces {
lo0 {
unit 3 {
family inet {
filter {
input Protect-RE;
}
address 10.198.123.235/32;
}
}
}
}
protocols {
bgp {
local-address 10.198.123.235;
mtu-discovery;
log-updown;
family inet-vpn {
unicast;
}
group l3vpn-client-group {
type internal;
authentication-algorithm md5;
authentication-key-chain BGP-L3VPN-key-chain;
cluster 10.198.123.235;
neighbor 10.198.123.204;
neighbor 10.198.123.205;
}
.
.
.
.
routing-options {
graceful-restart {
restart-duration 500;
}
router-id 10.198.123.235;
autonomous-system 65004;
}

BGP is established between PEs and RR

PE-2-re0> show bgp summary | match 10.198.123.235
10.198.123.235       65004      19154     12204       0       5 3d 23:20:04 Establ

PE-1-re0> show bgp summary | match 10.198.123.235
10.198.123.235       65004     19154     12326       0       1 3d 23:20:38 Establ

RR-re0> show bgp summary logical-system l3vpn-RR | match 10.198.123.204
10.198.123.204       65004     12336     19179       0     34 3d 23:25:10 Establ

RR-re0show bgp summary logical-system l3vpn-RR | match 10.198.123.205
10.198.123.205       65004     12212     19179       0     10 3d 23:24:31 Establ

PE-1 is advertising routes towards RR with next-hop address as its own loopback. All well n good.

PE-1-re0> show route advertising-protocol bgp 10.198.123.235
Data-VPN.inet.0: 22 destinations, 22 routes (22 active, 0 holddown, 0 hidden)
Restart Complete
Prefix                          Nexthop             MED     Lclpref   AS path
* 10.12.204.128/32     Self                       100       I
* 10.12.240.0/30         Self                         100       65012 I
* 10.12.240.128/32     Self                        100       65012 I
* 10.204.12.0/30         Self                         100       I

M10i-L3VPN.inet.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
Restart Complete
Prefix                         Nexthop            MED     Lclpref   AS path
* 10.0.0.240/30           Self                         100       65020 I
* 100.100.100.0/30   Self                         100       I

However wait a minute, we are not seeing any routes under BGP table on RR

RR-re0> show route receive-protocol bgp 10.198.123.204 logical-system l3vpn-RR
inet.0: 96 destinations, 96 routes (96 active, 0 holddown, 0 hidden)
Restart Complete
bgp.l3vpn.0: 89 destinations, 178 routes (0 active, 0 holddown, 178 hidden)
Restart Complete

Why is this??.. Now this is fundamentally an issue with how the things were setup.

As I mentioned above inet.3 table stores the egress address of an MPLS label-switched path (LSP) which is used by BGP table to resolve next-hop addresses which in our case is loopback ip of PEs however as RR is not in forwarding path there are no MPLS LSPs configured on it and in-turn no inet.3 table entries which is a problem and that’s why you can see all entries in output above are hidden as bgp table is not able to resolve the next-hop IPs in inet3 table.

So there are number of ways to resolve this and will be discussing two of them here. Simplest one and most widely used method is to configure a static route for loopback IP subnet under inet.3 rib as below.

[edit logical-systems l3vpn-RR routing-options]
RR.re0# load merge terminal relative
[Type ^D at a new line to end input]
rib inet.3 {
static {
route 10.198.123.0/24 {
discard;
metric 65535;
}
}
}
load complete
[edit logical-systems l3vpn-RR routing-options]
RR.re0# commit
re0:
configuration check succeeds
re0:
commit complete

Once you configure this, inet.3 table is populated with static entry and now BGP can use this to resolve the next-hop IP Address for each route and all entries are visible now in routing table.

RR.re0> show route logical-system l3vpn-RR table inet.3
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, – = Last Active, * = Both
10.198.123.0/24   *[Static/5] 00:00:08, metric 65535
Discard
[edit logical-systems l3vpn-RR routing-options]
RR.re0# run show route logical-system l3vpn-RR table bgp.l3vpn.0
bgp.l3vpn.0: 89 destinations, 178 routes (89 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, – = Last Active, * = Both
.
.
.
.
10.198.123.204:12:10.0.0.240/30
*[BGP/170] 4d 04:25:15, localpref 100, from 10.198.123.204
AS path: 65020 I, validation-state: unverified
to Discard
[BGP/170] 05:34:11, localpref 100, from 10.198.123.238
AS path: 65020 I, validation-state: unverified
to Discard
10.198.123.204:12:100.100.100.0/30
*[BGP/170] 4d 04:25:15, localpref 100, from 10.198.123.204
AS path: I, validation-state: unverified
to Discard
[BGP/170] 05:34:11, localpref 100, from 10.198.123.238
AS path: I, validation-state: unverified
to Discard
10.198.123.204:116:10.0.0.24/30
*[BGP/170] 4d 04:25:15, localpref 100, from 10.198.123.204
AS path: I, validation-state: unverified
to Discard
[BGP/170] 05:34:11, localpref 100, from 10.198.123.238
AS path: I, validation-state: unverified
to Discard

Another option is to let inet3.0 use the rib already calculated by inet.0 table by using the below command.

[edit logical-systems l3vpn-RR routing-options]
RR.re0# show
graceful-restart {
restart-duration 500;
}
router-id 10.198.123.235;
autonomous-system 65004;
resolution {
rib inet3.0 {
resolution-ribs inet.0;
}
}

Both of these methods are valid and it depends upon which one you want to use in your network. For 2nd method you can configure prefix-list to list down only the specific network you want to exchange.

So that’s all for today. I hope I was to make it easy for you to understand. Let me know in case you have any comments or queries. J

R
Mohit