Welcome to part three of many. In this post we’ll go over a Junos-IOS draft rosen interop. This entire time we have been doing draft rosen 7, otherwise known as ASM draft rosen. We could also do draft rosen 7, which is SSM. For now we’ll stick with draft rosen 6.
Same topology as last time. I’ve now added a Junos PE and CE router into the mix.
Junos PE core multicast config
I’m not going to show the basic IGP and MPLS config as that’s already been covered before.
darreno@J1> show configuration protocols pim
rp {
static {
address 3.3.3.3;
}
}
interface ge-0/0/1.0;
interface lo0.0;
Junos VRF PIM config
darreno@J1> show configuration routing-instances
A {
instance-type vrf;
interface ge-0/0/2.0;
interface lo0.1;
route-distinguisher 100:1;
vrf-target target:100:1;
protocols {
ospf {
export EXPORT;
area 0.0.0.0 {
interface ge-0/0/2.0;
interface lo0.1;
}
}
pim {
vpn-group-address 239.10.10.10;
interface ge-0/0/2.0;
interface lo0.1;
}
}
}
I’ve configured the default MDT group within the VRF config much like IOS. In order that Junos and IOS be compatible, I have to have a loopback with the same address as the local BGP peering loopback and that needs to be in the VRF. I’ve added lo0.1 to the above config, and this is the address configured:
darreno@J1> show configuration interfaces lo0
unit 0 {
family inet {
address 77.77.77.77/32;
}
}
unit 1 {
family inet {
address 77.77.77.77/32;
}
}
I need to add the MDT group to my MP-BGP config:
darreno@J1> show configuration protocols bgp
group L3MVPN {
local-address 77.77.77.77;
family inet-vpn {
unicast;
multicast;
}
family inet-mdt {
signaling;
}
peer-as 100;
neighbor 2.2.2.2;
neighbor 4.4.4.4;
neighbor 5.5.5.5;
}
The CE router is configured as normal enterprise multicast. R9 is still advertising itself as a BSR and RP candidate.
Verification
JR1 should see the three other PE routers plus the locally attached CE router. Note that Junos will use an mt interface (multicast tunnel)
darreno@J1> show pim neighbors instance A B = Bidirectional Capable, G = Generation Identifier H = Hello Option Holdtime, L = Hello Option LAN Prune Delay, P = Hello Option DR Priority, T = Tracking Bit Instance: PIM.A Interface IP V Mode Option Uptime Neighbor addr ge-0/0/2.0 4 2 HPLGT 00:30:30 10.0.78.8 mt-0/0/0.32768 4 2 HPG 00:15:40 2.2.2.2 mt-0/0/0.32768 4 2 HPG 00:00:27 4.4.4.4 mt-0/0/0.32768 4 2 HPG 00:15:40 5.5.5.5
JR2, our new CE, should see R9 as the RP:
darreno@J2> show pim rps Instance: PIM.master Address family INET RP address Type Mode Holdtime Timeout Groups Group prefixes 9.9.9.9 bootstrap sparse 25 19 3 224.0.0.0/4
Final confirmation
Let’s join the gorup 225.5.5.5 on JR2:
darreno@J2> show configuration protocols igmp
interface ge-0/0/2.0 {
static {
group 225.5.5.5;
}
}
NOTE: Junos will not respond to a ping sent to a multicast group. In order for your router to respond, you can add protocols sap (group_IP)
R9#ping 225.5.5.5 repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 225.5.5.5, timeout is 2 seconds: Reply to request 0 from 10.0.78.8, 28 ms Reply to request 0 from 10.0.128.12, 56 ms Reply to request 0 from 10.0.128.12, 52 ms Reply to request 0 from 10.0.78.8, 40 ms
Both JR2 and R12 are responding as expected.
End of draft rosen
Draft rosen certainly works. However as noted in part 1, multicast is required in the ISP core and this is not a very scalable technology, even when using the data MDT. One of the biggest issues you have is that for every multicast customer, your PE routers will maintain tunnels and PIM adjacencies with each other. If you have 10 PE routers with 4 multicast customers, that’s an awful lot of state running in your core. In parts four and onwards I’ll cover some of the newer ways that we can do MPLS L3 VPN Multicast.
I’ve seen a fair amount of debate where people are saying Cisco ‘stole’ the commit command from Juniper. Perhaps. But Juniper wasn’t the first to have a command available for staging configs before making them active.
Let’s look at this ancient (but still live) Riverstone RS3000:
RS135# conf RS135(config)# vlan create vlan26 ip id 26 RS135(config)# vlan add ports et.2.6 to vlan26 RS135(config)# interface create ip ip26 address-netmask 10.26.0.1/30 vlan vlan26
None of this is live. The config is merely staged. In order to check what will happen when we commit we check our ‘scratchpad’
RS135(config)# show scratchpad
******** Non-committed changes in Scratchpad ********
1*: vlan create vlan26 ip id 26
2*: vlan add ports et.2.6 to vlan26
!
3*: interface create ip ip26 address-netmask 10.26.0.1/30 vlan vlan26
To commit those changes:
RS135(config)# save active %VLAN-I-CREATED, VLAN vlan26 created with VLAN ID 26. To add ports to the VLAN, use the "vlan add ports" command. %INTERFACE-I-CREATEDIF, Interface ip26 was successfully created.
One thing the Riverstone doesn’t do is save those changes to the startup config. That is a separate step:
RS135(config)# save startup Are you sure you want to overwrite the Startup configuration [no]? yes %CONFIG-I-SAVED, configuration saved to Startup configuration.
The Riverstone also had some handy ‘diff’ commands which kind of worked like a show | compare in Junos.
Alas Riverstone Networks ceased to exist in 2006. They were bought out by Alcatel Lucent so are now under their umbrella.
I wanted to replicate the VRF using PBR post I did over here. Anyne who has used Junos will tell you that their version of PBR, while more powerful, is a lot more complicated that Cisco’s offering.
Let’s use the following topology:
R3 is going to be my source. It will have multiple interfaces configured. When I send traffic off to R2, I would like R2 to decide which VRF the packet should go into based on the source address used by R3. R2 and R4 are going to be simple ISP PE devices. R1 and R5 are going to be in VRF’s CUS1 and CUS5 respectively.
Configuration
CPE config
All the CPE routers have their loopback configured and have a static route pointing to their connected PE.
All the CPEs are configured simiraily. I’m only going to show the configuration of one.
USER3:R3> show configuration interfaces
ae1 {
unit 12 {
vlan-id 12;
family inet {
address 10.0.4.5/30;
}
}
}
lo0 {
unit 3 {
family inet {
address 3.3.3.3/32;
}
}
}
USER3:R3> show configuration routing-options
static {
route 0.0.0.0/0 next-hop 10.0.4.6;
}
PE Config
R4 is a regular PE so nothing special:
USER4:R4> show configuration
interfaces {
fe-0/0/3 {
unit 24 {
vlan-id 24;
family inet {
address 10.0.4.9/30;
}
family mpls;
}
}
ae1 {
unit 34 {
vlan-id 34;
family inet {
address 10.0.2.5/30;
}
}
unit 45 {
vlan-id 45;
family inet {
address 10.0.8.9/30;
}
}
}
lo0 {
unit 4 {
family inet {
address 4.4.4.4/32;
}
}
}
}
protocols {
mpls {
interface fe-0/0/3.24;
}
bgp {
group L3VPN {
local-address 4.4.4.4;
family inet-vpn {
unicast;
}
peer-as 100;
neighbor 2.2.2.2;
}
}
ospf {
area 0.0.0.0 {
interface fe-0/0/3.24;
interface lo0.4;
}
}
ldp {
interface fe-0/0/3.24;
}
}
routing-instances {
CUS1 {
instance-type vrf;
interface ae1.34;
route-distinguisher 100:1;
vrf-target target:100:1;
routing-options {
static {
route 1.1.1.1/32 next-hop 10.0.2.6;
}
}
}
CUS5 {
instance-type vrf;
interface ae1.45;
route-distinguisher 100:5;
vrf-target target:100:5;
routing-options {
static {
route 5.5.5.5/32 next-hop 10.0.8.10;
}
}
}
}
routing-options {
autonomous-system 100;
}
As you can see, R4 has a static route to R1 and R5 in each respective VRF. That information is then sent off to R2 as an MP-BGP update.
R2 is where all the magic happens. I need to ensure that packets coming into interface fe-0/0/3.12 via R3 is put into various VRFs based on the source address. I also need to ensure that R2 is able to get back to either these addresses over the VRF, even though interface fe-0/0/3.12 is not in a VRF.
First, let’s create a firewall filter that will match and move packets to the right VRF:
USER2:R2> show configuration firewall
family inet {
filter VRF_FBF {
term CUS1 {
from {
address {
192.168.1.1/32;
}
}
then {
routing-instance CUS1;
}
}
term CUS5 {
from {
address {
192.168.5.5/32;
}
}
then {
routing-instance CUS5;
}
}
term ANY {
then accept;
}
}
}
If a packet comes in with a source address of 192.168.1.1/32, send that off to the CUS1 vrf. If it comes in with a source address of 192.168.5.5/32, send that off to the CUS2 vrf. I’ve then got a catch-all to ensure any other packets are not dropped. Once that filter is created. I need to apply it inbound in my interface:
USER2:R2> show configuration interfaces fe-0/0/3.12
vlan-id 12;
family inet {
filter {
input VRF_FBF;
}
address 10.0.4.6/30;
}
This is great for packets coming into R2 from R3, but what about getting back? I could create static routes in each VRF, but the actual link between R2 and R3 is not in any VRF. i.e. the next-hops will not be able to be resolved. I could have a static route pointing to the default/global vrf, but I could also use a rib-group to get that interface into both vrfs.
Let’s try the second option. I wanted to get 10.0.4.4/30 into both VRFs. I also want to ensure only this link gets into the vrf and not all the others.
USER2:R2> show configuration policy-options
policy-statement R2-R3-LINK {
term 1 {
from {
route-filter 10.0.4.4/30 exact;
}
then accept;
}
term 2 {
then reject;
}
}
USER2:R2> show configuration routing-options rib-groups
GLOBAL_TO_VRF {
import-rib [ inet.0 CUS1.inet.0 CUS5.inet.0 ];
import-policy R2-R3-LINK;
}
USER2:R2> show configuration routing-options interface-routes
rib-group inet GLOBAL_TO_VRF;
The above says to match 10.0.4.4/30 and nothing else. That is applied to interface-routes which calls a rib-group. That rib-group states that when the interface route is placed in the default/global RIB, place it in CUS1 and CUS5′s RIB at the same time.
Verification
The end result of this is from from R2′s perspective, in the CUS1 RIB I should see R1′s address, R3′s 192.168.1.1/32 address, the R2-R3 link, and the R4-R1 link:
USER2:R2> show route table CUS1
CUS1.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1.1.1.1/32 *[BGP/170] 01:17:21, localpref 100, from 4.4.4.4
AS path: I
> to 10.0.4.9 via ae1.24, Push 299792
10.0.2.4/30 *[BGP/170] 01:17:21, localpref 100, from 4.4.4.4
AS path: I
> to 10.0.4.9 via ae1.24, Push 299792
10.0.4.4/30 *[Direct/0] 00:56:02
> via fe-0/0/3.12
192.168.1.1/32 *[Static/5] 00:56:02
> to 10.0.4.5 via fe-0/0/3.12
If we check CUS5′s RIB, I should see R5′s address, R3′s 192.168.5.5/32 address, the R2-R3 link again, and the R4-R5 link:
USER2:R2> show route table CUS5
CUS5.inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
5.5.5.5/32 *[BGP/170] 01:23:36, localpref 100, from 4.4.4.4
AS path: I
> to 10.0.4.9 via ae1.24, Push 299808
10.0.4.4/30 *[Direct/0] 00:58:51
> via fe-0/0/3.12
10.0.8.8/30 *[BGP/170] 01:23:36, localpref 100, from 4.4.4.4
AS path: I
> to 10.0.4.9 via ae1.24, Push 299808
192.168.5.5/32 *[Static/5] 00:58:51
> to 10.0.4.5 via fe-0/0/3.12
So our control plane is working perfectly fine. Let’s check our data plane for the final verification:
USER3:R3> ping 1.1.1.1 source 192.168.1.1 rapid PING 1.1.1.1 (1.1.1.1): 56 data bytes !!!!! --- 1.1.1.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.252/1.466/1.823/0.211 ms USER3:R3> ping 1.1.1.1 source 192.168.5.5 rapid PING 1.1.1.1 (1.1.1.1): 56 data bytes ..... --- 1.1.1.1 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss
R3 to R1 is working as expected. Let’s check R3 to R5:
USER3:R3> ping 5.5.5.5 source 192.168.5.5 rapid PING 5.5.5.5 (5.5.5.5): 56 data bytes !!!!! --- 5.5.5.5 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.262/1.358/1.577/0.115 ms USER3:R3> ping 5.5.5.5 source 192.168.1.1 rapid PING 5.5.5.5 (5.5.5.5): 56 data bytes ..... --- 5.5.5.5 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss
No problems there.
VPLS is a LAN emulation service that can be run over an MPLS backbone. I do not have a ton of free devices on hand and so my acual lab will only consist of two CE devices even though it supports more than two. VPLS runs over an MPLS core constructed by RSVP-TE or LDP LSP tunnels. VPLS itself requires either LDP (RFC 4762) or BGP (RFC 4761) as the VC singnalling protocol. Note that when LDP is used, this is a targeted LDP session and has nothing to do with the protocol you use for the LSPs itself. To prove this I will be using RSVP-TE LSP tunnels with LDP and BGP on top.
Part one of this series will use LDP as the VC signalling protocol. Part two will use BGP.
I was originally going to include Cisco’s IOS as well, but you need a 6500 or 7600 and I don’t have a spare. The 7200 platform does not support VPLS.
This the the topology I’m going to use:
R2 and R3 are P routers. R1 is a Junos PE and R8 is a Netiron PE. R6 and R10 are both CPEs
The actual P router config is standard RSVP-TE which I have covered extensively on this site already. The CPE’s have both been configured to be in the same subnet (10.0.0.0/24)
PE Config
Junos
darreno> show configuration interfaces fe-0/0/2
encapsulation ethernet-vpls;
unit 0 {
family vpls;
}
darreno> show configuration protocols ldp
interface lo0.1;
darreno> show configuration routing-instances
MELLOWD-VPLS {
instance-type vpls;
interface fe-0/0/2.0;
protocols {
vpls {
vpls-id 150;
neighbor 8.8.8.8;
}
}
}
On Junos you need to enable LDP on the loopback interface, even when running RSVP. You need to ensure VPLS encapsulation is on the physical interface. Finally you need to create the VPLS instance and tie this all together. You specify neighbours under the process. This actually creates the targeted LDP sessions (i.e. there is no need to specify a T-LDP session separately)
PE Config
Netiron
Brocade’s Netiron config is actually very simple compared to the above
router mpls mpls-interface ve2 vpls MELLOWD-VPLS 150 vpls-peer 1.1.1.1 vpls-mtu 1500 vlan 550 tagged ethe 3/19
That’s it. When you enable rsvp on an interface, and then set up a VPLS with a neighbour, it automatically sets up a T-LDP session with it’s peer. Under the VLAN I’ve said tagged eth 3/19 as it’ll be receiving tagged frames from the CPE router.
Verification
Control Plane
Let’s check to see if the session is actually up:
darreno> show vpls connections
Layer-2 VPN connections:
Legend for connection status (St)
[deleted for brevity]
Legend for interface status
Up -- operational
Dn -- down
Instance: MELLOWD-VPLS
VPLS-id: 150
Neighbor Type St Time last up # Up trans
8.8.8.8(vpls-id 150) rmt Up Mar 8 13:52:45 2013 1
Remote PE: 8.8.8.8, Negotiated control-word: No
Incoming label: 800000, Outgoing label: 983040
Negotiated PW status TLV: No
Local interface: vt-0/2/0.1048579, Status: Up, Encapsulation: ETHERNET
Description: Intf - vpls MELLOWD-VPLS neighbor 8.8.8.8 vpls-id 150
SSH@XMR_R8# show mpls vpls id 150 VPLS MELLOWD-VPLS, Id 150, Max mac entries: 8192 Routing Interface Id 150 Total vlans: 1, Tagged ports: 1 (1 Up), Untagged ports 0 (0 Up) IFL-ID: n/a Vlan 550 L2 Protocol: NONE Tagged: ethe 3/19 VC-Mode: Raw Total VPLS peers: 1 (1 Operational) Peer address: 1.1.1.1, State: Operational, Uptime: 55 min Tnnl in use: tnl2(299984)[RSVP] Peer Index:0 Local VC lbl: 983040, Remote VC lbl: 800000 Local VC MTU: 1500, Remote VC MTU: 1500 Local VC-Type: Ethernet(0x05), Remote VC-Type: Ethernet(0x05) CPU-Protection: OFF Local Switching: Enabled Extended Counter: ON Multicast Snooping: Disabled
Both sessions are up. Both see the others VC labels. Can we show that LDP is actually used?
darreno> show ldp neighbor Address Interface Label space ID Hold time 8.8.8.8 lo0.1 8.8.8.8:0 36
SSH@XMR_R8#sh mpls ldp neighbor Number of link neighbors: 0 Number of targeted neighbors: 1 Nbr Transport Interface Nbr LDP ID Max Hold Time Left 1.1.1.1 (targeted) 1.1.1.1:0 45 42
Verification
Data Plane
So can our CPE’s ping each others?
R10#ping 10.0.0.6 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.6, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/12 ms
USER6:R6> ping 10.0.0.10 rapid count 5 PING 10.0.0.10 (10.0.0.10): 56 data bytes !!!!! --- 10.0.0.10 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.368/1.460/1.755/0.148 ms
No problems there. It’s always handy to check MAC addresses learned over the VPLS. We can check like so:
darreno> show route forwarding-table family vpls
Routing table: MELLOWD-VPLS.vpls
VPLS:
Destination Type RtRef Next hop Type Index NhRef Netif
default perm 0 rjct 1007 1
fe-0/0/2.0 user 0 comp 1150 2
vt-0/2/0.1048579 user 0 comp 1258 2
00:12:f2:93:a9:00/48 dynm 0 indr 262142 5
10.0.4.14 Push 983040, Push 299920(top) 1233 2 ae1.13
00:13:19:22:8f:91/48 dynm 0 ucst 1146 4 fe-0/0/2.0
00:90:69:a5:13:f1/48 dynm 0 ucst 1146 4 fe-0/0/2.0
8c:b6:4f:63:46:b8/48 dynm 0 indr 262142 5
10.0.4.14 Push 983040, Push 299920(top) 1233 2 ae1.13
SSH@XMR_R8#sh mac vpls 150 Total MAC entries for VPLS 150: 4 (Local: 1, Remote: 3) VPLS MAC Address L/R/IB Port Vlan(In-Tag)/Peer ISID Age Type ==== =========== ====== ==== ================= ==== === ==== 150 8cb6.4f63.46b8 L 3/19 550 NA 70 NA 150 0a0a.0009.0004 R 3/7 1.1.1.1 NA 250 NA 150 0013.1922.8f91 R 3/7 1.1.1.1 NA 0 NA 150 0090.69a5.13f1 R 3/7 1.1.1.1 NA 70 NA
Both outputs show local and remote locations of MAC addresses. Both also show the neighbour ID of who has the directly connected MAC address.
Management over the VPLS
A handy new feature on the Netiron is the ability to have a layer3 interface over the VPLS. This can be handy when you need to manage the CPE devices. While in the past you may need to have a ‘break-in’ interface also attached to the VPLS, you can now do it directly on the Netiron.
interface ve 150 ip address 10.0.0.8/24 ! router mpls vpls MELLOWD-VPLS 150 router-interface ve 150
This essentially works like in SVI interface on a vlan. Let’s check if we have communication:
SSH@XMR_R8#ping 10.0.0.10 Sending 1, 16-byte ICMP Echo to 10.0.0.10, timeout 5000 msec, TTL 64 Type Control-c to abort Reply from 10.0.0.10 : bytes=16 time=1ms TTL=255 Success rate is 100 percent (1/1), round-trip min/avg/max=1/1/1 ms. SSH@XMR_R8#ping 10.0.0.6 Sending 1, 16-byte ICMP Echo to 10.0.0.6, timeout 5000 msec, TTL 64 Type Control-c to abort Reply from 10.0.0.6 : bytes=16 time=1ms TTL=64 Success rate is 100 percent (1/1), round-trip min/avg/max=1/1/1 ms.
This is part two of my blog started here: http://mellowd.co.uk/ccie/?p=3300
Same diagram as last time:
This time each CPE is going to be connected to a VRF on the PE router. I’m only using one customer for this post, but this is regular L3VPN so scale as you see fit.
Major issue with the Netiron. It doesn’t support the VPNV6 adress family :( – I’m using the latest 5.4b code and nothing. So this means this is a Junos/IOS lab only
CPE config
All the CPEs are running BGP with their directly connected PE routers. All are advertising reachability to their IPv6 loopback addresses to their PE router. I’m only showing R6′s config as the others are the same with different addresses:
interfaces {
ae1 {
unit 36 {
vlan-id 36;
family inet6 {
address 2001:db8:36::6/64;
}
}
lo0 {
unit 6 {
family inet6 {
address 2001:db8:6666::6666/128;
}
}
}
}
protocols {
bgp {
group PROVIDER {
family inet6 {
unicast;
}
export LOOPBACK;
neighbor 2001:db8:36::3 {
peer-as 100;
}
}
}
}
policy-options {
policy-statement LOOPBACK {
from {
protocol direct;
route-filter 2001:db8:6666::6666/128 exact;
}
then accept;
}
}
routing-options {
router-id 6.6.6.6;
autonomous-system 65123 loops 2;
}
You’ll need to statically define your router-id for all sites. If a router is running ONLY IPv6, or your VRF ONLY has a IPv6 address, then the router has no IPv4 address to choose it’s router-id from. This will be a common theme throughout as you’ll also need to set router-ids in IPv6-only VRF instances.
PE config
Junos
First we need to set up the VRF to the customer and run BGP. We then need to enable the VPNV6 family in BGP. I’m going to remove the old IPv6 unicast config used in part one of this series.
USER3:R3> show configuration protocols
mpls {
ipv6-tunneling;
interface ae1.13;
}
bgp {
group 6VPE {
family inet6-vpn {
unicast;
}
peer-as 100;
neighbor 4.4.4.4;
}
}
USER3:R3> show configuration routing-instances
CUSTOMER1 {
instance-type vrf;
interface fe-0/0/3.36;
route-distinguisher 3.3.3.3:1;
vrf-target target:100:1;
routing-options {
router-id 3.3.3.3;
}
protocols {
bgp {
group EXTERNAL {
advertise-peer-as;
family inet6 {
unicast;
}
neighbor 2001:db8:36::6 {
peer-as 65123;
}
}
}
}
}
IPv6 address family running with the customer. VPNv6 address family running with IOS PE R4. Note that I have to use ‘advertise-peer-as’ on R3 as Junos will not advertise a route to an AS that already has the AS number in the path by default.
IOS
The main issue with IOS is that I cannot statically definate a BGP router-id if I’m ONLY running IPv6. BGP requires a router-id on the x.x.x.x format. IOS does not give me the option to hard-code a router-id under the BGP process for the VRF, or the ipv6 unicast address family. So I had to enable the ipv4 address-family under the VRF and define a loopback address in the VRF to use as the router-id. Very silly indeed.
vrf definition CUSTOMER1 rd 4.4.4.4:100 ! address-family ipv4 exit-address-family ! address-family ipv6 route-target export 100:1 route-target import 100:1 exit-address-family ! interface Loopback4 vrf forwarding CUSTOMER1 ip address 4.4.4.4 255.255.255.255 ! router bgp 100 bgp router-id vrf auto-assign no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 3.3.3.3 remote-as 100 neighbor 3.3.3.3 update-source Loopback0 ! address-family vpnv6 neighbor 3.3.3.3 activate neighbor 3.3.3.3 send-community extended exit-address-family ! address-family ipv6 vrf CUSTOMER1 no synchronization neighbor 2001:DB8:47::7 remote-as 65123 neighbor 2001:DB8:47::7 activate exit-address-family
VRF assigned to the CE-PE link. IPv6 unicast running with the CPE and VPNv6 running with the Junos PE R3 router.
Verification
Let’s first check if our VPNv6 sessions are up:
7200_SRD_R4#show bgp vpnv6 unicast all neighbors 3.3.3.3 | include state|fam$
BGP state = Established, up for 03:09:47
Address family VPNv6 Unicast: advertised and received
For address family: VPNv6 Unicast
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
USER3:R3> show bgp neighbor 4.4.4.4 | match "Estab|NLRI" Type: Internal State: Established Flags:NLRI for restart configured on peer: inet6-vpn-unicast NLRI advertised by peer: inet6-vpn-unicast NLRI for this session: inet6-vpn-unicast
Sessions are up and running the VPNv6 family.
Can the CE’s ping each other from their IPv6 loopbacks?
USER7:R7> ping 2001:db8:6666::6666 source 2001:db8:7777::7777 rapid count 5 PING6(56=40+8+8 bytes) 2001:db8:7777::7777 --> 2001:db8:6666::6666 !!!!! --- 2001:db8:6666::6666 ping6 statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/std-dev = 1.520/1.726/1.997/0.195 ms
USER6:R6> ping 2001:db8:7777::7777 source 2001:db8:6666::6666 rapid count 5 PING6(56=40+8+8 bytes) 2001:db8:6666::6666 --> 2001:db8:7777::7777 !!!!! --- 2001:db8:7777::7777 ping6 statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/std-dev = 1.533/1.706/1.968/0.147 ms
No problems there :)
Comments