EIGRP SIA (Stuck-In-Active) through animations.

EIGRP SIA (Stuck-In-Active) process through animations:

“Active” = Actively looking for a route to a network (Successor)

Without SIA

Browse in separate page

With SIA

Browse in separate page

GET VPN, it is all about group.

GET VPN uses a group security paradigm comparing to the traditional point-to-point security paradigm like DMVPN, GRE IPSec or SSL. Do not confuse with any-to-any mesh which is the result of n(n-1)/2 point-to-point security associations between n peers.

We are talking about group security association (SA), group states and group keys.

Because each group member doesn’t know in advance about other group members, a central entity named key server (KS) need to manage GET VPN control plane: group member registration, distribute group keys and do the rekeys (updating security policy and group keys).

Once a group member has registered with the KS to a group, it can take care of the data plane encrypted communication with any of the other group members using the received group key and group security policy.

GET VPN doesn’t create the VPN perimeter (like Frame Relay for example), all group members and the key server are supposed to be already in the same VPN.

This lab is not supposed to be a comprehensive GET-VPN reference. Because it is all about a stories and process dynamics, I opted for a more visual approach: less words, more pictures.

I included a table summarizing the key characteristics of GET-VPN comparing with traditional IPSec, followed by a step-by-step animation of the main processes of GET-VPN.

Only then, I provide some configurations of the core MPLS-VPN and GET-VPN key server and group member.

And finally the offline lab with a myriad of useful commands collected during a running session.

By rushing to the CLI, you can easily drown yourself in a cup of water 🙂 Better take the time to understand the overall process, then configuration and troubleshooting will be straightforward and more instructive.

Outline:

• Comparison of GETVPN vs traditional IPSec.
• Summary of the main concepts
• Step-by-step GETVPN process
• Lab details
• • MPLS-VPN configuration
    • Core
    • PE_CE
  • GET VPN configuration
    • Basic Group member template
    • Basic key server
• Offline lab
• Troubleshooting

Comparison table (IPSec GET vpn)

	IPSec Crypto	GET Crypto
Main concept	Per link point-to-point security paradigm: each pair of devices establishes a separate security association.(figure3)	Group-based security paradigm: allows a set of network entities to connect through a single group security association.
Encapsulation	Requires the establishment of tunnel to secure the traffic between encrypting gateways.- a new header is added to the packet (figure4).- Limited QoS preservation (only ToS).	Tuneless: does not use tunnels and preserves the original src/dst IP in the header of the encrypted packet for optimal routing (figure6).- Preserve same established routing path.- Preserve entire QoS parameter set.
Multicast	– Traditional IPSec encapsulate multicast into encrypted PTP unicast GRE tunnels.- Alternatively, inefficient multicast replication at the HUB using DMVPN with many multicast deployment restrictions (RP, MA and multicast source location at the HUB).	GET VPN is particularly suited for multicast traffic encryption with native support. The WAN multicast infrastructure is used to transport encrypted GET-VPN multicast traffic.
Infrastructure	IPSec creates Overlay VPN and secures it over the Internet.	• Relies on MPLS/VPLS Any-to-Any VPN.• Direct Flows between all CE.• Leverages Existing VPNs.- GET VPN suited for enterprises running over MPLS private networks.- GET-VPN ONLY secure an already established VPN (MPLS-VPN), it doesn’t create it
Management	– Per-link security management: Each pair holds a security association for each other.- Resource consumption.- Alternative centralized HUB-based management with DMVPN though heterogeneous protocol suite (mGRE, NHRP)- Less scalable.	– Full mesh direct communications between sites.Same group members hold a single security association; don’t care about others on the group.- Relies on centralized membership management through key servers :A centralized entity (Key Server manage the control plane) and not involved in the data plane communication.Data plane communications don’t require transport through a hub HUB entity.- Low latency/jitter. – More scalable.
Security Perimeter	Per-link	All Sites within the same group.
Routing	Two routing levels(figure5a):Core routing+Overlay routing between encrypting gateways	Single end-to-end routing level with MPLS-VPN as the underlying VPN infrastructure(figure6a).

Figure3- Traditional IPSec PTP SAs between GMs

Figure4- Traditional IPSec PTP Packet

Figure5a-Traditional IPSec routing overlay

Figure6- Get-VPN IPSec PTP Packet + TEK

Figure6a- GETVPN end-to-end routing

 Summary of the main concepts

The key server manages the control operations (group member registration and rekey and policy distribution) on a different plane, initially, under the protection of IKE, after that, protected by a common key (KEK) (figure7/8).

Rekey process can be done using unicast (default) or multicast.

Any-to-any GM communications are performed on a separate data plane using the received TEK (Traffic Encryption Key) (figure9).

COOP (Co-operative key server protocol)

• A Key Server redundancy feature allowing key server communication to synchronize the keying information.

GDOI protocol (Group Domain of Interpretation)

• Used for policy & key deployment with group members.

Make sure to differentiate between registration vs rekey and between authentication vs authorization processes.

A-Registration process:

1- There is two types of KS-GM authentications):

• Shared key (deployed on the lab): a simple secret key shared (hopefully out-of-band) by the KS and all GMs (or per-pair).
• RSA (CA-based authentication): uses asymmetric encryption with public/private key pair and requires PKI infrastructure:
  • Enrollment phase:
    • Client (GM) gets CA certificate (CA public key signed with CA private key)
    • Client enrollment with CA
      • Client sends its own certificate (client public key signed with client private key)
      • CA signs the client certificate with its own (CA) public key and sends it to the client.
  • Peer-to-peer (GM-to-KS) authentication:
    • Peers exchanges and verify each other signatures using CA public key.

2- Authorization (during registration):

• KS verifies the group id number of the GM: If this id number is a valid and the GM has provided valid Internet Key Exchange (IKE) credentials, the key server sends the SA policy and the Keys to the group member.

B-Rekey process (after registration): uses asymmetric encryption with public/private key pair:

• The Primary KS uses the private & public keys (asymmetric) generated before the registration and export them to other secondary KSs.
• Primary KS generates Group control / data plane keys, TEK and KEK (symmetric keys)
• The KS signs TEK/KEK + policy with its own private key and sends them to GMs(figure7/8/9)
• The KS distributes public key to all GMs.
• GMs check the rekeys with the received KS public key

Figure7- Control plane: GM registration

Figure8- Control plane: rekey using KEK key

Figure9- GM data plane communications using TEK key

Step-by-step GET-VPN process

Click the picture below to browse the swf animation explaining GET-VPN interactions:

Lab details

Here is the lab topology, pretty straight forward, three group members and one key server with MPLS-VPN as the underlying VPN infrastructure.

Figure1- High-level lab topology

Figure2- Low-level lab topology

GET VPN:

• Customer equipments (CE) R9, R10 and R12 play the role of GETVPN group members (GM),
• R11 plays the role of the key server.

MPLS_VPN:

• R2, R3 and R5 are the MPLS-VPN PEs (Provider Edge equipment)

MPLS-VPN configuration:

Make sure the underlying MPLS-VPN topology works fine and all connectivity are successful before touching GET VPN.

For the sake of simplicity, a single MPLS core router (label switching router) R4 is used and static routing between CE_PE.

Figure2- Low-level MPLS-VPN lab infrastructure (MPLS LSR + PEs)

MPLS-VPN basic configuration with PE-CE static routing

• R4 the MPLS core router (LSR) is configured as BGP route reflector.
• Make sure PE equipments (wan interfaces and loopback rid’s) are reachable though MPLS core OSPF.
• Enable MPLS on the interfaces facing PE’s.
• Each PE (R2, R3 and R5) has similar configuration and a template can be used to scale client numbers.

Because this lab is not focused on MPLS-VPN, a simple PE-CE static routing is deployed. Each client has its interface and static route in the appropriate VRF. Generally multiple clients (VRFs) separately coexist in a single PE and the core transport is done through vpnv4 to and from other PE’s (figure2a)

Figure2a- MPLS-VPN PE Virtual Router Forwarding

With PE-CE static routing, only one-side redistribution is done, from static to vpnv4 address family.

You will find all details in the offline lab.

R4 (MPLS LSR router)

interface Loopback0ip address 10.0.0.4 255.255.255.255ip ospf 2345 area 0! interface FastEthernet0/0 ip address 192.168.45.4 255.255.255.0 ip ospf 2345 area 0 mpls label protocol ldp mpls ip ! interface FastEthernet0/1 ip address 192.168.24.4 255.255.255.0 ip ospf 2345 area 0 mpls label protocol ldp mpls ip ! interface FastEthernet1/0 ip address 192.168.34.4 255.255.255.0 ip ospf 2345 area 0 mpls label protocol ldp mpls ip ! router ospf 2345 ! router bgp 2345 no synchronization bgp router-id 4.4.4.4 network 192.168.24.0 network 192.168.34.0 network 192.168.45.0 neighbor 10.0.0.2 remote-as 2345 neighbor 10.0.0.2 route-reflector-client neighbor 10.0.0.3 remote-as 2345 neighbor 10.0.0.3 route-reflector-client neighbor 10.0.0.5 remote-as 2345 neighbor 10.0.0.5 route-reflector-client no auto-summary ! address-family vpnv4 neighbor 10.0.0.2 activate neighbor 10.0.0.2 send-community extended neighbor 10.0.0.2 route-reflector-client neighbor 10.0.0.3 activate neighbor 10.0.0.3 send-community extended neighbor 10.0.0.3 route-reflector-client neighbor 10.0.0.5 activate neighbor 10.0.0.5 send-community extended neighbor 10.0.0.5 route-reflector-client exit-address-family

R4#sh ip bgp summBGP router identifier 4.4.4.4, local AS number 2345…10.0.0.2 4 2345 134 137 4 0 0 02:09:53 0 10.0.0.3 4 2345 134 137 4 0 0 02:09:43 0 10.0.0.5 4 2345 136 137 4 0 0 02:09:52 0 R4#

GET-VPN configuration:

Key server:

crypto isakmp policy 1encr aesauthentication pre-sharegroup 2!crypto isakmp key cisco address 192.168.103.10 crypto isakmp key cisco address 192.168.29.9 crypto isakmp key cisco address 192.168.125.12 ! crypto ipsec transform-set transform128 esp-aes esp-sha-hmac ! crypto ipsec profile profile1 set security-association lifetime seconds 7200 set transform-set transform128 ! crypto gdoi group gdoi-group1 identity number 91011 server local rekey algorithm aes 128 rekey retransmit 10 number 2 rekey authentication mypubkey rsa rekey-rsa rekey transport unicast sa ipsec 1 profile profile1 match address ipv4 getvpn-acl address ipv4 192.168.115.11 ! interface FastEthernet0/0 ip address 192.168.115.11 255.255.255.0 ! ip access-list extended getvpn-acl deny icmp any any deny udp any eq 848 any eq 848 deny tcp any any eq 22 deny tcp any eq 22 any deny tcp any any eq tacacs deny tcp any eq tacacs any deny tcp any any eq bgp deny tcp any eq bgp any deny ospf any any deny eigrp any any deny udp any any eq ntp deny udp any eq ntp any deny udp any any eq snmp deny udp any eq snmp any deny udp any any eq snmptrap deny udp any eq snmptrap any deny udp any any eq syslog deny udp any eq syslog any permit ip any any

You can recognize usual IPSec components: crypto policy, shared keys, transform-sets wrapped in an ipsec profile, followed by GETVPN GDOI group policy ( ipsec profile and group policy (group-id, symm. encr. Algorithm, asymmetric keys to use during rekey authentication and getvpn acl)

The GETVPN ACL defines what will not be encrypted; consider your own topology needs:

• Exclude already encrypted traffic (https, ssh, etc.)
• Exclude PE-CE routing protocols.
• Exclude GETVPN control plane protocols( gdoi udp 848, tacacs, radius, etc.)
• Exclude Management/monitoring protocols (snmp. syslog, device remote access, icmp, etc.)

Group member template:

crypto isakmp policy 1encr aesauthentication pre-sharegroup 2crypto isakmp key cisco address 192.168.115.11! crypto gdoi group gdoi-group1 identity number 91011 server address ipv4 192.168.115.11 ! crypto map map-group1 10 gdoi set group gdoi-group1 ! interface FastEthernet0/0 crypto map map-group1

All control plane parameters are controlled by the KS, GMs are dumb devices. All they have to know is how to initiate IKE phase1 for preshared or RSA authentication with the KSs to register and get the keys, which groups they want to join, to which KS they will talk (if many configured) and finally, the get crypto-map assigned to the outbound interface.

Troubleshooting:

When practicing or during tenacious data plane issues, a good idea is to use ESP-NULL, the null encryption, where the encryption process is engaged, but packets are not encrypted.

This will make much easier the packet content inspection and marking between GMs.

To facilitate the deployment and the troubleshooting, think about the topology in terms of separate technology sub-domains; make sure everything works fine before moving to the next sub-domain.

• Layer2 MPLS
• MPLS-VPN
• Core routing
• PE-CE routing
• Core SSM multicast (if not unicast rekey)
• CA infrastructure (if you are not using shared keys to authenticate GMs to the KS)

Possible issues	Possible causes
key servers doesn’t exchange all announcements	Bad buffer – default buffer is not enough for large nbr of gm
Reassembly timed out	Some announcement fragments are dropped or lostICMP (packet too big) denied in the pathNo fragmentation because df bit setPresence of MTU bottlenecks, multipaths, firewalls.Not tuned tcp mss “ip tcp adjust-mss”
ike failure- failed negotiation	Preshared key mismatchIKE parameters mismatchTransport issues between GMs and KSs
Nothing works just after GM registration.	GETVPN acl policy cause routing traffic encryption: traffic not symmetrically excluded
KS not synchronizing	Check KS-KS transport: avoid making KS-KS communications dependent on GET-VPN successful transport.Keys not exported or not imported
Rekey not delivered	Issue with multicast infrastructure.Issue with mVPN service.

For more detailed GETVPN troubleshooting, I urge you to watch the excellent CiscoLive session by Wen Zhang https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=78699&tclass=popup

Offline lab:

Click  the picture below to browse the flash app of the offline lab:

References:

http://www.cisco.com/c/en/us/products/security/group-encrypted-transport-vpn/index.html

http://www.cisco.com/c/en/us/products/collateral/security/group-encrypted-transport-vpn/deployment_guide_c07_554713.html

https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=78699&tclass=popup

http://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Aug2013/CVD-GETVPNDesignGuide-AUG13.pdf

https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=7907&backBtn=true

http://www.cisco.com/c/en/us/td/docs/ios/12_4t/12_4t11/htgetvpn.html

http://tools.ietf.org/html/rfc3547

http://tools.ietf.org/rfc/rfc4534.txt

DMVPN animation

Here is an interactive animation of DMVPN (Dynamic Multipoint VPN), followed by a detailed offline lab (a snapshot of the topology under test with hopefully all commands needed for analysis and study).

Finally, check your understanding of the fundamental concepts by taking a small quiz.

Studied topology:

Animation

http://hpnouri.free.fr/dmvpn/DMVPN.swf

Offline Lab

http://hpnouri.free.fr/dmvpn/offlinelabv1025.swf

You might consider the following key points for troubleshooting:

Routing protocols:

To avoid RPF failure, announce routing protocols only through tunnel interfaces.

EIGRP

• Turn off “next-hop-self” to makes spokes speak directly. Without it traffic between spokes will always pass through the HUB and NHRP resolution will not occur.
• Turn off “split-horizon” to allow eigrp to advertise a received route from one spoke to another spoke through the same interface.
• Turn off sumarization
• Pay attention to the bandwidth required for EIGRP communication. requires BW > tunnel default BW “bandwidth 1000”

OSPF

• “ip ospf network point-to-multipoint”, allows only phase1 (Spokes Data plane communication through the HUB)
• “ip ospf broadcast” on all routers allows Phase2 (Direct Spoke-to-spoke Data plane communication)
• Set the ospf priority on the HUBs (DR/BDR) to be bigger than the priority on spokes (“ip ospf priority 0”).
• Make sure OSPF timers match if spokes and the HUB use different OSPF types.
• Because spokes are generally low-end devices, they probably can’t cope with LSA flooding generated within the OSPF domain. Therefore, it’s recommended to make areas Stubby (filter-in LSA5 from external areas) or totally stubby (neither LSA5 nor inter-area LSA3 are accepted)

Make sure appropriate MTU value matches between tunnel interfaces (“ip mtu 1400 / ip tcp mss-adjust 1360”)

Consider the OSPF scalability limitation (50 routers per area). OSPF requires much more tweekening for large scale deployments.

Layered approach:

DMVPN involves multiple layers of technologies (mGRE, routing, NHRP, IPSec), troubleshooting an issue can be very tricky.

To avoid cascading errors, test your configuration after each step and move forward only when the current step works fine. For example: IPSec encryption is not required to the functioning of DMVPN, so make sure your configuration works without it and only then you add it (set IPSEc parameters and just add “tunnel protection ipsec profile” to the tunnel interface).

Quiz

http://hpnouri.free.fr/dmvpn/dmvpn-quiz2.swf

Let’s 6rd!

6rd mechanism belongs to the same family as automatic 6to4, in which IPv6 traffic is encapsulated inside IPv4.

The key difference is that with 6rd, Service Providers use their own 6rd prefix and control the transition of their access-aggregation IPv4-only part of their networks to native IPv6. In the same time, SPs transparently provide IPv6 availability service to their customers.

6rd is generally referred as stateless transition mechanism.

Stateless In stateless mechanisms an algorithm is used to automatically map between addresses, the scope of mechanism is limited to a local domain in which devices, mapping device (6rd BR) and devices that need mapping (6rd CE), share a common elements of the configuration. Stateful On a gateway device, we need to specify a specific address or a range of addresses (not used elsewhere) that will represent another range of addresses. For example IPv4 NAT on Cisco (NAT44): ip nat source … The router relies on the configured statement which address (all bits) to translate to which address (all bits). Which is done independently of devices whose address needs to be translated (inside local/outside global). For redundancy we need additional configuration to synchronize connection state information between devices. for example SNAT(Stateful NAT failover).

Customer CE routers generate their own IPv6 from the delegated 6rd prefix from BRs (Border relays).

Both CEs and BRs encapsulate IPv6 traffic into IPv4 traffic by automatically reconstructing the header IPv4 addresses from IPv6.

• Lab topology
  

For end-to-end testing I am using Ubunu Server version for client host behind CE and Internet host.

Here, is a brief and I hope concise explanation of the main 6rd operations:

6rd configuration

6rd address planning depends on each SP. IPv4 bits must be unique to each CE to show the flexibility of the configuration, I fixed the first 16 bits (10.1) as prefix and the last octets (.1) as suffix and attributed the third octet to CEs.

6rd domain configured parameters:

Tunnel source interface	fa0/0
6rd prefix	2001:DEAD::/32
IPv4 prefix length	16
IPv4 bits	8
IPv4 suffix	8
Tunnel source interface IP	10.1.4.1

BR1

ipv6 general-prefix 6RD-PREFIX 6rd Tunnel0 ! interface Tunnel0 ipv6 address 6RD-PREFIX 2001:DEAD::/128 anycast ipv6 enable tunnel source FastEthernet0/0 tunnel mode ipv6ip 6rd tunnel 6rd ipv4 prefix-len 16 suffix-len 8 tunnel 6rd prefix 2001:DEAD::/32

interface FastEthernet0/0 ip address 10.1.4.1 255.255.0.0

We need a couple of static routes to make 6rd work in lab conditions; generally, BR announces client assigned IPv4 to clients to Internet.

• Default ipv4 static route to outside
• Static route to SP 6rd prefix pointing to the tunnel
• Default ipv6 static route to outside

ip route 0.0.0.0 0.0.0.0 192.168.20.100 ipv6 route 2001:DEAD::/32 Tunnel0 ipv6 route ::/0 2001:DB9:5AB::100

CE1

The same 6rd parameters are configured on CE:

• IPv4 affixes
• 6rd domain global prefix
• BR IPv4 address (remote tunnel end point)

interface Tunnel0 ipv6 enable tunnel source 10.1.1.1 tunnel mode ipv6ip 6rd tunnel 6rd ipv4 prefix-len 16 suffix-len 8 tunnel 6rd prefix 2001:DEAD::/32 tunnel 6rd br 10.1.4.1 ! interface FastEthernet0/0 ip address 10.1.1.1 255.255.0.0 ipv6 enable ! interface FastEthernet0/1 ip address 192.168.10.100 255.255.255.0 ipv6 address 6RD-PREFIX ::/64 eui-64 ! * <<<

* Note the CE WAN interface fa0/0 is only enabled for IPv6 to be attributed a link-local address.

Fa0/0 IPv4 address is generally assigned by IPv4 DHCP. If the ISP assigns private addresses, CGN NAT44 is needed at the BR to translate them into global IPv4.

6rd prefix is delegated not to CE fa0/0 WAN interface but CE inside LAN interface fa0/1.

This way the customer LAN can benefit directly from the globally IPv6 address without interrupting IPv6 address continuity and the same prefix can be assigned to client IPv6 network using SLAAC (stateless auto configuration).

A recursive (output interface + next-hop) IPv6 default route points to the BR tunnel interface.

ipv6 route ::/0 Tunnel0 2001:DEAD:400::1

Debugging 6rd tunnel

CE1

CE1#debug tunnel Tunnel Interface debugging is on CE1# Tunnel0: IPv6/IP adjacency fixup, 10.1.1.1->10.1.4.1, tos set to 0x0 Tunnel0: IPv6/IP (PS) to decaps 10.1.4.1->10.1.1.1 (tbl=0, “default”, len=124, ttl=254) Tunnel0: decapsulated IPv6/IP packet (len 124)

BR1

BR1#debug tunnel Tunnel Interface debugging is on BR1# Tunnel0: IPv6/IP to classify 10.1.1.1->10.1.4.1 (tbl=0,”default” len=124 ttl=254 tos=0x0) ok, oce_rc=0x0 Tunnel0: IPv6/IP adjacency fixup, 10.1.4.1->10.1.1.1, tos set to 0x0 BR1#

As shown by the debug, the end-to-end IPv6 traffic is encapsulated into IPv4 packets between CE and BR.

$iperf -u -t -i1 -V -c 2001:db9:5ab::10 -b 10K WARNING: delay too large, reducing from 1.2 to 1.0 seconds. ———————————————————— Client connecting to 2001:db9:5ab::100, UDP port 5001 Sending 1470 byte datagrams UDP buffer size: 112 KByte (default) ———————————————————— [ 3] local 2001:dead:100:0:a00:27ff:fe0f:20e9 port 39710 connected with 2001:db9:5ab::100 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 1.0 sec 1.44 KBytes 11.8 Kbits/sec [ 3] 1.0- 2.0 sec 1.44 KBytes 11.8 Kbits/sec [ 3] 2.0- 3.0 sec 4.00 GBytes 34.4 Gbits/sec [ 3] 3.0- 4.0 sec 1.44 KBytes 11.8 Kbits/sec [ 3] 4.0- 5.0 sec 1.44 KBytes 11.8 Kbits/sec [ 3] 5.0- 6.0 sec 4.00 GBytes 34.4 Gbits/sec [ 3] 6.0- 7.0 sec 1.44 KBytes 11.8 Kbits/sec [ 3] 7.0- 8.0 sec 4.00 GBytes 34.4 Gbits/sec [ 3] 8.0- 9.0 sec 1.44 KBytes 11.8 Kbits/sec [ 3] 9.0-10.0 sec 4.00 GBytes 34.4 Gbits/sec [ 3] 0.0-11.0 sec 16.0 GBytes 12.5 Gbits/sec [ 3] Sent 11 datagrams read failed: Connection refused [ 3] WARNING: did not receive ack of last datagram after 4 tries.

Following, is a wireshark traffic capture of the previous iperf testing

Verification commands

BR1:

BR1#sh tunnel 6rd tunnel 0 Interface Tunnel0: Tunnel Source: 10.1.4.1 6RD: Operational, V6 Prefix: 2001:DEAD::/32 V4 Prefix, Length: 16, Value: 10.1.0.0 V4 Suffix, Length: 8, Value: 0.0.0.1 General Prefix: 2001:DEAD:400::/40 BR1#

BR1#sh tunnel 6rd destination 2001:dead:100:: tunnel0 Interface: Tunnel0 6RD Prefix: 2001:DEAD:100:: Destination: 10.1.1.1 BR1#

BR1#sh tunnel 6rd prefix 10.1.1.1 tunnel 0 Interface: Tunnel0 Destination: 10.1.1.1 6RD Prefix: 2001:DEAD:100:: BR1#

CE1:

CE1#sh tunnel 6rd tunnel 0 Interface Tunnel0: Tunnel Source: 10.1.1.1 6RD: Operational, V6 Prefix: 2001:DEAD::/32 V4 Prefix, Length: 16, Value: 10.1.0.0 V4 Suffix, Length: 8, Value: 0.0.0.1 Border Relay address: 10.1.4.1 General Prefix: 2001:DEAD:100::/40 CE1#

CE1#sh tunnel 6rd destination 2001:dead:100:: tunnel0 Interface: Tunnel0 6RD Prefix: 2001:DEAD:100:: Destination: 10.1.1.1 CE1#

CE1#sh tunnel 6rd prefix 10.1.4.1 tunnel 0 Interface: Tunnel0 Destination: 10.1.4.1 6RD Prefix: 2001:DEAD:400:: CE1#

We can use “mtr” command to check the performance of the end-to-end (linux-to-linux) communication.

router@router1:~$ mtr 2001:db9:5ab::100 HOST: router1 Loss% Snt Last Avg Best Wrst StDev 1.|– 2001:dead:100:0:c801:3dff 0.0% 30 27.7 25.2 9.7 34.4 5.9 2.|– 2001:db9:5ab::1 0.0% 30 181.3 126.2 99.1 181.3 19.3 3.|– 2001:db9:5ab::100 0.0% 30 67.3 82.8 67.3 121.6 14.1 router@router1:~$

Customer internal network

6rd and MTU

The default MTU on IOS is 1480 bytes, so the maximum IPv4 packet size encapsulating IPv6 is 1500 bytes.

userver1 end-to-end MTU

router@router1:~$ tracepath6 2001:db9:5ab::100 1?: [LOCALHOST] 0.051ms pmtu 1500 1: 2001:dead:100:0:c801:3dff:fe5c:6 27.130ms 1: 2001:dead:100:0:c801:3dff:fe5c:6 57.536ms 2: 2001:dead:100:0:c801:3dff:fe5c:6 30.005ms pmtu 1480 2: 2001:db9:5ab::1 135.158ms 3: 2001:db9:5ab::100 79.603ms reached Resume: pmtu 1480 hops 3 back 253 router@router1:~$

Here is an animation explaining 6rd and fragmentation:

MTU recommendations

• Using a redundant BR, there is no guarantee that traffic will be handled by the same BR, so fragmented packets are lost between BRs è BR anycast IPv4 + IPv4 fragmentation is not recommended.
• Configure the same IPv4 MTU everywhere within the IPv4 segment and (DF=1) to disable fragmentation.
  • make sure the IPv4 MTU is coordinated with IPv6 MTU (IPv4 MTU < IPv6 MTU + 20 bytes)
• Enable PMTUD to choose the smallest MTU in the path of CE-to-BR communication.
• DO NOT Filter ICMP messages “Packet Too Big” and “Destination Unreachable” at routers and end-hosts, they provide inf. about transport issues, worse than traffic black hole is a silent traffic black hole.

Offline Lab

Finally, the offline lab with comprehensive command output during the lab:

IPv6 over AToM pseudowire

The purpose of this lab is to show the flexibility of Layer2 VPN technology AToM (Any Transport over MPLS), which allows service providers to smoothly transit the core network from legacy layer2 technologies into a single MPLS infrastructure ready for customer IPv6 transport.

Customer transition from IPv4 to dual stack is as easy as adding an IPv6 configuration to a point-to-point segment.

The lab is organized as follow:

• Lab topology overview
  
• MPLS Core
  
• Pseudowire circuit establishment over MPLS
  
• Customer configuration
  
• MTU
  
• Offline Lab
  
• Quiz
  
• Conclusion
  

Lab topology overview

Let’s consider the following lab topology: one core MPLS and three customers. Customer1 uses Ethernet port-to-port layer2 circuit to connect to Provider Edge access router, Customer2 uses Ethernet VLAN layer2 circuit and customer3 uses Frame Relay layer2 circuit.

Picture1: High-level Lab topology

Picture2: Low-level Lab topology

MPLS Core

The MPLS core is configured independently from any pseudowire configuration.

Picture3: MPLS core

In the core MPLS, there is practically nothing special to do. IGP and LDP configuration is straightforward. The goal is to guarantee core stability.

Make sure LDP router id is forced to a loopback interface.

Look here for the router’s main configuration:

http://hpnouri.free.fr/atom/atom-core.swf

Pseudowire circuit establishment over MPLS

Picture4: AToM Pseudowire establishment

The configuration to establish the different pseudowires do not depend on client configuration.

Note for each virtual circuit a directed LDP session is established between PEs connecting customer sites. Each PE uses a /32 loopback IP.

Layer2 Circuit	PE2	PE1
Port-to-port	interface FastEthernet0/0 no cdp enable xconnect 22.2.2.2 24 encapsulation mpls	interface FastEthernet0/0 no cdp enable xconnect 44.4.4.4 24 encapsulation mpls

Layer2 Circuit	PE2	PE1
Vlan	interface FastEthernet1/0 no cdp enable ! interface FastEthernet1/0.10 encapsulation dot1Q 10 xconnect 22.2.2.2 242 encapsulation mpls	interface FastEthernet1/0 no cdp enable ! interface FastEthernet1/0.10 encapsulation dot1Q 10 xconnect 44.4.4.4 242 encapsulation mpls

Layer2 Circuit	PE2	PE1
FR	connect fratom Serial2/0 501 l2transport xconnect 22.2.2.2 241 encapsulation mpls ! interface Serial2/0 encapsulation frame-relay frame-relay lmi-type cisco frame-relay intf-type dce	connect fratom Serial2/0 105 l2transport xconnect 44.4.4.4 241 encapsulation mpls ! interface Serial2/0 encapsulation frame-relay frame-relay lmi-type cisco frame-relay intf-type dce

Now, let’s take the east side as example of configuration between clients and the provider edge

Customer configuration

Picture5: Customer circuits

Note the provider edge is configured independently of the client layer3 protocol IPv4/IPv6.

Customer devices are configured in dual stack.

Ethernet port-to-port pseudowire

	East C1	PE1
IPv4	interface FastEthernet0/0 ip address 192.168.15.1 255.255.255.0 ip ospf 15 area 0	interface FastEthernet0/0 no cdp enable xconnect 44.4.4.4 24 encapsulation mpls
IPv6	interface FastEthernet0/0 ipv6 address FE80::15:5 link-local ipv6 address 2001:DB8:15::5/64 ipv6 ospf 15 area 0

Ethernet vlan pseudowire

	East C3		PE1
IPv4	interface Vlan10 ip address 192.168.152.1 255.255.255.0 ip ospf 15 area 0	interface FastEthernet1/0 switchport access vlan 10 switchport mode trunk	interface FastEthernet1/0 no cdp enable ! interface FastEthernet1/0.10 encapsulation dot1Q 10 xconnect 44.4.4.4 242 encapsulation mpls
IPv6	interface Vlan10 ipv6 address FE80::152:1 link-local ipv6 address 2001:DB8:152::1/64 ipv6 ospf 15 area 0

Use sub-interface on PE and disable CDP on the main interface.

FR pseudowire

	East C2	PE1
IPv4	interface Serial1/0 ip address 192.168.151.1 255.255.255.0 encapsulation frame-relay ip ospf network broadcast frame-relay interface-dlci 105	connect fratom Serial2/0 105 l2transport xconnect 44.4.4.4 241 encapsulation mpls ! interface Serial2/0 encapsulation frame-relay clock rate 2016000 frame-relay lmi-type cisco frame-relay intf-type dce
IPv6	interface Serial1/0 encapsulation frame-relay ipv6 address FE80::151:5 link-local ipv6 address 2001:DB8:151::5/64 ipv6 enable ipv6 ospf network broadcast ipv6 ospf 15 area 0 frame-relay map ipv6 FE80::151:1 105 frame-relay map ipv6 2001:DB8:151::1 105 broadcast

For the west side the client configuration is mirrored.

The offline lab provides a complete access to outcomes of large range of commands related to AToM.

The resulting virtual topology looks as follow, typical point-to-point circuits between client devices:

Picture6: Logical connections

MTU

Let’s analyse the path for each type of AToM:

• VC label (identify the pseudowire) = 4 bytes

• LDP Core switching label = 4 bytes

• AToM header for Ethernet = 4 bytes (empty)

• AToM header for Frame Relay = 4 bytes
• Ethernet port-to-port = 14 bytes
• Ethernet VLAN = 14 bytes (Ethernet port-to-port) + 4 bytes (VLAN tag) = 18 bytes
• Frame Relay encapsulation (Cisco) = 2 bytes.

Ethernet port-to-port AToM

Edge MTU	AToM header for Ethernet	Ethernet port-to-port	LDP Core switching label	VC label
1500	4 (empty)	14	4	4	1526 bytes

Ethernet VLAN AToM

Edge MTU	AToM header for Ethernet	Ethernet VLAN	LDP Core switching label	VC label
1500	4 (empty)	18	4	4	1530 bytes

FR AToM

Edge MTU	AToM header for FR	FR encapsulation	LDP Core switching label	VC label
1500	4	2	4	4	1514 bytes

Let’s set Max calculated MTU as Interface MTU of P/PE routers

On PE1 (Fa0/1), PE2 (FA0/1) and P (Fa0/0, Fa0/1)

(config-if)# mtu 1530

#sh int fa1/0 | i MTU MTU 1530 bytes, BW 100000 Kbit/sec, DLY 100 usec, #

MPLS MTU <= Core interfaces MTU

It is very important to distinguish IOS commands for setting MTU:

Hardware MTU

(config-if)# mtu <>: The maximum packet length the interface can support.

IP MTU

(config-if)# ip mtu <>: The maximum size of a non-labelled IP packet without fragmentation.

MPLS MTU

(config-if)# mpls mtu <>: The maximum size of a labelled IP packet without fragmentation (<= Hardware MTU).

Ivan Pepelnjak provides an excellent article about the difference between different MTU commands.

PE2#sh mpls int fa0/1 detail Interface FastEthernet0/1: IP labeling enabled (ldp): Interface config LSP Tunnel labeling not enabled BGP labeling not enabled MPLS operational MTU = 1500 PE2#

Testing end-to-end MTU

Note: Lab limitation

This lab was performed on GNS3 and I had some difficulties building MPLS core using C7200 platform with IOS 12.4(24) as P router. 3700 platform IOS doesn’t allow me to change Hardware MTU.

So the following test is done considering the maximum MTU through MPLS core of 1500 bytes.

The ping test is performed on a client site using EoMPLS VLAN to test the MTU limit

WestC3#ping Protocol [ip]: ipv6 Target IPv6 address: 2001:db8:52::1 Repeat count [5]: Datagram size [100]: 1400 Timeout in seconds [2]: Extended commands? [no]: yes Source address or interface: 2001:db8:12::1 UDP protocol? [no]: Verbose? [no]: Precedence [0]: DSCP [0]: Include hop by hop option? [no]: Include destination option? [no]: Sweep range of sizes? [no]: yes Sweep min size [1400]: Sweep max size [18024]: 1530 Sweep interval [1]: 4 Type escape sequence to abort. Sending 165, [1400..1530]-byte ICMP Echos to 2001:DB8:52::1, timeout is 2 seconds: Packet sent with a source address of 2001:DB8:12::1 !!!!!!!!!!!!!!!!C!. (size 1472) . (size 1476) . (size 1480) . (size 1484) . (size 1488) . (size 1492) . (size 1496) . (size 1500) . (size 1504) . (size 1508) . (size 1512) . (size 1516) . (size 1520) . (size 1524) . (size 1528) … <output omitted> Success rate is 53 percent (88/165), round-trip min/avg/max = 28/136/344 ms WestC3#

Note that ping fails starting from a packet size of 1472.

EoMPLS VLAN pseudowire adds 30 bytes to 1472 bytes which makes the packet bigger than 1500 bytes (lab max MTU limitation).

In fact, beyond the configured MTU on the core MPLS there is an implicit 18 bytes of the underlying Ethernet.

Following an illustrating hopefully clarifies the relationship between different MTUs:

Interactive illustration of Wireshark captured MPLS core transport packet

http://hpnouri.free.fr/atom/wireshark-atom-demo/wireshark-atom-demo.swf

Offline Lab

http://hpnouri.free.fr/atom/offlinelabv1.swf

Quiz

http://hpnouri.free.fr/atom/atom-quiz/atom-quiz.swf

Conclusion

• AToM pseudowires are configured independently of IPv4/IPv6, which makes the client transition from IPv4 to IPv6 transparent.
• From the client point of view it is a directly connected point-to-point circuit.
• Make sure MPLS core interfaces MTU are configured with the maximum packet size and the MPLS MTU is not bigger that interface hardware MTU to avoid unnecessary fragmentation.

6VPE (IPv6 VPN Provider Edge Router)

6VPE is an easy solution to connect IPv6 customers through an existing stable IPv4 MPLS infrastructure.

All clients have to do is to connect to a Provider Edge (configured with IPv6 VRFs) using IPv6.

I hope this post will provide you with a brief and concise explanation about 6VPE.

Let’s start with a short animation resuming the 6VPE forwarding process:

Following the main configuration steps.

Lab topology

Core IGP

For the sake of backbone stability, we need to configure the Core IGP (OSPF) to use loopback interfaces (always UP/UP) on all P and PE routers. {2.2.2.2, 3.3.3.3, 4.4.4.4}

22.2.2.2, 33.3.3.3, 44.4.4.4 loopback interfaces are used for MPLS router-id and need to be advertised through Core OSPF.

22.22.2.2, 44.4.4.4 loopback interfaces are used for MP-iBGP neighbor relationships and need to be advertised through Core OSPF.

By default OSPF will not advertise a 32-bit loopback mask. We need to configure the interface to be an OSPF network type point-to-point. For more details refer to this post…

6VPE2

interface Loopback0 ip address 4.4.4.4 255.255.255.255 ! ! interface Loopback2 ip address 44.4.4.4 255.255.255.0 ! ! interface Loopback3 ip address 44.44.4.4 255.255.255.255 ip ospf network point-to-point ! router ospf 234 router-id 4.4.4.4 network 44.4.4.4 0.0.0.0 area 0 network 44.44.4.4 0.0.0.0 area 0 network 192.0.0.0 0.255.255.255 area 0

Core

interface Loopback0 ip address 3.3.3.3 255.255.255.255 ! router ospf 234 router-id 3.3.3.3 network 33.3.3.3 0.0.0.0 area 0 network 192.0.0.0 0.255.255.255 area 0

6VPE1

interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! ! interface Loopback2 ip address 22.2.2.2 255.255.255.255 ! ! interface Loopback3 ip address 22.22.2.2 255.255.255.255 ip ospf network point-to-point ! mpls ldp router-id Loopback2 force ! router ospf 234 router-id 2.2.2.2 network 22.2.2.2 0.0.0.0 area 0 network 22.22.2.2 0.0.0.0 area 0 network 192.0.0.0 0.255.255.255 area 0

MPLS-LDP

MPLS-LDP establishes back-to-back sessions for label exchange in the control plane and label swapping in the forwarding plane.

Just configure MPLS LDP the appropriate interfaces and force a loopback interface for MPLS LDP router-id.

Core

interface FastEthernet0/0 ip address 192.168.23.3 255.255.255.0 mpls label protocol ldp mpls ip ! interface FastEthernet0/1 ip address 192.168.34.3 255.255.255.0 mpls label protocol ldp mpls ip ! mpls ldp router-id Loopback2 force

6VPE1

interface FastEthernet1/0 ip address 192.168.23.2 255.255.255.0 mpls label protocol ldp mpls ip ! mpls ldp router-id Loopback2 force

6VPE2

interface FastEthernet1/0 ip address 192.168.34.4 255.255.255.0 mpls label protocol ldp mpls ip ! mpls ldp router-id Loopback2 force

Provider Edge VRFs

Make sure IPv6 routing and IPv6 CEF are enabled.

6VPE1

vrf definition west-c1 rd 100:100 ! address-family ipv6 route-target export 100:100 route-target import 100:100 exit-address-family

interface FastEthernet0/0 vrf forwarding west-c1 ipv6 address FE80::12:2 link-local ipv6 address 2001:DB8:12::2/64

router bgp 65234 no synchronization bgp router-id 22.2.2.2 bgp log-neighbor-changes ! address-family ipv6 vrf west-c1 redistribute connected no synchronization neighbor 2001:DB8:12::1 remote-as 65010 neighbor 2001:DB8:12::1 activate exit-address-family

West6

router bgp 65010 bgp router-id 1.1.1.1 bgp log-neighbor-changes neighbor 2001:DB8:12::2 remote-as 65234 ! address-family ipv6 neighbor 2001:DB8:12::2 activate network 2001:DB8:10::/64 network 2001:DB8:12::/64 exit-address-family

6VPE2

vrf definition east-c1 rd 100:100 ! address-family ipv6 route-target export 100:100 route-target import 100:100 exit-address-family

interface FastEthernet0/0 vrf forwarding east-c1 ipv6 address FE80::45:4 link-local ipv6 address 2001:DB8:45::4/64

router bgp 65234 no synchronization bgp router-id 44.4.4.4 bgp log-neighbor-changes ! address-family ipv6 vrf east-c1 redistribute connected no synchronization neighbor 2001:DB8:45::5 remote-as 65050 neighbor 2001:DB8:45::5 activate exit-address-family

Note: With BGP used as customer protocol redistribution is not needed between PE-CE routing protocol (BGP) and MP-BGP

East6

router bgp 65050 bgp router-id 5.5.5.5 bgp log-neighbor-changes neighbor 2001:DB8:45::4 remote-as 65234 ! address-family ipv6 neighbor 2001:DB8:45::4 activate network 2001:DB8:45::/64 network 2001:DB8:50::/64 exit-address-family

Provider Edge-to-Provider Edge VPNv6

To understand the difference between PE-PE and PE-CE interactions, think about the difference between a routing protocol and a routed protocol:

• BGP, OSPF, EIGRP, RIP are routing protocols.
• IPv4, IPv6, IPX, AppleTalk are routed protocol.

So routing protocols exchange routed protocol information. In our particular case:

• PE-CE routing protocol is BGP and PE-CE routed protocol is IPv6.
• PE-PE routing protocol is MP-BGP and PE-PE routed protocol is vpnv6.
• Core routing protocol is OSPF and the routed protocol is IPv4.

Vpnv4 = RD + VRF IPv4 prefix

Vpnv6 = RD + VRF IPv6 prefix

RD (Route Distinguisher) uniquely identifies the VRF on the PE and allows having multiple customer VPNs with overlapping address schemas.

RT is a BGP extended community attribute (need to be enabled) used to control the installation of exchanged routes between PEs into the correct VRF.

PE-PE (MP-BGP) updates containing MP_BGP_NLRI information:

vpnv4 + (BGP attributes+ RT extended attribute) + Label

VPNv6 route exchange (using MP-BGP)

MPLS network autonomous system 65234 transits traffic between customer autonomous systems 65010 and 65040.

In our case all MPLS routers (P and PE) belong to the same AS. Therefore we need to configure next-hop-self on each PE; otherwise customer prefixes will be visible in BGP table with unreachable next-hops.

Another solution is to enable MPLS IP on interfaces facing clients to include them in MPLS updates, then don’t forget to filter LDP(UDP 646),TDP(TCP 711) traffic with the clients .

6VPE1

router bgp 65234 no synchronization bgp router-id 22.2.2.2 neighbor 44.44.4.4 remote-as 65234 neighbor 44.44.4.4 update-source Loopback3 neighbor 44.44.4.4 next-hop-self no auto-summary

The address-family vpnv4 is used to exchange customer IPv4 prefixes between PEs (through IPv4 core)

The address-family vpnv6 is used to exchange customer IPv6 prefixes between PEs (through IPv4 core)

router bgp 65234 address-family vpnv4 neighbor 44.44.4.4 activate neighbor 44.44.4.4 send-community extended exit-address-family ! address-family vpnv6 neighbor 44.44.4.4 activate neighbor 44.44.4.4 send-community extended exit-address-family

6VPE2

router bgp 65234 no synchronization bgp router-id 44.4.4.4 neighbor 22.22.2.2 remote-as 65234 neighbor 22.22.2.2 update-source Loopback3 neighbor 22.22.2.2 next-hop-self no auto-summary

router bgp 65234 address-family vpnv4 neighbor 22.22.2.2 activate neighbor 22.22.2.2 send-community extended exit-address-family ! address-family vpnv6 neighbor 22.22.2.2 activate neighbor 22.22.2.2 send-community extended exit-address-family

And a small QUIZ to check the very basic

The offline lab provides you with more information about the network behavior and its states in different test cases.

An extensive range of commands is provided.

I hope you will find it useful. Suggestions and critics are welcome.

IPv6 BGP synchronization

If you have been dealing with BGP under IOS < 12.0, you know something about BGP synchronization.

This post is driven by three reasons…nostalgia is not one of them : )

1. BGP synchronization illustrates the difference of BGP with the traditional concept of interior routing protocols like OSPF, RIP or EIGRP.
2. With ever-growing transition to IPv6, I wanted to test the concept of synchronization with IPv6.
3. You need to work out your brain muscles and be ready to deal with anything in the CCIE exam where your problem-solving skills will be tested more than your knowledge of best practices.

So let’s brush up our knowledge of the concept with a brief definition of BGP:

BGP is used to advertise NLRI (Network Layer reachability information) between ASs (Autonomous Systems) and it relies on TCP (179) for reliability of the communications. BGP is an attribute-based path-vector protocol.

BGP synchronization states that, if your autonomous system passes traffic from another AS to a third AS (transit), eBGP speaker should not advertise a route before all the routers in your AS have learned about the NLRI via IGP. So BGP will wait until IGP has propagated the route within the AS.

If not done properly, the transit AS will turn into a route black hole.

Here is a small animation illustrating the concept:

Animation

The solution is mutual redistribution of routes between BGP and the IGP.

Nowadays, BGP is running on all routers in autonomous system transit paths, so synchronization is disabled by default.

This allows you to carry fewer routes in your IGP and allow BGP to converge more quickly.

IPv6 configuration

Topology

Router R1:

Redistribution from OSPF TO BGP

router bgp 65012
address-family ipv6 unicast

 redistribute ospf 125

!

route-map RM6_OSPF_TO_BGP match external 2

route-map RM6_OSPF_TO_BGP
 permit 10 match ipv6 address ACL6_OSPF_TO_BGP 
!
ipv6 access-list ACL6_OSPF_TO_BGP 
 permit ipv6 2001:db8:209::/64 any log 
 permit ipv6 2001:db8:23::/64 any log

Redistribution from BGP to OSPF

route-map RM6_BGP_TO_OSPF permit 10
match ip address ACL6_BGP_TO_OSPF
!
ip access-list standard ACL6_BGP_TO_OSPF
permit ipv6 2001:db8:14::/64 any log
!
ipv6 router ospf 125

redistribute bgp 65012 subnets route-map RM6_BGP_TO_OSPF

Redistribution from BGP to OSPF

R1# sh ipv6 route
IPv6 Routing Table - 8 entries
…
C   2001:DB8:14::/64 [0/0]
via ::, FastEthernet0/1
L   2001:DB8:14::1/128 [0/0]
via ::, FastEthernet0/1
C   2001:DB8:15::/64 [0/0]
via ::, FastEthernet0/0
L   2001:DB8:15::1/128 [0/0]
via ::, FastEthernet0/0
O   2001:DB8:25::/64 [110/20]
via FE80::15:5, FastEthernet0/0
B   2001:DB8:40::/64 [20/0]
via FE80::14:4, FastEthernet0/1

OE2 2001:DB8:209::/64 [110/1] via FE80::15:5, FastEthernet0/0

L FF00::/8 [0/0] via ::, Null0 
R1#

R2:

Redistribution from BGP to OSPF

route-map RM6_BGP_TO_OSPF permit 10
match ipv6 address ACL6_BGP_TO_OSPF
!
ipv6 access-list  ACL6_BGP_TO_OSPF
permit 2001:db8:209::/64 any log
permit 2001:db8:23::/64 any log
!
ipv6 router ospf 125

redistribute bgp 65012 route-map RM6_BGP_TO_OSPF

Redistribution from OSPF to BGP

router bgp 65012
address-family ipv6 unicast

redistribute ospf 125 route-map RM6_OSPF_TO_BGP match external 2

route-map RM6_OSPF_TO_BGP permit 10

match ipv6 address ACL6_OSPF_TO_BGP 

!

ipv6 access-list ACL6_OSPF_TO_BGP permit 2001:db8:14::/64 any log

The presence of prefix 2001:DB8:40::/64 originated in AS 65040 (iBGP administrative distance = 200) in the IGP table (OSPFv3 administrative distance =110) means that the core IGP has synchronized the prefix.

R2#sh bgp ipv6 unicast  2001:DB8:40::/64
BGP routing table entry for 2001:DB8:40::/64, version 4
Paths: (2 available, best #1, table Global-IPv6-Table)
Advertised to update-groups:
1    2
Local
:: from 0.0.0.0 (2.2.2.23)
Origin incomplete, metric 1, localpref 100, weight 32768, valid, sourced, best
65040
2001:DB8:15::1 (metric 20) from 2001:DB8:15::1 (1.1.1.14)
Origin IGP, metric 0, localpref 100, valid, internal,

synchronized

R2#



R2# sh ipv6 route
IPv6 Routing Table - 8 entries
…
O   2001:DB8:15::/64 [110/20]
via FE80::25:5, FastEthernet0/0
C   2001:DB8:23::/64 [0/0]
via ::, FastEthernet0/1
L   2001:DB8:23::2/128 [0/0]
via ::, FastEthernet0/1
C   2001:DB8:25::/64 [0/0]
via ::, FastEthernet0/0
L   2001:DB8:25::2/128 [0/0]
via ::, FastEthernet0/0

OE2 2001:DB8:40::/64 [110/1]

via FE80::25:5, FastEthernet0/0

B 2001:DB8:209::/64 [20/0]

via FE80::23:3, FastEthernet0/1

L FF00::/8 [0/0]

via ::, Null0

R2#

 

From R5 core IGP router you can notice that OSPFv3 is synchronized with transit route prefixes from AS 64030 and AS 64040.

R5:

R5#sh ipv6 route
IPv6 Routing Table - 7 entries
…
C   2001:DB8:15::/64 [0/0]
via ::, FastEthernet0/0
L   2001:DB8:15::5/128 [0/0]
via ::, FastEthernet0/0
C   2001:DB8:25::/64 [0/0]
via ::, FastEthernet0/1
L   2001:DB8:25::5/128 [0/0]
via ::, FastEthernet0/1

OE2 2001:DB8:40::/64 [110/1] via FE80::15:1, FastEthernet0/0 OE2 2001:DB8:209::/64 [110/1] via FE80::25:2, FastEthernet0/1

L FF00::/8 [0/0] via ::, Null0 
R5#

Offline lab

With the offline lab you will have an idea about the network behavior its states in different test cases.

An extensive range of commands is provided. Both IPv6 and IPv4 BGP synchronization are configured in the offline lab.

I hope you will find it useful. Suggestions and critics are welcome.