VPRN R8.0R01 v1.2.1

Release 8.
0 workshop
New VPRN and VPRN-related features
William Brioschi <william.brioschi@alcatel-lucent.com>
April 2010
VPRN topics
1. Network Time Protocol within VPRN

2. PW termination: IPIPE, IPv6 over EPIPE, redundancy
3. GRT leaking
4. NAT
5. Load balancing in the MPLS core
6. MVPN
7. Miscellaneous: auto-bind, eiBGP, PE-CE
8. VPRN on 7705
1
Network Time Protocol in VPRN
Provide time/frequency reference to customer
Alcatel-Lucent – Internal
3 | R8.0 VPRN features | April 2010 Proprietary – Use pursuant to Company instruction.
NTP within VPRN
Providing time reference to customer
Release 8.0 introduces the possibility of acting as an NTP server inside a VPRN.
The CE and other customer equipment will be able to use the PE as a time
reference.
As a prerequisite, the PE must already be an NTP server in the base routing.
An external reference NTP server is still required (i.e. SR cannot act as a

“standalone” NTP time source).
NTP client and peer functionality is not available in VPRN PE.
There is only one instance of NTP: the VPRN will not provide a different timing
than the global one.
NTP within VPRN
Configuration steps
1) The PE must be configured as an NTP client to an external reference. The

reference server may be reached via “management” (out-of-band) or via
“Base” (in-band) routing instances.
A:PE3# configure system time ntp
A:PE3>config>system>time>ntp# server 138.203.19.128
A:PE3>config>system>time>ntp# no shutdown
NTP server
CE1
PE3
PE5
PE6
PE4
PE2
NTP within VPRN
Configuration steps
2) The PE must be configured to act as NTP server in the global context

NTP server
A:PE3>config>system>time>ntp# ntp-server
CE1
PE3
PE5
PE6
PE4
PE2
NTP within VPRN
Configuration steps
3) NTP must be enabled within the VPRN context

NTP server
A:PE3# configure service vprn 100

A:PE3>config>service>vprn# ntp
A:PE3>config>service>vprn>ntp# no shutdown
CE1
PE3
PE5
PE6
PE4
PE2
NTP within VPRN
Configuration steps
4) The CE may now be configured as a client to the PE

NTP server

A:PE3>config>service>vprn# ntp
A:PE3>config>service>vprn>ntp# no shutdown
CE1
PE3
PE5
A:CE1# configure system time ntp
A:CE1>config>system>time>ntp# server 192.168.0.3
A:CE1>config>system>time>ntp# no shutdown
PE6
PE4
PE2
NTP within VPRN
Configuration steps
5) Optionally authentication can be enabled. Authentication parameters are

local to the VPRN.
NTP server
A:PE3# configure service vprn 100 ntp

A:PE3>config>service>vprn>ntp# authentication-key 1 key SECRET type message-digest
A:PE3>config>service>vprn>ntp# authenticate
similar to “ntp-server authenticate” in global context

CE1
PE3
PE5
A:CE1# configure system time ntp
A:CE1>config>system>time>ntp# authentication-key 1 key SECRET type message-digest
A:CE1>config>system>time>ntp# server 192.168.0.3 key 1
PE6
PE4
PE2
NTP within VPRN
Configuration steps
It is also possible to use broadcast mode (but not multicast mode).
The server periodically sends time announcements and the client is configured
to process these broadcast messages.
A:CE9>config>system>ntp# broadcastclient interface to-PE3
NTP server CE9
A:PE3>config>service>vprn>ntp# broadcast interface to-CE9
CE1
PE3
PE5
PE6
PE4
PE2
NTP within VPRN
Caveat
Please note: the NTP process always checks out-of-band routing table first,
even when replying to VPRN clients.
Therefore, if you have “comprehensive” BOF static-routes, chances are that

the CE NTP client will not get a response from the PE NTP server.
NTP server
A:PE3# show bof | match static

static-route 0.0.0.0/1 next-hop 138.203.18.1
CE1
PE3
PE5
PE6
PE4
PE2
NTP within VPRN
Caveat
Please note: the NTP process in VPRN always generates packets from:
- the lowest numbered loopback IP address;
- if there is no loopback, the lowest numbered IP address
even if the client points to a different IP on the PE.

*A:PE3# show router 100 interface
*A:PE3# show router 100 interface
===============================================================================
===============================================================================
Interface Table (Service: 100)
Interface Table (Service: 100)
===============================================================================
Interface-Name ===============================================================================
Adm Opr Mode Port/SapId
IP-Address Interface-Name Adm Opr
PfxState Mode Port/SapId
IP-Address
------------------------------------------------------------------------------- PfxState
loopback -------------------------------------------------------------------------------
Up Up VPRN loopback
192.168.0.3/32 loopback Down n/a Down VPRN loopback
loopback2 192.168.0.3/32
Up Up VPRN loopback n/a
200.200.200.200/32 loopback2 Down n/a Down VPRN loopback
loopback3 200.200.200.200/32
Up Up VPRN loopback n/a
172.16.0.3/32 loopback3 Down n/a Down VPRN loopback
to-CE5 172.16.0.3/32
Up Up VPRN 1/2/1:4035 n/a
192.168.35.3/24 to-CE5 Up n/a Up VPRN 1/2/1:4035
to-CE7 192.168.35.3/24
Up Up VPRN 1/2/1:37 n/a
192.168.37.3/24 to-CE7 Up n/a Up VPRN 1/2/1:37
to-Epipe-red 192.168.37.3/24
Up Up VPRN spoke-34:103 n/a
192.168.103.2/24 to-Epipe-red Up n/a Up VPRN spoke-34:103
192.168.103.2/24
------------------------------------------------------------------------------- n/a
Interfaces : 6 -------------------------------------------------------------------------------
Interfaces : 6
===============================================================================
===============================================================================
NTP within VPRN
Extended show
NTP show command has been extended to list the NTP clients.
A:PE3# show system ntp all
===============================================================================
NTP Status
===============================================================================
Configured : Yes Stratum : 5
Admin Status : up Oper Status : up
Server Enabled : Yes Server Authenticate : No
Clock Source : 138.203.19.128 Auth Check : Yes
Current Date & Time: 2010/04/18 08:13:44 UTC
===============================================================================
===============================================================================
NTP Active Associations
===============================================================================
State Remote Reference ID St Type A Poll Reach Offset(ms)
-------------------------------------------------------------------------------
chosen 138.203.19.128 135.3.41.146 4 srvr - 1024 YYYYYYYY 2.433
===============================================================================
===============================================================================
NTP Clients
===============================================================================
vRouter Address Time Last Request Rx
-------------------------------------------------------------------------------
Base 10.0.0.4 04/18/2010 09:59:18
vprn100 138.203.18.140 04/16/2010 16:45:18
vprn100 192.168.0.1 04/18/2010 10:00:05
===============================================================================
Apparently clients are never removed from the list.

2
Pseudowire termination in L3 interface
IP pseudowire, IPv6 over Eth PW, redundancy
IP pseudowire temination
IPv6 over Ethernet pseudowire
IP pseudowire termination
Configuration steps
IP (v4) pseudowires can now be terminated into a L3 interface (VPRN or IES)
The spoke-sdp must be configured as vc-type ipipe
Chassis mode C (IOM2 or better) is required (including 7710 and 7450-mixed)
IPv6 PW is not supported

Note: fictional ethernet MTU
(even when non-ethernet SAP)
*A:PE5# configure service ipipe 101 A:PE6# configure system chassis-mode c

service-mtu 1514
sap 1/1/4:101 create A:PE6# configure service vprn 100
ce-address 192.168.101.7 interface "to-Ipipe" create
exit address 192.168.101.6/24
spoke-sdp 56:101 create ip-mtu 1500
ce-address 192.168.101.6 spoke-sdp 65:101 vc-type ipipe create
exit exit
no shutdown exit
IPIPE
192.168.101.7 192.168.101.6
CE PE5 PE6
IPv6 pseudowire termination
Configuration steps
IPv6 interfaces (VPRN or IES) can terminate Ethernet pseudowires
IOM2 or better is required (including 7710 and 7450-mixed), any chassis mode
*A:PE5# configure service epipe 102 A:PE6# configure service vprn 100
service-mtu 1514 interface "to-Epipe-IPv6" create
sap 1/1/4:102 create ipv6 address 2000::102:7/112
exit ip-mtu 1500
spoke-sdp 56:102 create spoke-sdp 65:102 create
exit exit
no shutdown exit
EPIPE
2000::102:7/112 2000::102:6/112
CE PE5 PE6
Pseudowire termination in L3 interface
Active/standby signalling
Active/standby signalling for redundant PW termination
Before 8.0
Standby TLDP signalling used to be ignored when terminating the pseudowire in

a L3 interface (VPRN or IES)
Both PE’s would see the interface “up”, leading to an inoperable situation
PE2
192.168.103.2
UP
192.168.0.103/32
EPIPE
192.168.103.9
CE9 PE4 PE6

UP
CE10
192.168.103.2
PE3
A:PE6# show router 100 route-table
-------------------------------------
192.168.103.0/24
10.0.0.2 (tunneled)
192.168.103.0/24
10.0.0.3 (tunneled)
Description
In Release 8.0 the PE processes the TLDP signalling so that the interface
connected to the standby SDP is brought down; correspondingly, the
route/routes are withdrawn
PE2
192.168.103.2
UP
192.168.0.103/32
EPIPE
192.168.103.9
CE9 PE4 PE6

DN
CE10
192.168.103.2
PE3
-------------------------------------
192.168.103.0/24
10.0.0.2 (tunneled)
Configuration
1) The endpoint on the epipe must be configured as A/S signalling master

(otherwise it would not send standby TLV)
A:PE2>config>service>vprn#
2) Nothing special is required on VPRN side, the capability is enabled by interface "to-Epipe-red" create
address 192.168.103.2/24
default and cannot be disabled ip-mtu 1500
spoke-sdp 24:103 create
exit
exit
No routing protocol is needed on CE static-route
PE2 192.168.0.103/32 next-hop 192.168.103.9
A:CE9# 192.168.103.2
static-route 0.0.0.0/0 next-hop 192.168.103.2 UP
192.168.0.103/32
EPIPE
192.168.103.9
CE9 PE4 PE6

DN
CE10
192.168.103.2
A:PE4>config>service>epipe# info PE3
interface "to-Epipe-red" create
endpoint "vprn" create address 192.168.103.2/24
standby-signalling-master ip-mtu 1500
exit spoke-sdp 34:103 create
sap 1/5/1:103 create exit
exit exit
spoke-sdp 42:103 endpoint "vprn" create static-route 192.168.0.103/32 next-hop 192.168.103.9
exit
spoke-sdp 43:103 endpoint "vprn" create PE3 has the same IP configuration as PE2
exit
Performance
Let’s see what happens when PW redundancy is triggered; for example, when PE2 is
rebooted.
1) PE4 needs to be know that the SDP to PE2 is not available anymore; this is usually
triggered by the LSP failing (LDP or RSVP); or BFD may be used on the TLDP session
2) PE4 signals to PE3 that the SDP is becoming active
typ < 1 sec
3) PE3 switches “up” the L3 interface
1) PE3 sends a gratuitous ARP  CE9 updates its ARP table
2) PE3 starts announcing the routes through the interface
4) MPBGP propagates the routes from PE3 …wait… …wait… 10-30 sec!
5) In the meanwhile, the remote PE’s detect that PE2 is unreachable and disable the
routes having PE2 as next-hop PE2
192.168.103.2
UP
192.168.0.103/32
EPIPE TLDP
192.168.103.9
CE9 PE4 ARP MPBGP PE6

UP
DN
CE10
192.168.103.2
MPBGP
PE3 RR9
Performance tuning
Overall convergence time is dominated by BGP.
It would be desirable to have a “cold” route pointing to PE3, ready to kick in when the
route to PE2 is invalidated (because PE2 becomes unreachable) – without waiting for BGP
to propagate the new route.
This can be achieved with a trick: PE3 announces a route to a wider subnet, including all
the networks behind the CE, while PE2 announces specific routes.
This way, PE6 can use the specific routes (to PE2) as far as PE2 is available, and switch to
the generic route (to PE3) when PE2 becomes unreachable.
By removing BGP from the convergence mechanism, the overall convergence time can
easily be brought under 1 second.
PE2
192.168.103.2
UP
192.168.0.103/32
EPIPE
192.168.103.9
CE9 PE4 PE6

DN
CE10
192.168.103.2
PE3 RR9
192.168.0.102/31
(black hole)
Performance tuning: configuration
Configuration of PE2 is unchanged. A:PE2>config>service>vprn#

address 192.168.103.2/24
ip-mtu 1500
exit
exit
Configuration of PE3 is as follows. A:PE3>config>service>vprn#

address 192.168.103.2/24
ip-mtu 1500
exit
exit
static-route 192.168.0.102/31 black-hole
PE2
192.168.103.2
UP
192.168.0.103/32
EPIPE
192.168.103.9
CE9 PE4 PE6

DN
CE10
192.168.103.2
PE3 RR9
192.168.0.102/31
(black hole)
Performance tuning: routing before failure
address 192.168.103.2/24
Routing at PE2 192.168.0.102/31 Remote BGP VPN ip-mtu 1500
10.0.0.3 (tunneled) spoke-sdp 24:103 create
192.168.0.103/32 Remote Static exit
192.168.103.9 exit

Routing at PE3 192.168.0.102/31 Remote Static address 192.168.103.2/24
Black Hole ip-mtu 1500
192.168.0.103/32 Remote BGP VPN spoke-sdp 24:103 create
10.0.0.3 (tunneled) exit
exit
Routing at PE6 192.168.0.102/31 Remote BGP VPN
10.0.0.3 (tunneled)
192.168.0.103/32 Remote BGP VPN
10.0.0.2 (tunneled)
PE2
192.168.103.2
UP
192.168.0.103/32
EPIPE
192.168.103.9
CE9 PE4 PE6

DN
CE10
192.168.103.2
PE3 RR9
192.168.0.102/31
(black hole)
Performance tuning: routing shortly after PE failure
address 192.168.103.2/24
192.168.103.9 exit

192.168.0.103/32 Remote Static spoke-sdp 24:103 create
192.168.103.9 exit
exit
10.0.0.3 (tunneled)
192.168.0.103/32 Remote BGP VPN
10.0.0.2 (tunneled)
PE2
192.168.103.2
UP
192.168.0.103/32
EPIPE
192.168.103.9
CE9 PE4 PE6

UP
DN
CE10
192.168.103.2 Missing any specific route, the generic
PE3 “blue” route
RR9 is used for “pink” traffic
192.168.0.102/31 as well
(black hole)
Performance tuning: routing after BGP propagation
address 192.168.103.2/24
192.168.103.9 exit

192.168.103.9 exit
exit
10.0.0.3 (tunneled)
192.168.0.103/32 Remote BGP VPN
10.0.0.3 (tunneled)
PE2
192.168.103.2
UP
192.168.0.103/32
EPIPE
192.168.103.9
CE9 PE4 PE6

UP
DN
CE10
192.168.103.2
PE3 RR9
192.168.0.102/31
(black hole)
Performance tuning: routing shortly after SDP failure
address 192.168.103.2/24
192.168.103.9 exit

192.168.103.9 exit
exit
10.0.0.3 (tunneled)
192.168.0.103/32 Remote BGP VPN
10.0.0.2 (tunneled)
PE2
U-turn
192.168.103.2
DN
192.168.0.103/32
EPIPE
192.168.103.9
CE9 PE4 PE6

UP
DN
CE10
192.168.103.2
PE3 RR9
192.168.0.102/31
(black hole)
Performance tuning: after BGP propagation (SDP failure)
address 192.168.103.2/24
192.168.0.103/32 Remote BGP VPN exit
10.0.0.3 (tunneled) exit

192.168.103.9 exit
exit
10.0.0.3 (tunneled)
192.168.0.103/32 Remote BGP VPN
10.0.0.3 (tunneled)
PE2
192.168.103.2
DN
192.168.0.103/32
EPIPE
192.168.103.9
CE9 PE4 PE6

UP
DN
CE10
192.168.103.2
PE3 RR9
192.168.0.102/31
(black hole)
Performance tuning: revert to PE2
What happens when switching from PE3 to PE2 (either because the endpoint
configuration in PE4 is revertive, or because PE3 fails)?
PE2
192.168.103.2
UP
192.168.0.103/32
BGP
EPIPE
192.168.103.9
CE9 PE4 PE6

DN
CE10
192.168.103.2
PE3 RR9
192.168.0.102/31
(black hole) Traffic is blackholed until BGP
propagates to PE3 and/or PE6
In order to avoid BGP convergence times, PE2 should be configured in a similar way to
PE3 (black-hole route to wider subnet).
PE6 must have both BGP routes available  different route-distinguisher must be used on
PE2 and PE3.
Performance tuning: configuration
route-distinguisher 999:102
address 192.168.103.2/24
ip-mtu 1500
address 192.168.103.2/24
ip-mtu 1500
exit
exit
exit
exit
Two routes available:

A:PE6# show router bgp routes vpn-ipv4 community target:999:100
===============================================================================
u*>i 999:103:192.168.0.102/31 100 None
10.0.0.3 131071
No As-Path
u*>i 999:102:192.168.0.102/31 100 None
10.0.0.2 131066
No As-Path
u*>i 999:102:192.168.0.103/32 100 None
10.0.0.2 131066
No As-Path
192.168.0.102/31 Remote BGP VPN
10.0.0.3 (tunneled)
One route selected based on usual BGP 192.168.0.103/32 Remote BGP VPN
criteria (unless ECMP is enabled in VPRN) 10.0.0.2 (tunneled)
Lab practice
IP PW + active/standby
Group G = ……
Lab practice
PE5
192.168.117.56
VPRN
i/f
1G00
192.168.0.7/32 SDP 35 / 53
l.b 192.168.28.2
1/1/1:1G10 1/2/1 IPIPE VPRN
i/f i/f i/f
1G01 1G00 192.168.28.8
192.168.117.7 SDP 36 / 63
CE7 PE3 PE2 CE8

VPRN (VPRN 1G10)
(VPRN 1G10) i/f
1G00
192.168.117.56
PE6
VPRN 1G00 is already created on PE2, PE5, PE6; CE7 and CE8 are configured as well
• Use customer id G
• Complete IPipe 1G01 on PE3 with active/standby spoke-sdp to PE5 and PE6; make PE5 primary and revertive
• Complete the interfaces on PE5 and PE6
• Verify that CE7 can ping PE5 (or PE6) and v.v.
• Check ARP and routing tables on CE7, PE5, PE6 Router Management System
• whose MAC addresses do they list? PE2 138.203.19.105 10.0.0.2
PE3 138.203.19.67 10.0.0.3
• Static route towards 192.168.0.7/32 is configured on PE5 and PE6 PE5 138.203.18.156 10.0.0.5
• Check routing on PE2, PE5 and PE6 PE6 138.203.18.187 10.0.0.6
• Verify that 192.168.0.7 is reachable from CE8 CE7 138.203.18.83
• Do not attempt to optimize convergence time yet CE8 138.203.18.155
• Run a continuous ping from CE8 to CE7 192.168.0.7

• Force a spoke-sdp switch on PE3, verify the convergence time; check routing on PE2, PE5 and PE6
• Try to reduce the convergence time – any trick is allowed 
3
Leaking to Global Routing Table
Leaking to Global Routing Table (GRT)
Description
It has always been possible to route between one VPRN and another, creating
things like “extranet”, “hub and spoke” etc., by operating on the vrf-import
and vrf-export policies; this is easily possible because all VPRNs distribute their
routes with the same protocol and address family (BGP / vpn-ipv4).
It’s not possible to do the same for the global routing table.
However, Release 8.0 introduces tools to allow routing between a VPRN and
the GRT.
There are two directions to cope with:
• from VPRN to base routing
• from base routing to VPRN
The approach is different in the two directions, as shown in the next slides.
Allowing data from VPRN to base routing
To allow data flowing from VPRN to base routing space, routing information
must be made available for lookup in the VPRN.
As usual, the flow of the routing information (control plane) is in the opposite
direction than the flow of the user packets (data plane).
In this case the routing information for the
Control plane
GRT is already available in the router, and it
Data plane only needs to be made available to the VPRN.
The approach chosen is to perform a double
VRF GRT lookup:
1) in the VRF table
2) in the global table
If a match is found in the VRF table, then that is used.
Otherwise, information from the GRT is used (if available).
The double lookup is not enabled by default.
It can be enabled with one instruction inside the VPRN service:
*A:PE5# configure service vprn 100

grt-lookup
enable-grt
exit
exit
IOM3/IMM (incl. 7450-mixed and 7750 SRc) is required

- all the VPRN interfaces (network and access) must be on IOM3
- chassis mode D is not required
There is no lock in the configuration: SR will accept the

configuration without IOM3 -- but packets won’t be forwarded!
Double lookup is also performed for CPM-generated traffic
e.g. ping 40.3.3.3 router 100

grt-lookup
enable-grt Double lookup and selection of VRF/GRT route:
exit
exit
destination IP is 40.1.1.1
VRF GRT
A:PE5# show router 100 route-table A:PE5# show router route-table
=========================================== ===========================================
Dest Prefix Type Proto Dest Prefix Type Proto
Next Hop[Interface Name] Next Hop[Interface Name]
------------------------------------------- -------------------------------------------
40.1.1.1/32 Remote BGP VPN 40.2.2.2/32 Remote OSPF
10.0.0.6 (tunneled) 10.3.5.3
10.0.0.2 (tunneled) 10.3.5.3
=========================================== ===========================================
Result in VRF: nh = LSP to PE6 No result in GRT
Result: nh = LSP to PE6
grt-lookup
exit
exit
VRF GRT
=========================================== ===========================================
------------------------------------------- -------------------------------------------
10.0.0.6 (tunneled) 10.3.5.3
10.0.0.2 (tunneled) 10.3.5.3
=========================================== ===========================================
No result in VRF Result in GRT: nh = 10.3.5.3
Result: nh = 10.3.5.3
grt-lookup
exit
exit
VRF GRT
=========================================== ===========================================
------------------------------------------- -------------------------------------------
10.0.0.6 (tunneled) 10.3.5.3
10.0.0.2 (tunneled) 10.3.5.3
=========================================== ===========================================
Result in VRF: nh = LSP to PE2 Result in GRT: nh = 10.3.5.3

(VRF wins)
Since a VRF match is preferred to GRT, if the VRF has default routes or
comprehensive routes then the GRT will never be used.
It is however possible to override the base behaviour for specific networks:

grt-lookup
enable-grt
static-route 40.0.0.0/8 grt
exit
exit
With this configuration:
- destinations in 40.0.0.0/8 will be looked up in the GRT
- a static black-hole route is published in the VRF
- more specific routes (e.g. 40.1.2.3/24) in the VRF are still preferred
*A:PE5# show router 100 route-table A:PE2# show router 100 route-table
--------------------------------------- ---------------------------------------
10.0.0.0/8 Remote Static 10.0.0.0/8 Remote BGP VPN
Black Hole 10.0.0.5 (tunneled)
grt-lookup
exit destination IP is 40.1.1.1
exit
VRF GRT
=========================================== ===========================================
------------------------------------------- -------------------------------------------
10.0.0.6 (tunneled) 10.3.5.3
40.0.0.0/8 Remote Static 40.3.3.3/32 Remote OSPF
Black Hole 10.3.5.3
40.1.1.1/32 Remote BGP VPN ===========================================
10.0.0.6 (tunneled)
40.3.3.3/32 Remote BGP VPN
10.0.0.2 (tunneled)
===========================================
No result in GRT
Result in VRF: nh = LSP to PE6

grt-lookup
exit
VRF GRT
=========================================== ===========================================
------------------------------------------- -------------------------------------------
10.0.0.6 (tunneled) 10.3.5.3
Black Hole 10.3.5.3
40.1.1.1/32 Remote BGP VPN ===========================================
10.0.0.6 (tunneled)
10.0.0.2 (tunneled)
===========================================
Result in GRT: nh = 10.3.5.3
Result in VRF: no nh (black hole)

 no contribution to final selection Result: nh = 10.3.5.3
grt-lookup
exit
VRF GRT
=========================================== ===========================================
------------------------------------------- -------------------------------------------
10.0.0.6 (tunneled) 10.3.5.3
Black Hole 10.3.5.3
40.1.1.1/32 Remote BGP VPN ===========================================
10.0.0.6 (tunneled)
10.0.0.2 (tunneled)
===========================================
Result in GRT: nh = 10.3.5.3
Result in VRF: nh = LSP to PE2

There is also a “disable” option to the “static-route grt” command.
The purpose of this option is apparently to disable the override temporarily,

without removing it from the configuration.
grt-lookup
enable-grt
static-route 40.0.0.0/8 grt disable
exit
exit
With this configuration:
- the black-hole route is removed from the VRF
- second lookup in GRT is still performed, with VRF result taking precedence
Allowing data from base routing to VPRN
To allow data flowing from base routing context to VPRN, routing information
must be made available into the GRT.
As usual, the flow of the routing information (control plane) is in the opposite
direction than the flow of the user packets (data plane).
A new protocol is introduced to export routes from VPRN into GRT: vpn-leak.
*A:PE5# configure router
The vpn-lean “protocol” may be used in the policy-options
begin
routing policies in GRT to inject routes policy-statement "export-vpn"
exported from the VPRN. entry 10
from
protocol vpn-leak
exit
Control plane action accept
exit
exit
Data plane exit
commit
exit
ospf
VRF GRT asbr
export "export-vpn"
exit
What routes should be exported from the VRF to the GRT?
This is specified inside the VPRN service configuration, via a policy.
It is also possible to limit the maximum number of routes to leak to GRT

(default limit is only 5 so make sure you set a higher limit if needed).
grt-lookup *A:PE5# configure router policy-options
export-grt "vprn100-to-grt" prefix-list "vprn100-public"
export-limit 100 prefix 192.168.0.0/24 longer
exit exit
policy-statement "vprn100-to-grt"
entry 10
from
prefix-list "vprn100-public"
exit
action accept
exit
exit
exit
A log message is generated if the export-limit is hit:

304 2010/04/20 04:27:13.21 CEST MAJOR: VRTR #2026 vprn100 GRT Lookup
"GRT has reached the export-limit 5, additional routes will not be exported into GRT"
The routes are now available in the global routing table; they are recognizable
as leaked in the injecting router.
*A:PE5# show router route-table
===============================================================================
Route Table (Router: Base)
===============================================================================
192.168.0.1/32 Remote VPN Leak 00h03m56s 180

10.0.0.6 (tunneled) 0
10.0.0.2 (tunneled) 0
10.0.0.3 (tunneled) 0
10.0.0.3 (tunneled) 0
10.0.0.3 (tunneled) 0
Of course the addresses exported to GRT must be globally unique, i.e. they
can’t be used in the GRT (or be leaked to the GRT by another VPRN).
The default preference for vpn-leak protocol is 180, worse than any normal GRT routing protocol; so,
in case of conflict between a GRT-originated route and a VRF-leaked route, the GRT would win.
Even so, a more spcific route would still be preferred over a more general route (e.g. a /32 vs a /24).
Identifying the origin VPRN of a leaked route
There is no easy command to identify the VPRN a route was leaked from.
Route table does not help:

*A:PE5# show router route-table protocol vpn-leak
===============================================================================
===============================================================================
Dest Prefix Type Proto Age Pref
Next Hop[Interface Name] Metric
-------------------------------------------------------------------------------
10.0.0.6 (tunneled) 0
10.0.0.6 (tunneled) 0
10.0.0.6 (tunneled) 0
10.0.0.6 (tunneled) 0
Offending 10.0.0.6
routes: (tunneled)
(but no clue where they come from) 0
10.0.0.6 (tunneled) 0
10.0.0.6 (tunneled) 0
-------------------------------------------------------------------------------
No. of Routes: 7
===============================================================================
Identifying the origin VPRN of a leaked route
Information is indirectly available via the FIB and BGP RIB:

A:PE5# show router fib 1 172.16.0.0/16 longer
===============================================================================
FIB Display
===============================================================================
Prefix Protocol
NextHop
-------------------------------------------------------------------------------
172.16.0.10/32 VPN_LEAK
10.0.0.6 (VPRN Label:131059 Transport:LDP)
172.16.60.0/24 VPN_LEAK
A:PE5# show router bgp routes vpn-ipv4 172.16.0.10/24
-------------------------------------------------------------------------------
===============================================================================
Total Entries : 2 BGP Router ID:10.0.0.5 AS:999 Local AS:999
-------------------------------------------------------------------------------
===============================================================================
===============================================================================
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
-------------------------------------------------------------------------------
...
u*>i 999:2400:172.16.0.10/24 100 None
10.0.0.6 131059
No As-Path
...
Summary
Allows bidirectional communication between VPRN and global routing context
Examples of application:
• retailer/wholesaler Internet acccess
• access to/from the Internet for customer “exposed” hosts
• management of operator equipment inside the VPRN

Leaked IP addresses must be globally unique
Possible in any VPRN topology (full mesh, hub and spoke, extranet)
IOM3 or equivalent is required (IMM, 7750 SRc12, 7450 mixed-mode)
No IPv6 (yet)
URPF is mutually exclusive to GRT leaking (they share the “second lookup”
resource)
4
Network Address Translation
Another approach to GRT
Network Address Translation
Description
If the VPRN wants to grant access to the Internet to all its hosts, including
those without a globally routable IP address, NAT is necessary.
On the SR platform, MS-ISA MDA is necessary to perform NAT; the ISA MDA
must be equipped in an IOM3 to enable the NAT functionality.
There are two flavours of NAT available in Release 8.0:
• subscriber aware (ESM-integrated) L2-aware NAT
• non-subscriber aware Large Scale NAT (aka Carrier Grade NAT)
We’ll briefly explore Large Scale NAT, comparing it to GRT leaking
Large Scale NAT
Configuration
• MDA provisioning: ISA-MS must be equipped in an IOM3, and it must be

provisioned for personality “isa-bb”
*A:PE5# configure card 1

*A:PE5>config>card# info
----------------------------------------------
card-type iom3-xp
mda 1
mda-type m5-1gb-sfp-b
exit
mda 2
mda-type isa-bb
exit
----------------------------------------------
*A:PE5>config>card# show mda
===============================================================================
MDA Summary
===============================================================================
Slot Mda Provisioned Equipped Admin Operational
Mda-type Mda-type State State
-------------------------------------------------------------------------------
1 1 m5-1gb-sfp-b m5-1gb-sfp-b up up
2 isa-bb isa-ms up up
===============================================================================
Large Scale NAT
Configuration
• NAT group: one or more ISA MDA’s form a load-balancing resilient group
*A:PE5# configure isa
*A:PE5>config>isa# info
----------------------------------------------
nat-group 1 create
active-mda-limit 1
mda 1/2
no shutdown
exit
• Outside: configure the public address pool in the GRT; IP addresses used to
NAT the private hosts will come from the address ranges defined inside the
pool *A:PE5# configure router nat
*A:PE5>config>router>nat# info
----------------------------------------------
outside
pool "public-1" nat-group 1 type large-scale create
address-range 20.20.20.0 20.20.20.39 create
exit
address-range 20.20.20.100 20.20.20.103 create
exit
no shutdown
exit
exit
----------------------------------------------
Large Scale NAT
Configuration
• Address ranges define in the pool appear in the GRT as “static”

*A:PE5>config>router>nat# show router route-table
===============================================================================
===============================================================================
-------------------------------------------------------------------------------
...
10.5.9.0/24 Local Local 04d02h40m 0
to-RR9 0
20.20.20.0/27 Remote Static 00h02m56s 5
NAT outside: group 1 member 1 1
10.0.0.6 (tunneled) 0
...
-------------------------------------------------------------------------------
No. of Routes: 23
===============================================================================
The address ranges are automatically summarized to the largest possible subnets
Large Scale NAT
Configuration
• NAT policy: points to the pool and optionally defines limits, parameters etc.
*A:PE5# configure service nat
*A:PE5>config>service>nat# info
----------------------------------------------
nat-policy "policy-1" create
pool "public-1" router Base
exit
----------------------------------------------
• Inside: point to the policy and define the destination addresses that will
trigger NAT (if destination is not found in VRF table); this is similar to
“static-route grt” in GRT leaking
nat
inside
nat-policy "policy-1"
destination-prefix 0.0.0.0/0
exit
exit
Large Scale NAT
Configuration
• Destination-prefix’es appear in the VRF table as “static”
*A:PE5# show router 100 route-table
===============================================================================
Route Table (Service: 100)
===============================================================================
-------------------------------------------------------------------------------
NAT inside 1
...
That’s it! – enjoy your NAT*
* (of course this very brief overview skips 95% of the NAT features…)
GRT leaking vs NAT
Comparison
A simple functional comparison between GRT leaking and (CG-)NAT – no

scalability / performance considered
GRT leaking NAT
Requires globally unique addresses inside the VPRN Allows private/non-unique addresses in the VPRN
Allows bidirectional communication GRT  VPRN Only allows communication VPRN  GRT (session
initiation)
Requires IOM3/IMM Requires IOM3 and MS-ISA
All application protocol work Some NAT-unfriendly application protocols might

not work (for example PPTP, SIP)
Possible in any VPRN topology Possible in any VPRN topology
(with two extranets you could deploy GRT leaking and LS-NAT at the same time)
No IPv6 No IPv6
Lab practice
GRT leaking and NAT
Group G = ……
Lab practice
10.0.0.9
172.16.0.10/32
PE5 GRT sys
l.b
CE10 VPRN GRT
i/f l.b
(VPRN 2G10) 172.16.60.10 2G00 VPRN
l.b 30.30.30.9
2G00
20.G.10.10 PE6 RR9
VPRN 2G00 is already created on PE5 and PE6

CE10 is configured with two loopbacks, one is a private address (172.x.x.x) and one is a public address (20.x.x.x)
RR9 is configured with two loopbacks, both are public addresses
• Use customer id G
• Configure GRT leaking on PE5
• export the 20.x.x.x public loopback to GRT
• valid destination from VRF to GRT is 10.0.0.0/8
• Verify that CE10 public IP can reach RR9 (ping 10.0.0.9 source 20.G.10.10) and the other 10.0.0.x system addresses
in the network
• Verify that RR9 can reach CE10 public IP
Router Management System
• Verify that CE10 private IP cannot reach RR9 and v.v.
PE5 138.203.18.156 10.0.0.5
PE6 138.203.18.187 10.0.0.6
RR9 138.203.18.159
• Configure NAT on PE5 CE10 138.203.18.188
• use nat-policy “policy-G”, pool “pool-group-G” and IP range 20.G.20.20-21
• valid destination from VRF to GRT is 0.0.0.0/0
• Verify that RR9 cannot reach CE10 private or public loopback address
• Verify that CE10 can reach RR9 30.30.30.9 loopback from both the private and public address
5
Load balancing in the MPLS core
“Entropy” label, hashing on IP
Load balancing in the MPLS core
Load balancing VPRN traffic at the LSR
Since 7750 allocates VPRN service labels on a per-service basis (rather than
per-destination or per next-hop), hashing on the label stack at the LSR does not
provide efficient load balancing.
Two approaches are available in Release 8.0 to obtain more granular traffic
distribution:
 hashing on IP header rather than (or in addition to) the label stack; this is an
extension to functionality introduced in Release 7.0.R4
 configuration at system and router level; nothing to configure in VPRN
 introducing an additional label (the “entropy label” or “hash label”) in the

label stack, to propagate hashing result based on the information available to
the LER (user packet L2/L3/L4 headers); with this addition, the maximum
depth of the label stack increases from 5 to 6
 configuration inside VPRN service
SR1 7710 SRc-NG SR7/12 IOM1 IOM2 A/B
Load balancing at LSR 8.0.R1 C
ESS7/12
Hash label for “entropy” 7705 ESS1 ESS7/12
mixed-mode
IOM3 IMM D
PE hashes on L3/L4 header of customer

payload payload
packet and remembers the hash result.
PE pushes three MPLS labels: hash, service
used for
L4 header (optional) L4 header
and transport. Hash label contains the hash
hashing
IP header IP header result (19 significant bits).
L2 header hash
label LSR hashes on MPLS label stack, usually two
used for service
hashing label labels, up to six; the original hash result is
transport
label part of the input to the hash function in the
LSR.
LSR LSR
CE CE
PE PE
LSR LSR
ESS7/12
Hash label for “entropy” 7705 ESS1 ESS7/12
mixed-mode
IOM3 IMM D
Egress PE must understand the three-label stack.

The hash label is recognizable because its most payload
significant bit is always 1. Hence the range of

possible values is from 524288 to 1048575. L4 header
IP header
As far as the ingress PE is 7x50, this range is distinct
hash
from all the service, transport and special labels. label
used for service
hashing label
Interop test shows that 7705 R3.0 accepts incoming transport
label
packets with 3 label stack (ignoring the hash label).
LSR LSR
Case-by case interop testing
may be required with other
vendors.
CE CE
PE PE
LSR LSR
ESS7/12
Configuration 7705 ESS1 ESS7/12
mixed-mode
IOM3 IMM D
Configuration of the hash label in a VPRN is possible at two points:

• globally at service level  this applies to auto-bind and to explicity spokes
(it is not possible to enable/disable selectively per spoke-sdp)
• specifically for a spoke-sdp terminated in an interface (the remote side will
usually not be a VPRN and should be configured appropriately to accept,
and possibly generate, the hash label)

auto-bind ldp
hash-label
vrf-target target:999:100
interface "to-Ipipe" create
address 192.168.101.6/24
ip-mtu 1500
spoke-sdp 65:101 vc-type ipipe create
hash-label
exit
exit
spoke-sdp 64 create
exit
ESS7/12
Configuration 7705 ESS1 ESS7/12
mixed-mode
IOM3 IMM D
“show service … base” command can be used to check if the hash label is
enabled on the VPRN service level:
A:PE6# show service id 100 base
...
Ignore NH Metric : Disabled
Hash Label : Enabled
Vrf Target : target:999:100
...
“show router/service … interface” can be used to check if the hash label is

enabled on the interface spoke-sdp:
A:PE6# show router 100 interface "to-Ipipe" detail
...
...
A:PE6# show service id 100 interface "to-Ipipe" detail

...
...
6
MVPN
MVPN 8.0.R4 or later
Preview
New MVPN features are expected for minor Release 8.0.R4 (or possibly later):
• RSVP p2mp LSP

• LSP template, auto creation
• Inter AS
• Segmented trees
• Single data-plane tech, no mix, and it must be rsvp-p2mp
• UMH: knob between highest IP or hashing (fixed to highest IP in R7)
• Chapter 14 (no intersite-shared)

• interop with Juniper (who implemented ch 13 in the meanwhile)
• Extranet
Full interop with Juniper is expected in upcoming implementation of MVPN
MVPN 9.0 or later
Preview
Not to be expected in Release 8.0 timeframe:
• mLDP p2mp and mp2mp
• S-PMSI without I-PMSI
• Aggregated PMSI
Preview: RSVP p2mp LSP
As usual with p2mp LSP, chassis mode C is required and IOM3 is preferred (better
performance).
Only automatic creation of p2mp LSP based on a template will be possible in the first
release, for both the inclusive and the selective PMSIs. Manual p2mp provisioning might
become available in a later release.
Sample configuration (based on 8.0 BETA, CLI details may differ in final release):
*A:sim3# configure service vprn 9999
mvpn
auto-discovery
c-mcast-signaling bgp
provider-tunnel
*A:sim3# configure router mpls
inclusive
path "loose"
rsvp
no shutdown
lsp-template mc-lsp
exit
no shutdown
lsp-template "mc-lsp" p2mp
exit
default-path "loose"
exit
no shutdown
selective
exit
rsvp
lsp-template mc-lsp
no shutdown
exit
exit
exit
exit
Preview: UMH selection knob, disable chapter 13
Again, based on 8.0 BETA *A:sim3# configure service vprn 9999

mvpn
no intersite-shared
umh-selection hash-based
exit
*A:sim3# show router 9999 mvpn
===============================================================================
MVPN 9999 configuration data
===============================================================================
signaling : Bgp auto-discovery : Enabled
UMH Selection : Hash-based intersite-shared : Disabled
vrf-import : N/A
vrf-export : N/A
vrf-target : N/A
C-Mcast Import RT : N/A
ipmsi : rsvp mc-lsp

i-pmsi P2MP AdmSt : Up
spmsi : rsvp mc-lsp

s-pmsi P2MP AdmSt : Up
data-delay-interval: 3 seconds
===============================================================================
7
Miscellaneous
Auto-bind MPLS, eiBGP, GR helper at PE-CE, BFD at PE-CE for
OPSF
Miscellaneous
Auto-bind MPLS, eiBGP, GR helper and BFD at PE-CE
• Automatic binding to either RSVP-TE LSPs or LDP LSPs, as available
• eiBGP
• PE-CE adjacency
• Graceful Restart helper for OSPF and BGP when used as PE-CE protocols (GR helper
was already available in base router)
• BFD support for OSPF PE-CE adjacencies (already available for BGP and PIM)
• BGP next hop indirection
Auto-bind MPLS
Miscellaneous
Auto-bind MPLS
Auto-bind now has four options for automatic selection of the tunnel to BGP next-hop:
• auto-bind gre  use automatic GRE tunnels
• auto-bind ldp  use automatic LDP LSP to next-hop
• auto-bind rsvp-te  choose automatically an existing TE LSP
• auto-bind mpls  this was new in 7.0R3: choose an existing TE LSP if available,
otherwise use LDP
In all cases, if an explicit spoke-sdp is specified in the VPRN, it is always preferred over
automatically selected tunnels (even if the SDP is down  the route becomes
inactive, there is no fallback to the automatic selection).

auto-bind mpls
spoke-sdp 26 create
exit
Miscellaneous
Auto-bind MPLS: configuration
Let’s consider an example:
*A:PE2>config>service>vprn# info
----------------------------------------------
auto-bind mpls
interface "loopback" create
address 192.168.0.2/32
loopback
exit
address 192.168.103.2/24
ip-mtu 1500
exit
exit
spoke-sdp 25 create
shutdown
exit
spoke-sdp 26 create
exit
no shutdown
Miscellaneous
Auto-bind MPLS: checking
show router xxx route-table is a first checkpoint:

*A:PE2# show router 100 route-table
===============================================================================
Route Table (Service: 100)
===============================================================================
-------------------------------------------------------------------------------
192.168.0.1/32 this is via a specific Remote
SDP BGP VPN 00h05m02s 170
10.0.0.6 (tunneled) 0
(we know because we
192.168.0.2/32 Local Local 03d19h48m 0
loopback configured it!) 0
192.168.0.3/32 Remote BGP VPN 00h07m35s 170
10.0.0.3 (tunneled:RSVP:1) this is via 0
192.168.0.102/31 auto-boundRemote Static 21h12m54s 5
Black Hole 1
RSVP-TE LSP
192.168.103.9 (tunnel id 1) 1
192.168.16.0/24 Remote BGP VPN 00h05m02s 170 Note that there is no active
10.0.0.6 (tunneled) 0 route to 10.0.0.5, because
the spoke-sdp is down and
10.0.0.6 (tunneled) 0
192.168.103.0/24 Local Local 00h26m35s 0 there is no fallback to auto-
to-Epipe-red 0 selection
10.0.0.4 (tunneled) this is via auto-bound 0
192.168.254.0/24 LDP LSP (we knowRemote BGP VPN 00h06m17s 170
10.0.0.4 (tunneled) because there is no SDP 0
-------------------------------------------------------------------------------
configured)
No. of Routes: 10
===============================================================================
Miscellaneous
show router xxx fib is more explicit:

*A:PE2# show router 100 fib 1
===============================================================================
FIB Display
===============================================================================
Prefix Protocol
NextHop
-------------------------------------------------------------------------------
192.168.0.1/32 BGP_VPN
10.0.0.6 (VPRN Label:131068 Transport:SDP:26) this is via a specific
192.168.0.2/32 LOCAL
SDP (id 26)
192.168.0.2 (loopback)
192.168.0.3/32 BGP_VPN
this is via auto-bound
10.0.0.3 (VPRN Label:131071 Transport:RSVP LSP:1)
192.168.0.102/31
RSVP-TE
STATIC
LSP (tunnel id 1)
Blackhole
192.168.0.103/32 STATIC
192.168.103.9 (to-Epipe-red)
192.168.16.0/24 BGP_VPN
10.0.0.6 (VPRN Label:131068 Transport:SDP:26)
192.168.101.0/24 BGP_VPN
10.0.0.6 (VPRN Label:131068 Transport:SDP:26)
192.168.103.0/24 LOCAL
192.168.103.0 (to-Epipe-red)
192.168.253.0/24 BGP_VPN
this is via auto-bound
LDP LSP (no tunnel id)
192.168.254.0/24 BGP_VPN
-------------------------------------------------------------------------------
Total Entries : 10
-------------------------------------------------------------------------------
===============================================================================
Miscellaneous
show router tunnel-table can be useful to obtain information about the various
tunnels (LDP, RSVP, SDP) available for selection:
*A:PE2# show router tunnel-table
===============================================================================
Tunnel Table (Router: Base)
===============================================================================
Destination Owner Encap TunnelId Pref Nexthop Metric
-------------------------------------------------------------------------------
10.0.0.3/32 rsvp MPLS 1 7 10.2.3.3 100
10.0.0.3/32 ldp MPLS - 9 10.2.3.3 100
10.0.0.4/32 sdp MPLS 24 5 10.0.0.4 0
10.0.0.4/32 ldp MPLS - 9 10.2.4.4 100
10.0.0.5/32 sdp MPLS 25 5 10.0.0.5 0
10.0.0.5/32 ldp MPLS - 9 10.2.3.3 200
10.0.0.5/32 ldp MPLS - 9 10.2.4.4 200
10.0.0.6/32 sdp MPLS 26 5 10.0.0.6 0
10.0.0.6/32 ldp MPLS - 9 10.2.6.6 100
===============================================================================
Note how “Preference” and “Metric” are used for best tunnel selection:
* SDP has lowest (best) preference, followed by RSVP then by LDP
* if preference is the same, lowest metric is selected (ECMP is possible with LDP)
eiBGP
eiBGP
Description
In the situation below, while traffic from Bob to Alice can be balanced on both
links to PE2 and PE3, traffic from Alice to Bob will only use the PE3-CE7 link and
will never use the PE2-CE8 link, because the BGP-VPN route has a worse
preference than the eBGP route to CE8.
192.168.1.1
CE5
A:PE3# show router 100 route-table 192.168.2.0/24

----------------------------------------------------
Alice 192.168.2.0/24 Remote BGP
192.168.37.7
PE3 A:CE7# show router route-table 192.168.1.0/24

-----------------------------------------------
192.168.1.0/24 Remote BGP
192.168.27.2
192.168.1.0/24 Remote BGP
MPLS VPRN 192.168.37.3
192.168.2.1
PE2 CE7
Bob
eiBGP 7.0.R4
Description
In Release 7.0.R4 the eiBGP functionality was introduced.
When enabled, the VPRN PE disregards the different preference between eBGP
ipv4 and iBGP vpn-ipv4, obtraining routes with equal cost that can be both
active, therefore obtaining load balancing.
CE5
Alice
PE3
MPLS VPRN
PE2 CE8
Bob
eiBGP 7.0.R4
Configuration
In order to achieve the desired behaviour, a few thing must be configured in the
VPRN service on the PE:
- different route-distinguisher must be used on PE2 and PE3, otherwise the
alternate BGP-VPN route via PE2 might be suppressed by BGP selection
- ECMP must be enabled
- eiBGP special treatment must be enabled
ecmp 4
autonomous-system 999
auto-bind ldp
...
bgp
eibgp-loadbalance
group "Customer"
type external
export "export-vpn"
neighbor 192.168.37.7
peer-as 65100
exit
exit
exit
eiBGP 7.0.R4
Description
Result is that now there are two next-hops for the “Bob” subnet in PE3, one
directly to CE7 and one tunneled to PE2.
In order to avoid loops, the tunneled destination is not used for traffic coming
from a network tunnel, but only from a SAP or interface-terminated spoke SDP.
192.168.1.1
CE5
A:PE3# show router 100 route-table 192.168.2.0/24
----------------------------------------------------
Alice 192.168.2.0/24 Remote BGP VPN
10.0.0.2 (tunneled)
192.168.2.0/24 Remote BGP
192.168.37.7
PE3
MPLS VPRN
192.168.2.1
PE2 CE8
Bob
eiBGP
Description
It works for traffic coming into a VPRN interface, either from a SAP or from a
spoke-SDP.
Instead, traffic coming from a VPRN peer is not forwarded to another VPRN peer
(to avoid loops).
CE5
Alice
PE3
MPLS VPRN
EPIPE
R4
spoke-SDP
PE2 CE8
Bob
Charlie
Graceful Restart helper on PE-CE link
Miscellaneous
PE-CE GR helper
Graceful Restart helper for OSPF is enabled by default

*A:R6# show router 100 ospf status
configure service vprn 100
ospf =============================================
graceful-restart OSPF Status
helper-disable =============================================
exit ...
exit Graceful Restart : Enabled
GR Helper Mode : Disabled
Preference : 10
Graceful Restart helper for BGP is disabled by default.

It can be enabled globally, per group or per neighbor.
*A:R2# show router 100 bgp neighbor 192.168.128.8 graceful-restart
bgp ===================================================================
graceful-restart BGP Neighbor 192.168.128.8 Graceful Restart
exit ===================================================================
exit Graceful Restart locally configured for peer: Disabled
Peer's Graceful Restart feature : Disabled
...
Restart time locally configured for peer : 120 seconds
Restart time requested by the peer : 0 seconds
Time stale routes from peer are kept for : 360 seconds
Graceful restart status on the peer : Not currently being
helped
Number of Restarts : 0
Last Restart at : Never
BFD for PE-CE OSPF adjacency
BFD on PE-CE OSPF adjacency
Configuration
BFD must be first enabled on the interface:

interface "vprn100_to-R10" create *A:R6# show router 100 bfd interface
address 192.168.160.6/24
bfd 100 receive 100 multiplier 3 ===============================================================
sap 1/1/1:114 create BFD Interface
exit ===============================================================
exit Interface name Tx Interval Rx Interval Multiplier
---------------------------------------------------------------
vprn100_to-R10 100 100 3
---------------------------------------------------------------
No. of BFD Interfaces: 1
===============================================================
Then it may be enabled on within OSPF (per interface):

ospf
area 0.0.0.0
interface "vprn100_to-R10“
bfd-enable [remain-down-on-failure] Error occurs if interface is not configured yet:
exit INFO: OSPF #1062 OSPF BFD error - BFD not configured on interface
exit
exit *A:R6# show router 100 ospf interface "vprn100_to-R10" detail
...
---------------------------------------------------------------
State
---------------------------------------------------------------
...
Oper Metric : 100 Bfd Enabled : Yes
...
Next hop indirection on PE-CE
(thanks to Gilles and Dominique)
BGP Fast NextHop Resolution
IGP NH1
PE CE (BGP NH)
IGP NH2
In Forwarding Plane
180K BGP Single Msg to NP to update mapping
Routes 180K routes re-converge in 200～300 ms
BGP Prefix next BGP next Hop IGP Next

---------- ---------- ----------
P1.P1.P1.0/24 “PE2” PE2 “ P1”,”P2” IGP NH1 Adj1
…snip… …snip… …snip…
Px.Px.Px.0/24 “PE3” PE3 “P1” IGP NH2 Adj2

---------- ---------- ----------
180K 10 10
Pre-R8.0, not available for PE-CE routing. No CLI required (enabled by default).
8
VPRN on 7705
VPRN on 7705 SAR
Features
VPRN is available in 7705 as of Release 3.0

There are some limitations of course.
Things that are available:

• IPv4 unicast
• Local and distributed (MP-BGP)
• Auto-bind (LDP and GRE) and spoke-sdp
• According to user guide they are not supported at the same time; yet, it can be
configured and appears to work fine
• Hub and spoke, extranet etc.
• PE-CE: static routes (including cpe-check and bfd)
VPRN on 7705 will (of course) interop with 7750 and it should seamlessly
interop with other vendors’ IP-VPN as well.
VPRN on 7705 SAR
Limitations
Some things that are not available

• IPv6 (6VPE)
• Multicast (MVPN)
• Spoke-sdp termination in interface
• Loopback interfaces
• PE-CE: BGP, OSPF, RIP
• Auto-bind RSVP, auto-bind MPLS
• ECMP
• GRT lookup
• Hash label
• NTP
• Subscriber management
•…
VPRN on 7705 SAR
Configuration (service)
Configuration of the VPRN service is exactly the same as in 7750

A:PE4# show router 100 route-table route-distinguisher 999:100
auto-bind ldp
===============================================================================
Route Table (Service: 100) interface "test_if" create
===============================================================================
address 192.168.254.4/24
Next Hop[Interface Name]
sap 1/5/1:254 create
Metric
exit
-------------------------------------------------------------------------------
192.168.0.1/32 exit BGP VPN 00h05m16s
Remote 170
10.0.0.6 static-route 192.168.253.0/24
0 next-hop 192.168.254.253
192.168.0.2/32 spoke-sdp 42 create
Remote BGP VPN 00h05m16s 170
10.0.0.2 exit 0
192.168.0.3/32 Remote BGP VPN 00h05m16s
no shutdown 170
10.0.0.3 0
10.0.0.2 0
10.0.0.3 0
10.0.0.6 0
10.0.0.6 0
10.0.0.3 0
192.168.254.253 1
192.168.254.0/24 Local Local 00h06m03s 0
test_if 0
-------------------------------------------------------------------------------
No. of Routes: 10
===============================================================================
VPRN on 7705 SAR
Configuration (BGP)
Configuration of BGP is very similar to 7750

*A:PE4# configure router
autonomous-system 999
Supported families: ipv4 and vpn-ipv4
bgp
family vpn-ipv4
A:PE4# show router bgp summary
=============================================================================== group “rr”
BGP Router ID : 10.0.0.4 AS : 999 Local AS : 999 peer-as 999
=============================================================================== neighbor 10.0.0.9
BGP Admin State : Up BGP Oper State : Up exit
Total Peer Groups : 1 Total Peers : 1 exit
Total BGP Paths : 13 Total Path Memory : 1572 exit
Total IPv4 Remote Rts : 0 Total IPv4 Rem. Active Rts : 0
Total Supressed Rts : 0 Total Hist. Rts : 0
Total Decay Rts : 0
There is no “type internal/external” instruction
Total VPN Peer Groups : 0 Total VPN Peers if peer-as
: 0= our as, then it’s iBGP
Total VPN Local Rts : 2
Total VPN-IPv4 Rem. Rts : 9 Total VPN-IPv4 Rem. Act. Rts: 9
Total VPN Supp. Rts : 0 Total VPN Hist. Rts : 0
Total VPN Decay Rts : 0
===============================================================================
BGP Summary
===============================================================================
Neighbor
AS PktRcvd InQ Up/Down State|Rcv/Act/Sent (Addr Family)
PktSent OutQ
-------------------------------------------------------------------------------
10.0.0.9
999 11073 0 16h26m30s 9/9/2 (VpnIPv4)
10996 0
===============================================================================
VPRN on 7705 SAR
Scalability
A few relevant limits for VPRN and BGP in 7705
Limit Enforced? Error messsage / notes
VPRN services per node 16 yes MINOR: SVCMGR #1210 Reached the maximum
number of VPRN services

VPRN/IES interfaces 128 yes MINOR: SVCMGR #1506 Reached the maximum
number of service IP interfaces

SAP per ethernet port 128 yes MINOR: RESMGR #216 Insufficient Resources – SAP
Objects (port limit reached)

BGP peers 32 no Can configure more than 32 peers
BGP RIB 32K no Can process at least 60K vpn-ipv4 routes in one VPRN
Routes per VRF 16K no See above
SDP per VPRN 32 no
Data throughput ?
www.alcatel-lucent.com
www.alcatel-lucent.com

VPRN R8.0R01 v1.2.1

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VPRN R8.0R01 v1.2.1

Uploaded by

Copyright:

Available Formats

Release 8.

William Brioschi <william.brioschi@alcatel-lucent.com>

1. Network Time Protocol within VPRN

As a prerequisite, the PE must already be an NTP server in the base routing.

An external reference NTP server is still required (i.e. SR cannot act as a

NTP client and peer functionality is not available in VPRN PE.

1) The PE must be configured as an NTP client to an external reference. The

2) The PE must be configured to act as NTP server in the global context

A:PE3# configure system time ntp

3) NTP must be enabled within the VPRN context

A:PE3# configure system time ntp

A:PE3# configure service vprn 100

4) The CE may now be configured as a client to the PE

A:PE3# configure system time ntp

A:PE3# configure service vprn 100

5) Optionally authentication can be enabled. Authentication parameters are

A:PE3# configure service vprn 100 ntp

similar to “ntp-server authenticate” in global context

It is also possible to use broadcast mode (but not multicast mode).

NTP server CE9

A:PE3>config>service>vprn>ntp# broadcast interface to-CE9

Therefore, if you have “comprehensive” BOF static-routes, chances are that

A:PE3# show bof | match static

even if the client points to a different IP on the PE.

Apparently clients are never removed from the list.

IP (v4) pseudowires can now be terminated into a L3 interface (VPRN or IES)

The spoke-sdp must be configured as vc-type ipipe

Chassis mode C (IOM2 or better) is required (including 7710 and 7450-mixed)

IPv6 PW is not supported

*A:PE5# configure service ipipe 101 A:PE6# configure system chassis-mode c

IPv6 interfaces (VPRN or IES) can terminate Ethernet pseudowires

Standby TLDP signalling used to be ignored when terminating the pseudowire in

CE9 PE4 PE6

CE9 PE4 PE6

1) The endpoint on the epipe must be configured as A/S signalling master

CE9 PE4 PE6

CE9 PE4 ARP MPBGP PE6

Overall convergence time is dominated by BGP.

CE9 PE4 PE6

Configuration of PE2 is unchanged. A:PE2>config>service>vprn#

Configuration of PE3 is as follows. A:PE3>config>service>vprn#

CE9 PE4 PE6

interface "to-Epipe-red" create

CE9 PE4 PE6

interface "to-Epipe-red" create

CE9 PE4 PE6

interface "to-Epipe-red" create

CE9 PE4 PE6

interface "to-Epipe-red" create

CE9 PE4 PE6

interface "to-Epipe-red" create

CE9 PE4 PE6

CE9 PE4 PE6

Two routes available:

CE7 PE3 PE2 CE8

• Run a continuous ping from CE8 to CE7 192.168.0.7

• Try to reduce the convergence time – any trick is allowed 

There are two directions to cope with:

• from VPRN to base routing

• from base routing to VPRN

If a match is found in the VRF table, then that is used.

Otherwise, information from the GRT is used (if available).

The double lookup is not enabled by default.