CiscoLive 2020 Barcelona - Advanced IPv6 Routing and Services Lab

IPv6 Routing and Services
Lab
Harold Ritter, Sr. Technical Leader
@ccie4168
Faraz Shamim, Solutions Architect
@ccie4131
LABSPG-3122
Cisco Webex Teams
Questions?
Use Cisco Webex Teams to chat
with the speaker after the session
How
1 Find this session in the Cisco Events Mobile App
2 Click “Join the Discussion”
3 Install Webex Teams or go directly to the team space
4 Enter messages/questions in the team space
LABSPG-3122 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
Tuesday
Opening Keynote 09:00
LTRIPV-2494 Wednesday
Thursday
Lab: IPv6 adoption in 09:00 LABSPG-3122 9:00
next-gen SP networks Lab: Advanced IPv6 Routing
and services lab
BRKIP6-2191 Tuesday BRKRST-2619 Wednesday BRKSEC-3200 Friday

The Protocol 11:00 IPv6 Deployment: 11:00 Advanced IPv6 Security Threats and 11:30
Developing an IPv6 Mitigation
addressing Plan and
Deploying Ipv6
LABSPG-3122 BRKRST-3304
Lab: Advanced IPv6
Tuesday
14:30
BRKIP6-2223 Thursday Friday
IPv6 for the World of IOT 14:45 Hitchhiker guide to 11:30
Routing and services Troubleshooting
lab Thursday
Guest Keynote 17:00
Cisco Live
IPv6
Thursday
Celebration 18:30
IPv6 IPv6 Track

#CLEMEA www.ciscolive.com/emea/learn/technology-tracks.html
Session Abstract
• This hands on Advanced IPv6 lab goes into the details of IPv6 Routing and Services
covering link state protocols(OSPFv3 & ISISv6) and Exterior gateway protocol(BGPv6)
in depth and MPLS features such as 6PE & 6VPE and IPv6 basic multicast. Students will
be provided a scenario with IPv4 addressing & routing preconfigured where they will
find lots of opportunities to study and analyze the differences between IPv4 and IPv6
routing side by side. Students will also learn different methods of configuring
BGP peering using link local, global as well as IPv6 in IPv4 peering and IPv4 in IPv6
peering & BGP route reflector model in IPv6. The lab also provide interesting scenarios
with MPLS 6PE as well as MPLS 6VPE in dual stack environment. There is also an IPv6
multicast lab at the end with basic IPv6 multicast with static and embedded RP. All the
labs will be independent of each other giving students an opportunity to pick and
choose among these 6 labs and spend more time on one technology or do all the labs
• Prerequisites
• Students MUST have a basic understanding of IPv6 Addressing, MPLS and Routing
Protocols.
• Familiarity with Cisco IOS.
Agenda
• OSPFv3 Lab
• ISISv6 Lab
• BGPv6 Lab
• 6PE Lab
• 6VPE Lab
• IPv6 Multicast Lab
Lab info
• This is an advanced level lab that will NOT test you on basic features of IPv6 such as address
configuration or Neighbor Discovery
• Each lab can be done on its own in any order
• IPv4 addressing & routing is pre-established. Use it for comparison between IPv4 and IPv6
• Each lab has a clear topology diagram with addressing details
• All IPv6 addresses are pre-assigned.
• The IPv6 addressing must not be changed unless otherwise mentioned in the lab
• Lab keys are given at the end of each lab
Topology
OSPFv3 Lab
OSPFv3 Lab Agenda
• Redistribution in OSPFv3
• OSPFv2 & OSPFv3 RID
• Explore LSA differences between OSPFv2 and OSPFv3
• Virtual links in OSPFv3 compare to OSPFv2
• The new concept of Instance ID
• Summarization in OSPFv3 (Inter-area and External) vs
OSPFv2
• Routing over Link local address
OSPFv3 Lab Topology
OSPFv3 Instructions
• Configure OSPFv3 as follows:
• R1-R4 in area 1, change it to totally stubby NSSA area

• R1-R2 in area 0
• R2-R3 in area 4
• R3-R5 in area 2
• IPv6 static routes on R4 are predefined
• Virtual link is already configured in OSPFv2
OSPFv3 Lab: Redistribution
• Redistribute static IPv6 routes into OSPFv3 on R4

• What is the redistribution difference compared to OSPFv2?
R# OSPFv2 OSPFv3
R4 router ospf 1 ipv6 router ospf 1
redistribute static subnets redistribute static

R4 sh ip ospf data nssa | i sh ipv6 ospf data nssa | i
Forward Forward
Forward Address: 10.0.0.2
Forward Address: 10.0.0.2
OSPFv3 Lab: Redistribution (Answers)
• OSPFv3 redistribution does not require subnet keyword while redistributing routes
• Forwarding address are optional in OSPFv3
• All other characteristics of externals are same as in OSPFv2
OSPFv3 Lab: Router ID
• Check the OSPFv2 & v3 RID for R4
• Why OSPFv3 RID is same ID as OSPFv2?
• Change OSPFv3 RID to 0.0.0.4
R# OSPFv2 OSPFv3
R4 sh ip ospf | incl ID sh ipv6 ospf | incl ID
Routing Process "ospf 1" with ID Routing Process "ospfv3 1" with ID 10.1.1.4
10.1.1.4
config term
ipv6 router ospf 1
router-id 0.0.0.4
clear ipv6 ospf process
sh ipv6 ospf | i ID
Routing Process "ospfv3 1" with ID 0.0.0.4
OSPFv3 Lab: Router ID (Answers)
• OSPFv3 picks up RID using the exact algorithm used by OSPFv2
• It’s a 32 bit number in dotted decimal format
• Has nothing to do with IPv4 addressing
• That’s why you can change the RID to any 32 bits dotted decimal
• Some example are 0.0.0.1 or 0.255.1.0 which are clearly not a valid IPv4 addresses
• 0.0.0.0 is reserved and can not be used as RID
OSPFv3 Lab: LSA Differences
• Compare OSPFv2 & OSPFv3 LSAs
• What are the major differences?
R# LSA OSPFv2 OSPFv3

R1 Router sh ip ospf data router <RID of R1> sh ipv6 ospf data router self
R1 Network sh ip ospf data network <DR IP sh ipv6 ospf data netw self
add>
R1 Summary/inter- sh ip ospf data summary 10.1.1.0 sh ipv6 ospf data inter-area prefix 2001:db8:1:1::/64
area
R1 NSSA sh ip ospf data nssa 10.1.4.4 sh ipv6 ospf data nssa 2001:db8:1:4::4/64
R1 External sh ip ospf data ext 10.1.4.4 sh ipv6 ospf data ext 2001:db8:1:4::4/127
R3 SummaryASBR sh ip ospf data asbr 10.1.0.1 sh ipv6 ospf data inter-area router 10.1.0.1
R3 Link LSA sh ipv6 ospf data link self
R4 inter-area router sh ipv6 ospf data prefix
OSPFv3 Lab: LSA Differences (Answers)
• OSPFv3 has almost similar type of LSA’s as OSPFv2
• Two new LSA’s has been introduced (Link & prefix)
• Summary LSA is now called “Inter-area network”
• Summary ASBR is now called “inter-area router”
• Router LSA in OSPFv3 are no longer identified by LS ID
• Network LSA are no longer identified by LSID
• Forwarding Address field are optional in External LSAs
OSPFv3 Lab: Virtual Link
• Configure a virtual link between R2 & R3

• How the virtual link is formed in OSPFv3?
R# OSPFv2 OSPFv3
R2 area 4 virtual-link 10.1.3.1 area 4 virtual-link 10.1.3.1
R2 sh ip ospf virtual | i Virtual sh ipv6 ospf virtual | i Virtual
Virtual Link OSPF_VL0 to Virtual Link OSPFv3_VL0 to
router 10.1.3.1 is up router 10.1.3.1 is up
R3 area 4 virtual-link 10.1.0.0 area 4 virtual-link 10.1.0.0
R3 sh ip ospf virtual | i Virtual sh ipv6 ospf virtual | i Virtual
Virtual Link OSPF_VL1 to Virtual Link OSPFv3_VL0 to
router 10.1.0.0 is up router 10.1.0.0 is up
OSPFv3 Lab: Virtual Link (Answers)
• OSPFv3 has the exact same way of configuring a virtual link
• The router ID does not have to be known in the routing table
• At least one Global or Unique local address must be present in the transit area
• As soon as a virtual link is configured, the router advertises a /128 with LA bit set.
• That’s how the end point of virtual links are found and hellos are sent to form virtual
adjacencies over the virtual links
OSPFv3 Lab: Instance ID
• Configure an instance ID of 1 on R1 S1/0 interface
• Why R1 adjacency went down after the instance ID is changed to 1 on S1/0 interface?
• Change the instance ID of R2 S1/0 interface to 1
R# OSPFv3
R1 interface S1/0
ipv6 ospf 1 area 0 instance 1
%OSPFv3-5-ADJCHG: Process 1, Nbr 10.1.0.0 on Serial1/0 from FULL to DOWN,
Neighbor Down: Dead timer expired
R2 interface S1/0
%OSPFv3-5-ADJCHG: Process 1, Nbr 10.1.0.1 on Serial1/0 from LOADING to FULL,
Loading Done
OSPFv3 Lab: Instance ID (Answers)
• Instance ID is a new field introduced in OSPFv3 packet
• Instance ID has to be the same across a link otherwise adjacency won’t be formed
• Instance ID can be used as a protection against forming unnecessary adjacency over a link
• An interface can be included in more than 1 OSPFv3 area through instance ID
OSPFv3 Lab: Summarization
• Summarize area 0 routes in area 2

• Summarize OSPFv3 external routes coming out of R1
• What is the difference between OSPFv2 and OSPFv3 when summarizing?
R# 23 OSPFv3
R1 sh run | i summary-address sh run | i summary-prefix
summary-address 10.1.4.4 summary-prefix 2001:DB8:1:4::4/127

255.255.255.254
R3 sh run | i range sh run | i range
area 0 range 10.1.0.0 255.255.255.252 area 0 range 2001:DB8:1::/126
OSPFv3 Lab: Summarization (Answers)
• Just like OSPFv2, routes can be summarized in OSPFv3
• OSPFv3 has inter-area prefix summarization which was known as area range summarization
in OSPFv2
• OSPFv3 also has external route summarization
• Instead of subnet mask, OSPFv3 summarization can be done using prefix mask notation in
the form of /<prefix length>
• Summarization is still a great tool to minimize the size of the routing table
OSPFv3 Lab: Link Local Routing
• Enable IPv6 link local address on R4 E0/0.
• Remove IPv6 global address on R4 E0/0.
• Did the neighbor go down on E0/0? Why not?
• Now remove IPv6 global address on R1 also.
• Did the neighbor go down on E0/0? Why not?
Router OSPFv3
R4 interface e0/0
ipv6 enable
no ipv6 address
R1 interface e0/0
ipv6 enable
no ipv6 address
OSPFv3 Lab: Link Local Routing
• OSPFv3 sends its hellos over link local address
• Whether the global address is present on a link or not, OSPFv3 does not care when forming
adjacency over that link
• Entire network can be configured with Link Local address (RFC7404)
• It will still provide end to end connectivity through hop by hop routing
• For Trace route to work, at least one IPv6 address is required on a router
• In multipath scenario, it would be difficult to tell which interface a packet was traversed
OSPFv3 Lab Key
OSPFv3 Lab: Configs
R# Configs
ipv6 unicast-routing router ospf 1
R1 ! area 1 nssa no-summary
interface Loopback0 summary-address 10.1.4.4 255.255.255.254
ip address 10.1.0.1 255.255.255.255 !
ip ospf 1 area 0 ipv6 router ospf 1
ipv6 address 2001:DB8:1::1/128 area 1 nssa no-summary
ipv6 ospf 1 area 0 summary-prefix 2001:DB8:1:4::4/127
!
interface Ethernet0/0
ip address 10.1.1.1 255.255.255.0
ip ospf 1 area 1
ipv6 address 2001:DB8:1:1::1/64
ipv6 ospf 1 area 1
!
interface Serial1/0
ip address 10.1.0.3 255.255.255.254
ip ospf 1 area 0
ipv6 address 2001:DB8:1::3/127
!
OSPFv3 Lab: Configs
R# Configs
R2 ipv6 unicast-routing
!
interface Loopback0
ip address 10.1.0.0 255.255.255.255
ip ospf 1 area 0
ipv6 address 2001:DB8:1::/128
ipv6 ospf 1 area 0
!
ip address 10.1.0.4 255.255.255.254
ip ospf 1 area 4
ipv6 ospf 1 area 4
!
interface Serial1/0
ip address 10.1.0.2 255.255.255.254
ip ospf 1 area 0
!
router ospf 1
area 4 virtual-link 10.1.3.1
!
ipv6 router ospf 1
area 4 virtual-link 10.1.3.1
OSPFv3 Lab: Configs
R# Configs
ipv6 unicast-routing router ospf 1
R3 ! area 0 range 10.1.0.0 255.255.255.252
interface Loopback0 area 4 virtual-link 10.1.0.0
ip address 10.1.3.1 255.255.255.255 !
ip ospf 1 area 2 ipv6 router ospf 1
ipv6 address 2001:DB8:1:3::3/128 area 0 range 2001:DB8:1::/126
ipv6 ospf 1 area 2 area 4 virtual-link 10.1.0.0
!
ip address 10.1.2.3 255.255.255.0
ip ospf authentication message-digest
ip ospf authentication-key cisco
ip ospf 1 area 2
ipv6 address 2001:DB8:1:2::3/64
ipv6 ospf 1 area 2
!
ip address 10.1.0.5 255.255.255.254
ip ospf 1 area 4
ipv6 ospf 1 area 4
!
OSPFv3 Lab: Configs
R# Configs
ipv6 unicast-routing ip route 10.1.4.4 255.255.255.255 10.0.0.2
R4 ! ip route 10.1.4.5 255.255.255.255 10.0.0.2
interface Ethernet0/0 !
ip address 10.1.1.4 255.255.255.0 ipv6 route 2001:DB8:1:4::4/128 2001:DB8::2
ip ospf 1 area 1 ipv6 route 2001:DB8:1:4::5/128 2001:DB8::2
ipv6 address 2001:DB8:1:1::4/64 !
ipv6 ospf 1 area 1 ipv6 router ospf 1
! router-id 0.0.0.4
interface Ethernet1/0 area 1 nssa
ip address 10.0.0.1 255.255.255.0 redistribute static
ip ospf 1 area 1
ipv6 address 2001:DB8::/64 eui-64
ipv6 ospf 1 area 1
!
router ospf 1
area 1 nssa
redistribute static subnets
!
OSPFv3 Lab: Configs
R# Configs
!
ip address 10.1.2.5 255.255.255.0
ip ospf authentication message-digest
ip ospf authentication-key cisco
ip ospf 1 area 2
ipv6 address 2001:DB8:1:2::5/64
ipv6 ospf 1 area 2
!
router ospf 1
!
ipv6 router ospf 1
ISISv6 Lab
ISISv6 Lab Agenda
• Single Topology ISIS

• Redistribution in ISISv6 vs ISISv4
• Summarization in ISISv6
• ISISv6 over tunnels
• Multi Topology ISIS
ISISv6 Lab Topology
ISISv6 Instructions
• ISISv4 is preconfigured in area 49.0001 & 49.0002
• Level 2 routing already established between R1 and R2 for IPv4
• Static routes are pre-configured on R4 for both IPv4 and IPv6 for comparison purpose
• Static routes for IPv4 are already redistributed into ISISv4
ISISv6 Lab: Single Topology ISIS
• Configure single topology ISIS in area 49.0001.
• What are the restrictions of Single topology ISIS?
R# ISISv4 ISISv6
R1/R4 interface e0/0 interface e0/0
ip router isis ipv6 router isis
R4 interface e1/0 interface e1/0
R1 interface s1/0 interface s1/0
router isis
net 49.0001.0000.0000.00001.00
passive-interface lo0
R4 sh clns neighbors sh clns neighbors
System Id Interface SNPA State Holdtime Type Protocol
R1 Et0/0 aabb.cc00.5100 Up 29 L1 IS-IS
ISISv6 Lab: Single topology ISIS (Answers)
• Single topology rules says: all interfaces of all routers within an ISIS Level that are enabled for
IPv4 ISIS, must also be configured with IPv6 ISIS
• Single topology has single SPF for both IPv4 and IPv6
• Due to these restrictions all routers in an ISIS Level must belong to both address-families
ISISv6 Lab: Redistribution
• Redistribute static IPv6 routes into ISISv6 on R4

• What is the redistribution difference between ISISv4 and ISISv6?
R# ISISv4 ISISv6
R4 router isis router isis
redistribute static ip level-1 address-family ipv6
redistribute static level-1
R1 R1#sh isis database R4.00-00 verbose ip | i 10.1.4.4 R1#sh isis database R4.00-00 verbose ipv6 | i
2001:DB8:1:4::4
Metric: 0 IP-External 10.1.4.4 255.255.255.255 Metric: 0 IPv6 2001:DB8:1:4::4/128
R1 R1#sh ip route | i 10.1.4.5 R1#sh ipv6 route | i 2001:DB8:1:4::5
i L1 10.1.4.5/32 [115/10] via 10.1.1.4, 00:41:07, I1 2001:DB8:1:4::5/128 [115/10]

Ethernet0/0
ISISv6 Lab: Redistribution (Answers)
• To redistribute a route in ISISv6, you have to go under address-family ipv6
• The keyword ip is only needed in ISISv4. In ISISv6, since the command is available under
address-family ipv6, no keyword is needed
• In ISISv4, TLV 128 is for Internal IP prefixes and TLV 130 is for External prefixes
• In ISISv6, TLV 236 represents both Internal and external prefixes
• External prefixes are marked by setting an X bit in TLV 236
ISISv6 Lab: Summarization
• Enable ISISv6 over S1/0 of R2
• Summarize external ipv6 routes on R1 towards L2 area
• What is the summarization difference between ISISv4 & v6?
R# ISISv4 ISISv6
R2 Int s1/0
ipv6 router isis
R1 router isis router isis
R1 summary-address 10.1.4.4 255.255.255.254 Address-family ipv6
summary-prefix 2001:DB8:1:4::4/127
R2 sh ip route isis | i 10.1.4.4 sh ipv6 route isis | i 2001:DB8:1:4::4
i L2 10.1.4.4/31 [115/20] via 10.1.0.3, I2 2001:DB8:1:4::4/127 [115/20]
00:01:32, Serial1/0
ISISv6 Lab: Summarization (Answers)
• All IPv6 prefix summarization needs to be done under address-family ipv6
• Summary-address has been changed to summary-prefix
• Route to null 0 is also installed on the router performing summarization just like in ISISv4
ISISv6 Lab: ISISv6 over tunnels
• Due to L2 limitation, IPv6 can not be enabled between R2 and R5
• Configure IPv6 over IPv4 tunnel between R2 and R5
• Assign IPv6 address over this tunnel as shown in the topology
R# ISISv6
R2 interface tunnel0
tunnel source s2/0
tunnel destination 10.1.0.7
tunnel mode ipv6ip
ipv6 address 2001:db8:1::6/127
R5 interface tunnel0
tunnel source s1/0
tunnel mode ipv6ip
ipv6 address 2001:db8:1::7/127
• Enable ISISv6 over tunnel0

• Is it forming ISISv6 adjacency over the tunnel? Why?
R# ISISv6
R2 int tun 0
ipv6 router isis
sh isis neighbor | incl Tu0
R5 int tun 0
ipv6 router isis
sh isis neighbor | incl Tu0
• Change the tunnel mode to GRE, is the neighbor formed now? Why?
R# ISISv6
R2 Interace tun0
Tunnel mode gre ip
sh isis neighbor | I Tu0
R2 L1 Tu0 UP 29 02
R5 İnterface tun0
Tunnel mode gre ip
sh isis neighbor | I Tu0
R5 L1 Tu0 UP 27 01
ISISv6 Lab: ISISv6 over tunnels (Answers)
• ISISv6 can not run on ipv6 over ip tunnel
• There is no direct encapsulation method for encapsulating CLNS within IPv6 header
• The only tunnel method that is supported for ISISv6 is GRE tunnel
• Any tunnel method that use direct encapsulation of IPv6 in IP with protocol 41 won’t support
ISISv6
• For example IPv6IP, ISATAP, 6to4, 6rd etc
ISISv6 Lab: Multi Topology ISIS
• Enable ISISv6 over E0/0 of R5 & R2 and S1/0 of R2

• Did ISIS adjacency over E0/0 on R2 went down? Why?
R# ISISv6
R5 interface e0/0
ipv6 router isis
R2 interface s1/0
ipv6 router isis
R2 sh isis neighbor | i R3
• Enable multi topology isis on R2

• Did ISIS adjacency over E0/0 on R2 come back up?
R# ISISv6
R2 router isis
metric-style wide
address-family ipv6
multi-topology
R2 sh isis neighbor | i R3
R3 L1 Et0/0 10.1.0.5 UP 9 R3.01
• Are you receiving any ISISv6 routes on R2? Why not?
• What about ISISv4 routes on R2?
• Enable metric-style wide on all routers
• Did the ISISv4 routes come back on R2?
• What about ISISv6 routes on R2?
R# ISISv4 ISISv6
R2 sh ip route sum | i isis sh ipv6 route sum | i isis
isis 0 0 0 isis 0 0 0
R1/R5 router isis
metric-style wide
R2 sh ip route sum | i isis sh ipv6 route sum | i isis
isis 0 6 0 360 1032 isis 0 0 0
• Change the multi-topology configs on R2 to transition mode

• Did the IPv6 routes come back on R2?
• Change the circuit-type of S1/0 on R2 to level-2 only (not needed in some IOS)
R# ISISv6
R2 Router isis
address-family ipv6
multi-topology transition
R2 Sh ipv6 route sum | i isis
isis 1 88 124
R2 Interface S1/0
Isis circuit-type level-2-only
Sh ipv6 route sum | I isis
isis 5 440 620
• transition keyword must be removed once all the routers are converted into MT-ISIS
otherwise it will carry both ISISv6 TLV as well as MT-ISIS TLV in the database
R# ISISv6
R2 R2#sh isis data R2.00-00 verbose ipv6 l1 | i 2001
IPv6 Address: 2001:DB8:1::

Metric: 10 IPv6 2001:DB8:1::4/127
Metric: 10 IPv6 2001:DB8:1::2/127
Metric: 0 IPv6 2001:DB8:1::/128
Metric: 10 IPv6 2001:DB8:1::6/127
Metric: 10 IPv6 (MT-IPv6) 2001:DB8:1::4/127
Metric: 0 IPv6 (MT-IPv6) 2001:DB8:1::/128
ISISv6 Lab: Multi-Topology ISIS (Answers)
• Single topology rules says: all interfaces of all routers within an area that are enabled for IPv4
ISIS, must also be configured with IPv6 ISIS
• When E0/0 of R2 is configured with ISISv6 the adjacency goes down on that interface
because R3 does not support IPv6 address family so under single SPF rule R3 can not be a
part of SPF
• When we enable multi topology on R2, it enables 2 separate SPF in area 49.0002, one SPF
for IPv4 and one SPF for IPv6
• transition keyword is needed in a situation where a neighbor can not understand MT-ISIS
TLV’s for e.g. R5, R2(Level 2 routes).
• To avoid ISISv4 adjacency going down when multi-topology is enabled on R2 “adjacency-
check” can be disabled under address-family ipv6. This check must be disabled after MT-
ISIS configs are complete
ISISv6 Lab Key
ISISv6 Lab: Configs
R# Configs
ipv6 unicast-routing router isis
R1 ! net 49.0001.0000.0000.0001.00
interface Loopback0 metric-style wide
ip address 10.1.0.1 255.255.255.255 summary-address 10.1.4.4 255.255.255.254
ipv6 address 2001:DB8:1::1/128 passive-interface Loopback0
! !
interface Ethernet0/0 address-family ipv6
ip address 10.1.1.1 255.255.255.0 summary-prefix 2001:DB8:1:4::4/127
ip router isis exit-address-family
ipv6 address 2001:DB8:1:1::1/64
ipv6 router isis
!
interface Serial1/0
ip address 10.1.0.3 255.255.255.254
ip router isis
ipv6 router isis
!
ISISv6 Lab: Configs
R# configs
ipv6 unicast-routing interface Serial1/0
R2 ! ip address 10.1.0.2 255.255.255.254
interface Loopback0 ip router isis
ip address 10.1.0.0 255.255.255.255 ipv6 address 2001:DB8:1::2/127
ipv6 address 2001:DB8:1::/128 ipv6 router isis
! !
interface Tunnel0 router isis
no ip address net 49.0002.0000.0000.0002.00
ipv6 address 2001:DB8:1::6/127 metric-style wide
ipv6 router isis passive-interface Loopback0
tunnel source Serial2/0 !
tunnel destination 10.1.0.7 address-family ipv6
! multi-topology transition
interface Ethernet0/0 exit-address-family
ip address 10.1.0.4 255.255.255.254
ip router isis
ipv6 router isis
!
ISISv6 Lab: Configs
R# Configs
R3 interface Loopback0
ip address 10.1.3.1 255.255.255.255
!
ip address 10.1.0.5 255.255.255.254
ip router isis
!
router isis
net 49.0002.0000.0000.0003.00
is-type level-1
metric-style wide
passive-interface Loopback0
ISISv6 Lab: Configs
R# Configs
ipv6 unicast-routing !
R4 ! ip route 10.1.4.4 255.255.255.255 10.0.0.2
interface Ethernet0/0 ip route 10.1.4.5 255.255.255.255 10.0.0.2
ip address 10.1.1.4 255.255.255.0 !
ip router isis !
ipv6 address 2001:DB8:1:1::4/64 ipv6 route 2001:DB8:1:4::4/128 2001:DB8::2
ipv6 router isis ipv6 route 2001:DB8:1:4::5/128 2001:DB8::2
!
ip address 10.0.0.1 255.255.255.0
ip router isis
ipv6 router isis
!
router isis
net 49.0001.0000.0000.0004.00
is-type level-1
metric-style wide
redistribute static ip level-1
!
address-family ipv6
redistribute static level-1
exit-address-family
ISISv6 Lab: Configs
R# Configs
ipv6 unicast-routing router isis
R5 ! net 49.0002.0000.0000.0005.00
interface Tunnel0 is-type level-1
no ip address metric-style wide
ipv6 router isis
tunnel source Serial1/0
!
ip address 10.1.2.5 255.255.255.0
ip router isis
ipv6 address 2001:DB8:1:2::5/64
ipv6 router isis
!
interface Serial1/0
ip address 10.1.0.7 255.255.255.254
ip router isis
!
BGPv6 Lab
BGPv6 Lab Agenda
• iBGPv6 peering over global unicast

• Peer groups & Route Reflector in BGPv6
• IPv6 NLRI over link local
• IPv6 NLRI over IPv4
• IPv4 NLRI over link local
• IPv4 NLRI over global unicast
BGPv6 Lab Topology
BGPv6 Instructions
• OSPFv3 is pre-configured between R1-R2-R3
• BGP for IPv4 is pre-configured in AS 1, 2 & 109
BGPv6 Lab: iBGP over global unicast
• Configure iBGP between R1-R2 & R2-R3
• Compare difference between IPv4 and IPv6 BGP
• *IPv4 BGP configs are there for comparison purpose
R# *BGPv4 BGPv6
R1 router bgp 109 router bgp 109
neighbor 10.1.0.0 remote-as 109 neighbor 2001:DB8:1:: remote-as 109
neighbor 10.1.0.0 update-source L0 neighbor 2001:DB8:1:: update-source L0
address-family ipv6
neighbor 2001:DB8:1:: activate

neighbor 10.1.0.1 remote-as 109 neighbor 2001:DB8:1::1 remote-as 109
neighbor 10.1.0.1 update-source L0 neighbor 2001:DB8:1::1 update-source L0
neighbor 10.1.3.1 remote-as 109 neighbor 2001:DB8:1:3::3 remote-as 109
neighbor 10.1.3.1 update-source L0 neighbor 2001:DB8:1:3::3 update-source L0
address-family ipv6
neighbor 2001:DB8:1::1 activate
neighbor 2001:DB8:1:3::3 activate
R# *BGPv4 BGPv6
neighbor 10.1.0.0 remote-as 109 neighbor 2001:DB8:1:: remote-as 109
neighbor 10.1.0.0 update-source L0 neighbor 2001:DB8:1:: update-source L0
address-family ipv6
neighbor 2001:DB8:1:: activate
• Verify that the peers have been established by using appropriate show commands.
• Why do we see peering over ipv6 in both IPv4 as well as IPv6 address family?
• *Only R2 peering is shown as it covers all peering.
R# BGPv4 BGPv6
R2#sh bgp ipv4 unicast sum | i 109 R2#sh bgp ipv6 unicast sum | i 109
R2 BGP router identifier 10.1.0.0, local AS number 109 BGP router identifier 10.1.0.0, local AS number 109
10.1.0.1 4 109 325 327 3 0 0 04:53:45 1 2001:DB8:1::1 4 109 46 43 1 0 0 00:38:06 0
10.1.3.1 4 109 328 328 3 0 0 04:53:15 1 2001:DB8:1:3::3 4 109 46 45 1 0 0 00:38:06 0
2001:DB8:1::1 4 109 94 93 3 0 0 01:19:52 1 R2#
2001:DB8:1:3::3 4 109 84 84 3 0 0 01:13:16 1
R2#
• Deactivate peering over IPv6 in IPv4 address-family in R1, R2 and R3.
• Do we see only ipv4 peering under address-family ipv4 now?
• How is the BGP configs different then before?
R# BGPv4 BGPv6
R1/R3 router bgp 109
no neighbor 2001:DB8:1:: activate
R2 router bgp 109

no neighbor 2001:DB8:1::1 activate
no neighbor 2001:DB8:1:3::3 activate
R2 R2#sh bgp ipv4 unicast sum | i 109 R2#sh bgp ipv6 unicast sum | i 109
BGP router identifier 10.1.0.0, local AS number 109 BGP router identifier 10.1.0.0, local AS number 109
10.1.0.1 4 109 325 327 3 0 0 04:53:45 1 2001:DB8:1::1 4 109 46 43 1 0 0 00:38:06 0
10.1.3.1 4 109 328 328 3 0 0 04:53:15 1 2001:DB8:1:3::3 4 109 46 45 1 0 0 00:38:06 0
BGPv6 Lab: iBGPv6 over global unicast
(Answers)
• Configuring BGPv6 over IPv6 global unicast address is very similar to IPv4 BGP
• Instead of IPv4 address in BGP peering, IPv6 address is used
• One unique thing that is required for every BGP peering is to activate BGP session under IPv6
• By default BGP will form peering for IPv4 AND IPv6
• IPv4 address-family peering needs to be deactivated specifically
• This will change the BGP configs and address-family ipv4 will start showing up in the configs
for ipv4 address family specific configs
BGPv6 Lab: BGPv6 peer groups & Route
Reflector
• Configure BGPv6 peer groups on R2 for R1 & R3
• Configure R2 as route reflector for R1 & R3
• Compare difference between IPv4 and IPv6 BGP peer groups & Route Reflector
R# *BGPv4 BGPv6
neighbor RR-client peer-group neighbor RR-v6client peer-group
neighbor RR-client remote-as 109 neighbor RR-v6client remote-as 109
neighbor RR-client update-source Lo0 neighbor RR-v6client update-source Lo0
neighbor 10.1.0.1 peer-group RR-client neighbor 2001:DB8:1::1 peer-group RR-v6client
neighbor 10.1.3.1 peer-group RR-client neighbor 2001:DB8:1:3::3 peer-group RR-v6client
address-family ipv4 address-family ipv6
neighbor RR-client route-reflector-client neighbor RR-v6client route-reflector-client
neighbor 10.1.0.1 activate neighbor 2001:DB8:1::1 activate
neighbor 10.1.3.1 activate neighbor 2001:DB8:1:3::3 activate
BGPv6 Lab: IPv6 NLRI over link local
• Configure eBGPv6 peering between R1 & R4 over link local under address-family ipv6.
• Did you get any errors?
• Use valid scoping and configure the eBGPv6 peers.
• Did the peer come up? Note: Last 64 bit may be different in your lab setup
R# *BGPv4 BGPv6
R1 router bgp 109 ipv6 unicast-routing
neighbor 10.1.1.4 remote-as 1 router bgp 109
address-family ipv6
neighbor FE80::A8BB:CCFF:FE00:5400 remote 1
% BGP(v6): Invalid scope. Unable to configure link-local peer.
R1 router bgp 109
address-family ipv6
neighbor FE80::A8BB:CCFF:FE00:5400%Ethernet0/0 remote-as 1
R4 router bgp 1
address-family ipv6
R4 %BGP-5-ADJCHANGE: neighbor FE80::A8BB:CCFF:FE00:5100%Ethernet0/0 Up
• Propagate E1/0 IPv6 prefix from R4

• Did you have to do next-hop-self on R1 toward iBGP peers like in IPv4? Why not?
• Can you configure link local peering for iBGP?
R# *BGPv4 BGPv6

neighbor 10.1.0.0 remote-as 109 address-family ipv6
! neighbor 2001:DB8:1:: activate
address-family ipv4
neighbor 10.1.0.0 next-hop-self
R3 R3#sh bgp ipv6 uni | i 2001

*>i2001:DB8::/64 2001:DB8:1::1 0 100 01i
• Link local peering can not be done without mentioning a valid scope which is an outgoing
interface
• The default link local address can be manually changed to a fix value on the interface (such
as FE80::1) to simplify the configuration and management
• Link local peering can not be done for iBGP peering since the link local address can not exist
outside the local segment(iBGP peers are usually more than one hop away)
• Next-hop over link local peering is not preserved when the prefixes learned over link local is
propagated over iBGP
• Next-hop-self behavior is automatically applied in this case so R1 will use its loopback
address when prefixes are propagated over iBGP
BGPv6 Lab: IPv6 NLRI over IPv4
• Configure an eBGPv6 peering between R3 & R5 over IPv4 address under address-family ipv6
and propagate R5 loopback0 over eBGPv6 from R5
• Is this route accessible from R4? Why not?
R# BGPv6
router bgp 109
address-family ipv6
neighbor 10.1.2.5 remote 2
R5 router bgp 2
address-family ipv6
neighbor 10.1.2.3 remote-as 109
network 2001:DB8:1:5::3/128
%BGP-5-ADJCHANGE: neighbor 10.1.2.3 session 2 Up
R4 R4#sh ipv route bgp | i 2001
• Debug ipv6 bgp update on R3, force BGP update out from R5 and check the debug
output
• Why is it complaining about invalid path?
• Create a route-map on R5 and set the next-hop to the outgoing IPv6 address of R5
• Is the prefix advertised by R5 reachable from R4 now? (solution on the next slide)
R# BGPv6
R3 R3#debug bgp ipv6 update
R5 R5#clear bgp ipv6 uni * out
R3 BGP(1): 10.1.2.5 session 2 rcvd UPDATE w/ attr: nexthop ::FFFF:10.1.2.5, origin i, metric 0, merged
path 2, AS_PATH
*BGP(1): no valid path for 2001:DB8:1:5::3/128
R5 route-map ipv6-nh permit 10
set ipv6 next-hop 2001:DB8:1:2::5
router bgp 2
address-family ipv6
neighbor 10.1.2.3 route-map ipv6-nh out
R4 R4#sh ipv6 route bgp | i 2001
• Does route reflector knows the path to the next hop?

• Check the BGP table on RR (R2).
• Enable OSPFv3 on E0/0 of R3.
• Is the prefix advertised by R5 reachable from R4 now?
R# BGPv6
R2 R2#sh bgp ipv6 uni | b 2001:DB8:1:5::3

* i 2001:DB8:1:5::3/128
2001:DB8:1:2::5 0 100 02i
R2 R2#sh ipv6 route 2001:db8:1:2::5

% Route not found
R3 interface e0/0
ipv6 ospf 1 area 0
R4 R4#sh ipv6 route bgp | i 2001

B 2001:DB8:1:5::3/128 [20/0]
BGPv6 Lab: IPv6 NLRI over IPv4 (Answers)
• When IPv6 NLRI is sent over IPv4 peering it uses IPv4 mapped IPv6 address as a next hop
• IPv4 mapped ipv6 next hop is only consider as a valid next hop if the receiving router is either
a 6PE or 6VPE.
• The way to fix this is to set a route-map outbound from R5 and send a valid IPv6 next hop in
the update
• Next hop must be reachable by the receiving router either via IGP or sending BGP speaker
must do next-hop-self
• Change the ipv4 peering to link local between R1-R4
• Is the prefix 10.0.0.0/24 acceptable on R1? Why not?
R# BGPv4
R4 router bgp 1
No neighbor 10.1.1.1 remote-as 109
Address-family ipv4
neighbor FE80::A8BB:CCFF:FE00:5100%Ethernet0/0 activate
R1 router bgp 109

No neighbor 10.1.1.4 remote-as 1
Address-family ipv4
%BGP-5-ADJCHANGE: neighbor FE80::A8BB:CCFF:FE00:5100%Ethernet0/0 Up
R1 R1#sh ip route bgp | i 10.0.0.0 255.255.255.0
• Debug bgp update for ipv4 on R4.
• What is wrong with the next hop?
• Create a route-map outbound on R4 and set the next-hop to ipv4 address.
R# BGPv4
R4 R4#deb ip bgp up
R4#clear ip bgp * out
R4#
*BGP(0): Can't advertise 10.0.0.0/24 to
FE80::A8BB:CCFF:FE00:5100%Ethernet0/0 with NEXT_HOP 254.128.0.0
set ip next-hop 10.1.1.4
router bgp 1
address-family ipv4
neighbor FE80::A8BB:CCFF:FE00:5100%Ethernet0/0 route-map ipv4-nh
out
• Clear bgp update outbound on R4.

• Is the route being advertised with a proper next hop?
• Check if R5 is receiving this route.
R# BGPv4
R4 Clear ip bgp * out

BGP(0): FE80::A8BB:CCFF:FE00:5100%Ethernet0/0 NEXT_HOP is set to
10.1.1.4 by policy for net 10.0.0.0/24,
BGP(0): FE80::A8BB:CCFF:FE00:5100%Ethernet0/0 send UPDATE (format)
10.0.0.0/24, next 10.1.1.4, metric 0, path Local
R5 R5#sh ip route bgp | i 10.0.0.0/24
B 10.0.0.0/24 [20/0] via 10.1.2.3, 00:04:03
BGPv6 Lab: IPv4 NLRI over link local (Answers)
• When IPv4 NLRI is sent over IPv6 link local peering it converts peering address into 32 bit
IPv4 address
• So FE80:: becomes 254.128.0.0
the update
• Next hop must be reachable by the receiving router either via IGP or sending BGP speaker
must do next-hop-self
BGPv6 Lab: IPv4 NLRI over global unicast
• Change the ipv4 peering to IPv6 global unicast between R3-R5

• Is the prefix 10.1.5.1/32 acceptable on R3? Why not?
R# BGPv4
R5 router bgp 2
No neighbor 10.1.2.3 remote 109
neighbor 2001:DB8:1:2::3 remote-as 109
R3 router bgp 109

No neighbor 10.1.2.5 remote 2
neighbor 2001:db8:1:2::5 remote 2
%BGP-5-ADJCHANGE: neighbor 2001:DB8:1:2::5 Up
R3 R1#sh ip route bgp | i 10.1.5.1
• Debug bgp update for ipv4 on R3
• What wrong with the next hop?
• Create a route-map outbound on R5 and set the next-hop to ipv4 address
R# BGPv4
R3 R3#debug ip bgp up
R5 R5#clear ip bgp * out
R3 BGP(0): 2001:DB8:1:2::5 rcvd UPDATE w/ attr: nexthop 32.1.13.184, origin
i, metric 0, merged path 2, AS_PATH
Router bgp 2
address-family ipv4
neighbor 2001:DB8:1:2::3 route-map ipv4-nh out
• Clear bgp update outbound on R5.
• Is the route being advertised with a proper next hop?
• Check if R4 is receiving this route, why not?
R# • Do a debug ip bgp update on R1.
BGPv4
R5 R5#debug ip bgp update
R5#clear ip bgp * soft out
BGP(0): 2001:DB8:1:2::3 NEXT_HOP is set to 10.1.2.5 by policy for net 10.1.5.1/32,
*Nov 28 05:40:35.544: BGP(0): 2001:DB8:1:2::3 send UPDATE (format) 10.1.5.1/32,
next 10.1.2.5, metric 0, path Local
R1 R1#debug ip bgp up
R1#clear ip bgp * soft out
BGP(0): Can't advertise 10.1.5.1/32 to FE80::A8BB:CCFF:FE00:5400%Ethernet0/0
with NEXT_HOP 254.128.0.0
• Create a route-map on R1 and set the next hop to IPv4 address toward R4
• Is the being learned by R4 now?
R# BGPv4
Router bgp 109
address-family ipv4
neighbor FE80::A8BB:CCFF:FE00:5400%Ethernet0/0 route-map ipv4-nh out
R1 R1#clear ip bgp * soft out
BGP(0): FE80::A8BB:CCFF:FE00:5400%Ethernet0/0 NEXT_HOP is set to 10.1.1.1
by policy for net 10.1.5.1/32,
*Nov 28 06:00:31.368: BGP(0): FE80::A8BB:CCFF:FE00:5400%Ethernet0/0 send
UPDATE (format) 10.1.5.1/32, next 10.1.1.1, metric 0, path 2
B 10.1.5.1/32 [20/0] via 10.1.1.1, 00:08:36
(Answers)
• When IPv4 NLRI is sent over IPv6 global unicast peering it converts peering address into 32
bit IPv4 address
• So 2001:db8: becomes 32.1.13.184
the update
• Since ipv4 peering between R1 and R4 is over link local, we run into the same issue so we
have to set the route-map outbound from R1 towards R4 and set its ipv4 address as a next
hop towards R4
BGPv6 Lab Key
BGPv6 Lab: Configs
R# Configs
ipv6 unicast-routing router bgp 109
R1 ! neighbor 10.1.0.0 remote-as 109
interface Loopback0 neighbor 10.1.0.0 update-source Loopback0
ip address 10.1.0.1 255.255.255.255 neighbor 2001:DB8:1:: remote-as 109
ip ospf 1 area 0 neighbor 2001:DB8:1:: update-source Loopback0
ipv6 address 2001:DB8:1::1/128 neighbor FE80::A8BB:CCFF:FE00:5400%Ethernet0/0
ipv6 ospf 1 area 0 remote-as 1
! !
interface Ethernet0/0 address-family ipv4
ip address 10.1.1.1 255.255.255.0 neighbor 10.1.0.0 activate
ipv6 address 2001:DB8:1:1::1/64 neighbor 10.1.0.0 next-hop-self
! no neighbor 2001:DB8:1:: activate
interface Serial1/0 neighbor FE80::A8BB:CCFF:FE00:5400%Ethernet0/0
ip address 10.1.0.3 255.255.255.254 activate
ip ospf 1 area 0 neighbor FE80::A8BB:CCFF:FE00:5400%Ethernet0/0
ipv6 address 2001:DB8:1::3/127 route-map ipv4-nh out
ipv6 ospf 1 area 0 exit-address-family
! !
router ospf 1 address-family ipv6
neighbor FE80::A8BB:CCFF:FE00:5400%Ethernet0/0
activate
!
ipv6 router ospf 1
!
route-map ipv4-nh permit 10
BGPv6 Lab: Configs
R# Configs
R2 ! neighbor RR-client peer-group
interface Loopback0 neighbor RR-client remote-as 109
ip address 10.1.0.0 neighbor RR-client update-source Loopback0
255.255.255.255 neighbor RR-v6client peer-group
ip ospf 1 area 0 neighbor RR-v6client remote-as 109
ipv6 address 2001:DB8:1::/128 neighbor RR-v6client update-source Loopback0
ipv6 ospf 1 area 0 neighbor 10.1.0.1 peer-group RR-client
! neighbor 10.1.3.1 peer-group RR-client
interface Ethernet0/0 neighbor 2001:DB8:1::1 peer-group RR-v6client
ip address 10.1.0.4 neighbor 2001:DB8:1:3::3 peer-group RR-v6client
255.255.255.254 !
ip ospf 1 area 0 address-family ipv4
ipv6 address 2001:DB8:1::4/127 neighbor RR-client route-reflector-client
ipv6 ospf 1 area 0 neighbor 10.1.0.1 activate
! neighbor 10.1.3.1 activate
interface Serial1/0 no neighbor 2001:DB8:1::1 activate
ip address 10.1.0.2 no neighbor 2001:DB8:1:3::3 activate
255.255.255.254 exit-address-family
ip ospf 1 area 0 !
ipv6 address 2001:DB8:1::2/127 address-family ipv6
ipv6 ospf 1 area 0 neighbor RR-v6client route-reflector-client
! neighbor 2001:DB8:1::1 activate
!
ipv6 router ospf 1
BGPv6 Lab: Configs
R# Configs
R3 ! neighbor 10.1.0.0 remote-as 109
ip address 10.1.3.1 255.255.255.255 neighbor 2001:DB8:1:: remote-as 109
ip ospf 1 area 0 neighbor 2001:DB8:1:: update-source Loopback0
ipv6 address 2001:DB8:1:3::3/128 neighbor 2001:DB8:1:2::5 remote-as 2
ipv6 ospf 1 area 0 !
! address-family ipv4
interface Ethernet0/0 neighbor 10.1.0.0 activate
ip address 10.1.2.3 255.255.255.0 no neighbor 2001:DB8:1:: activate
ip ospf 1 area 0 neighbor 2001:DB8:1:2::5 activate
ipv6 address 2001:DB8:1:2::3/64 !
ipv6 ospf 1 area 0 address-family ipv6
ip address 10.1.0.5 255.255.255.254 ipv6 router ospf 1
ip ospf 1 area 0
ipv6 ospf 1 area 0
!
BGPv6 Lab: Configs
R# Configs
R4
ipv6 unicast-routing
!
ip address 10.1.1.4 255.255.255.0
ipv6 address 2001:DB8:1:1::4/64
!
ip address 10.0.0.1 255.255.255.0
!
router bgp 1
bgp log-neighbor-changes
!
address-family ipv4
network 10.0.0.0 mask 255.255.255.0
neighbor FE80::A8BB:CCFF:FE00:5100%Ethernet0/0 route-map ipv4-nh out
!
address-family ipv6
network 2001:DB8::/64
!
route-map ipv4-nh permit 10
BGPv6 Lab: Configs
R# Configs
ipv6 unicast-routing route-map ipv4-nh permit 10
R5 interface Loopback0 set ip next-hop 10.1.2.5
ip address 10.1.5.1 255.255.255.255 !
ipv6 address 2001:DB8:1:5::3/128 route-map ipv6-nh permit 10
! set ipv6 next-hop 2001:DB8:1:2::5
ip address 10.1.2.5 255.255.255.0
ipv6 address 2001:DB8:1:2::5/64
!
router bgp 2
!
address-family ipv4
network 10.1.5.1 mask 255.255.255.255
neighbor 2001:DB8:1:2::3 route-map ipv4-nh
out
exit-address-family
!
address-family ipv6
network 2001:DB8:1:5::3/128
exit-address-family
!
6PE Lab
6PE Lab Agenda
• Enabling OSPFv3 as a PE-CE protocol on a non vrf based

interface
• Enabling BGPv6 as a PE-CE protocol on a non vrf based

interface
• Enabling 6PE
6PE Lab Topology
6PE Instructions
• MPLS/LDP is preconfigured in AS 109 between R1-R2-R3

• OSPFv2 is pre-configured between R1-R4(E0/0-E0/0) as a PE-CE protocol (over a
VRF interface)
• BGP for IPv4 is pre-configured between R3-R5(E2/0-E1/0) as a PE-CE protocol
(over a VRF interface)
• IPv6 address are pre-configured between R1-R4(E1/0-E1/0) & R3-R5(E0/0-E0/0)
• Note, a separate interface is used for 6PE. This is usually a case where ipv4 internet
routes or a default routes are received on that interface. IPv6 can be enabled on that
interface to receive ipv6 internet prefixes and that will be a dual stack environment
but in lab, we are only using that interface for IPv6
6PE Lab: Enabling OSPFv3 on PE-CE link
• Configure OSPFv3 between R1-R4.
• Why are we configuring ospfv3 on a separate interface?
R# OSPFv3
R1 interface Ethernet1/0
ospfv3 1 ipv6 area 0
!
router ospfv3 1
router-id 10.1.0.1
R4 interface Loopback0
!
!
router ospfv3 1
router-id 10.0.0.1
• Configure mutual redistribution between OSPFv3 and BGP.

• In which routing table (global or VRF) do you see the V6 routes after the redistribution on R1?
R# OSPFv3 and Redistribution
R1 router ospfv3 1
address-family ipv6
redistribute bgp 109
!
router bgp 109
address-family ipv6
redistribute ospf 1
• Verify that the peers have been established and that R4 loopback address is received
and seen in BGP on R1
R# BGPv6
R1 R1#sh ipv6 ospf nei
OSPFv3 Router with ID (10.1.0.1) (Process ID 1)
Neighbor ID Pri State Dead Time Interface ID Interface

10.0.0.1 1 FULL/BDR 00:00:38 6 Ethernet1/0
R1#sh ipv6 route 2001:db8::4

Routing entry for 2001:DB8::4/128
Known via "ospf 1", distance 110, metric 10, type intra area, bgp 109
Route count is 1/1, share count 0
Routing paths:
FE80::A8BB:CCFF:FE00:5401, Ethernet1/0
Last updated 03:17:09 ago
R1#sh bgp ipv6 unicast

Network Next Hop Metric LocPrf Weight Path
*> 2001:DB8::4/128 :: 10 32768 ?
R1#
(Answers)
• We are getting global IPv4 and IPv6 routes on a separate interface and l3vpn routes over
another interface.
• 6PE installs the routes in the global routing table
• Note that although OSPFv3 is enabled under the interface itself, the redistribution is
enabled under the ospfv3 router process
• As 6PE uses the global routing table, configuring OSPFv3 in the context of 6PE does not
require anything special
6PE Lab: Enabling BGPv6 as a PE-CE protocol
• Configure BGPv6 between R3-R5.

• Advertise R5 loopback address in BGPv6.
• Why don’t we need to configure redistribution?
R# BGPv6 and Redistribution

R3 router bgp 109
neighbor 2001:db8:1:2::5 remote-as 2
!
address-family ipv6
neighbor 2001:db8:1:2::5 active
R5 router bgp 2
!
address-family ipv6
neighbor 2001:db8:1:2::3 activate
network 2001:db8:1:5::3/128
• Verify that the peers has been established by using appropriate show commands
• Verify that R5 loopback address is seen on R3
• Can we configure the PE-CE BGP session over a IPv4 transport in a 6PE scenario?
R# BGPv6
R3 R3#sh bgp ipv6 unicast summ

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2001:DB8:1:2::5 4 2 14 14 5 0 0 00:08:33 1
R3#
R3#sh bgp ipv6 unicast
BGP table version is 5, local router ID is 10.1.3.1
*> 2001:DB8:1:5::3/128
2001:DB8:1:2::5 0 0 2i
R3#
(Answers)
• Redistribution is not required for BGP routes received from the CE as the routes will be
propagated automatically to the 6PE peers via separate iBGP session exclusively for 6PE
• The PE-CE BGP session in 6PE is just like any other IPv6 eBGP session. It could be
configured over an IPv4 or IPv6 transport. The normal restrictions would apply. For example,
a route-map would be required to change the BGP next hop.
6PE Lab: Enabling 6PE
• Configure iBGP between R1-R2 (RR) & R2-R3.

• IPv4 BGP configs are there for comparison purposes.
• What is the purpose of the send-label keyword in 6PE?
R# *BGPv4 BGPv6
R1&R3 router bgp 109 router bgp 109
neighbor 10.1.0.0 remote-as 109 neighbor 10.1.0.0 remote-as 109
neighbor 10.1.0.0 update-source L0 neighbor 10.1.0.0 update-source L0
neighbor 10.1.0.0 act neighbor 10.1.0.0 activate
neighbor 10.1.0.0 send-label
R# *BGPv4 BGPv6
neighbor 10.1.0.1 activate neighbor 10.1.0.1 activate
neighbor 10.1.0.1 route-reflector-client neighbor 10.1.0.1 send-label
neighbor 10.1.3.1 activate neighbor 10.1.0.1 route-reflector-client
neighbor 10.1.3.1 route-reflector-client neighbor 10.1.3.1 activate
neighbor 10.1.3.1 route-reflector-client
• Verify that the peers has been established by using appropriate show commands.
• *Only R2 (RR) peering is shown as it covers all peering.
• Why don’t we have ipv6 neighbors?
R# BGPv6
R2 R2#sh bgp ipv6 unicast summ
BGP router identifier 10.1.0.0, local AS number 109
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down

State/PfxRcd
10.1.0.1 4 109 15 15 1 0 0 00:10:04 0
10.1.3.1 4 109 13 11 1 0 0 00:08:38 0
R2#
• Verify that R5 loopback is received on R1 and what label is advertised for it.
• What is the next hop for it and why?
• Look at R5 loopback address in cefv6.
• Why do we see 2 labels for this ipv6 prefix?
R# BGPv6
R1 R1#sh bgp ipv6 unicast label
Network Next Hop In label/Out label
2001:DB8::4/128 :: 16/nolabel
2001:DB8:1:5::3/128
::FFFF:10.1.3.1 nolabel/17
R1#sh ip cef 10.1.3.1

10.1.3.1/32
nexthop 10.1.0.2 Serial2/0 label 17
R1#sh ipv6 cef 2001:db8:1:5::3

2001:DB8:1:5::3/128
nexthop 10.1.0.2 Serial2/0 label 17 17
6PE Lab: Enabling 6PE (Answers)
• 6PE requires configuring the BGP session over an IPv4 transport as the core is not IPv6
enabled
• This is done by activating a neighbor with an IPv4 peer address under address-family ipv6
• The send-label statement under address-family ipv6 is really what enables 6PE
• 6PE uses an IGP label to get the ipv6 packet from the ingress to the egress PE. It is the LDP
label learnt for the BGP next hop (IPv4 address).
• It also uses a service label on the egress PE to forward the packet through the proper egress
interface. The service label is learnt via BGP as a result of the send-label keyword.
6PE Lab: Enabling 6PE (Answers)
• The BGP next hop for R5 loopback address is actually R3 loopback IPv4 address. It is
displayed as an IPv4 mapped IPv6 address. The first 80 bits are all zero followed by 0xFFFF
and then the IPv4 next hop address of the egress PE in dotted decimal format
• Redistribution is not required for BGP routes received from the CE as the routes will be
propagated automatically to the 6PE peers.
6PE Lab Key
6PE Lab: Configs
R# Configs
R1 ipv6 cef no bgp default ipv4-unicast
! neighbor 10.1.0.0 remote-as 109
ip address 10.1.0.1 255.255.255.255 neighbor 10.1.3.1 remote-as 109
! neighbor 10.1.3.1 update-source Loopback0
ipv6 address 2001:DB8:1:1::1/64 address-family ipv6
ospfv3 1 ipv6 area 0 redistribute ospf 1
interface Serial2/0 neighbor 10.1.0.0 send-label
ip address 10.1.0.3 255.255.255.254 exit-address-family
mpls ip
!
router ospfv3 1
router-id 10.1.0.1
!
address-family ipv6 unicast
redistribute bgp 109
exit-address-family
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
6PE Lab: Configs
R# Configs
interface Loopback0 router bgp 109
R2 ip address 10.1.0.0 255.255.255.255 neighbor 10.1.0.1 remote-as 109
interface Ethernet0/0 neighbor 10.1.3.1 remote-as 109
ip address 10.1.0.4 255.255.255.254 neighbor 10.1.3.1 update-source Loopback0
mpls ip !
! address-family ipv6
interface Serial1/0 neighbor 10.1.0.1 activate
ip address 10.1.0.2 255.255.255.254 neighbor 10.1.0.1 send-label
mpls ip neighbor 10.1.0.1 route-reflection-client
router ospf 1 neighbor 10.1.3.1 send-label
nerwork 0.0.0.0 255.255.255.255 area 0 neighbor 10.1.3.1 route-reflection-client
!
6PE Lab: Configs
R# Configs
R3 ipv6 cef bgp log-neighbor-changes
! no bgp default ipv4-unicast
interface Loopback0 neighbor 10.1.0.0 remote-as 109
ip address 10.1.3.1 255.255.255.255 neighbor 10.1.0.0 update-source Loopback0
! neighbor 2001:DB8:1:2::5 remote-as 2
no ip address address-family ipv6
ipv6 address 2001:DB8:1:2::3/64 neighbor 10.1.0.0 activate
! neighbor 10.1.0.0 send-label
interface Ethernet1/0 neighbor 2001:DB8:1:2::5 activate
ip address 10.1.0.5 255.255.255.254 exit-address-family
mpls ip
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
6PE Lab: Configs
R# Configs
R4 !
interface Loopback0
ip address 10.0.0.1 255.255.255.255
ipv6 address 2001:db8::4/128
!
ipv6 address 2001:DB8:1:1::4/64
!
router ospfv3 1
router-id 10.0.0.1
!
address-family ipv6 unicast
exit-address-family
!
6PE Lab: Configs
R# Configs
ipv6 cef
!
interface Loopback0
ipv6 address 2001:DB8:1:5::3/128
!
ipv6 address 2001:DB8:1:2::5/64
!
router bgp 2
!
address-family ipv6
network 2001:DB8:1:5::3/128
exit-address-family
6VPE Lab
6VPE Lab Agenda
• Enabling static a PE-CE protocol for IPv6
• Enabling BGP as a PE-CE protocol for IPv6
• Enabling 6VPE
6VPE Lab Topology
6VPE Instructions
• MPLS/LDP is preconfigured in AS 109 between R1-R2-R3

• OSPFv2 is preconfigured between R1-R2-R3
• IPv6 address are preconfigured between R1-R4 & R3-R5
• PE-CE protocol between R1-R4 is static for IPv4 and is preconfigured
• PE-CE protocol between R3-R5 is BGP for IPv4 and is preconfigured
6VPE Lab: Enabling static as a PE-CE protocol
• Enable IPv6 VRF on R1
• Configure static route between R1-R4
• Redistribute static in BGP
R# OSPFv3 and Redistribution
R1 vrf upgrade-cli multi-af-mode common-policies vrf 6vpe force*

!
vrf definition 6vpe
address-family ipv6
!
ipv6 route vrf 6vpe 2001:db8::/64 201:db8:1:1::4
!
router bgp 109
address-family ipv6 vrf 6vpe
redistribute static
R4 ipv6 route ::/0 2001:db8:1:1::1
Note: Will need to re-enter IPv6 address since enabling VRF will remove the IPv6 address from the interface
• Verify that static route is installed in the VRF and that it is present in BGP
• What is the purpose of the “vrf upgrade-cli” command?
R# BGPv6
R4 R4#sh ipv6 route ::/0

Routing entry for ::/0
Known via "static", distance 1, metric 0
Backup from "static [2]"
Route count is 1/1, share count 0
Routing paths:
2001:DB8:1:1::1
Last updated 00:01:22 ago
R1 R1#sh ipv6 route vrf 6vpe | incl 2001:DB8::/64

S 2001:DB8::/64 [1/0]
R1#sh bgp vpnv6 unicast all | incl 2001:DB8::/64

*> 2001:DB8::/64 2001:DB8:1:1::4 0 32768 ?
R1#
(Answers)
• The “vrf upgrade-cli” command converts the IPv4 centric VRF CLI to a multi address family
VRF CLI. There are several option with this command. For example, only one VRF can be
converted into new format at a time. “force” command will not prompt for the verification.
Common policies will keep the same policies as IPv4 vrf
• Note that the VRF configuration as been slightly modified to accommodate multiple address
families
• Static routes in the context of 6VPE are very similar to any other static routes. They just need
to be configured as part of the VRF configuration on the PE
6VPE Lab: Enabling BGP as a PE-CE protocol
• Enable IPv6 VRF on R3
• Configure BGP between R3-R5
R# Static and redistribution for V6
R3 vrf upgrade-cli multi-af-mode common-policies vrf 6vpe force*
!
vrf definition 6vpe
address-family ipv6
!
router bgp 109
address-family ipv6 vrf 6vpe
R5 router bgp 2
no bgp default ipv4-unicast
address-family ipv6
network 2001:db8:1:5::3/128
neighbor 2001:db8:1:2::3 activate
Note: Will need to re-enter IPv6 address since enabling VRF will remove the IPv6 address from the interface
• Verify the BGP sessions are up and that the routes are advertised
R# Static routes
R3 R3#sh bgp vpnv6 uni all summ | incl 2001
2001:DB8:1:2::5 4 2 57 59 4 0 0 00:48:33 1
R3#sh bgp vpnv6 uni all | incl 2001:DB8:1:5::3

*> 2001:DB8:1:5::3/128
R3#
R5 R5#sh bgp ipv6 uni summ | incl 2001

2001:DB8:1:2::3 4 109 61 59 3 0 0 00:50:21 1
R5#sh bgp ipv6 uni | incl 2001:DB8::/64

*> 2001:DB8::/64 2001:DB8:1:2::3 0 109 ?
R5#
(Answers)
• The BGP session on the PE is in the VRF context, whereas it is a simple BGP session on the
CE
• Note that just as for IPv4 BGP in a VRF context, the neighbor address only needs to be
configured under the appropriate address-family for the specific VRF
• Just like any IPv6 BGP session, you can either use an IPv6 or IPv4 transport address when
you configure the BGP session in the VRF context
6VPE Lab: Enabling 6VPE
• Configure iBGP between R1-R2 (RR) & R2-R3

• Compare difference between IPv4 and IPv6 BGP
R# *BGPv4 BGPv6
R1&R3 router bgp 109 router bgp 109
address-family vpnv4 address-family vpnv6
neighbor 10.1.0.0 act neighbor 10.1.0.0 activate
R# *BGPv4 BGPv6
address-family vpnv4 address-family vpnv6
neighbor 10.1.0.1 route-reflector-client neighbor 10.1.0.1 route-reflector-client
neighbor 10.1.3.1 route-reflector-client neighbor 10.1.3.1 route-reflector-client
• Verify the BGP sessions are up on the RR and that the routes are advertised
R# Static routes
R2 R2#sh bgp vpnv6 uni all summ
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

10.1.0.1 4 109 72 71 3 0 0 01:00:42 1
10.1.3.1 4 109 68 66 3 0 0 00:57:40 1
R2#sh bgp vpnv6 uni all

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter, a
additional-path
Origin codes: i - IGP, e - EGP, ? - incomplete

Route Distinguisher: 1:1
*>i 2001:DB8::/64 ::FFFF:10.1.0.1 0 100 0 ?
*>i 2001:DB8:1:5::3/128
::FFFF:10.1.3.1 0 100 0 2i
• Verify that routes are received and installed in the CEF table
R# Static routes
R1 R1#sh bgp vpnv6 uni all
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-
Filter, a additional-path
Origin codes: i - IGP, e - EGP, ? - incomplete

Route Distinguisher: 1:1 (default for vrf 6vpe)
*> 2001:DB8::/64 2001:DB8:1:1::4 0 32768 ?
*>i 2001:DB8:1:5::3/128
::FFFF:10.1.3.1 0 100 02i
R1#sh ip cef 10.1.3.1
10.1.3.1/32
nexthop 10.1.0.2 Serial1/0 label 17
R1#sh ipv6 cef vrf 6vpe 2001:db8:1:5::3
2001:DB8:1:5::3/128
nexthop 10.1.0.2 Serial1/0 label 17 20
R1#
6VPE Lab: Enabling 6VPE (Answers)
• Just like 6PE and L3VPN for IPv4, 6VPE uses a label stack to forward traffic through the
MPLS core.
• The IGP label is learnt via LDP and correspond to the BGP next hop (loopback address of
the egress PE).
• The service label is learnt via the BGP AF VPNv6, which is configured between the two PE
6VPE Lab Key
6VPE Lab: Configs
R# Configs
vrf definition 6vpe router bgp 109
R1 rd 1:1 bgp log-neighbor-changes
route-target export 1:1 no bgp default ipv4-unicast
route-target import 1:1 neighbor 10.1.0.0 remote-as 109
address-family ipv6 !
exit-address-family address-family vpnv6
ipv6 unicast-routing neighbor 10.1.0.0 send-community extended
ipv6 cef exit-address-family
! !
interface Loopback0 address-family ipv6 vrf 6vpe
ip address 10.1.0.1 255.255.255.255 redistribute static
! exit-address-family
vrf forwarding 6vpe
ip address 10.1.1.1 255.55.255.0
ipv6 address 2001:DB8:1:1::1/64
!
interface Serial1/0
ip address 10.1.0.3 255.255.255.254
mpls ip
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
6VPE Lab: Configs
R# Configs
interface Loopback0 router bgp 109
R2 ip address 10.1.0.0 255.255.255.255 no bgp default ipv4-unicast
! neighbor 10.1.0.1 remote-as 109
interface Ethernet0/0 neighbor 10.1.0.1 update-source Loopback0
ip address 10.1.0.4 255.255.255.254 neighbor 10.1.3.1 remote-as 109
mpls ip neighbor 10.1.3.1 update-source Loopback0
! !
interface Serial1/0 address-family vpnv6
ip address 10.1.0.2 255.255.255.254 neighbor 10.1.0.1 activate
mpls ip neighbor 10.1.0.1 route-reflection-client
router ospf 1 neighbor 10.1.3.1 route-reflection-client
nerwork 0.0.0.0 255.255.255.255 area 0
!
6VPE Lab: Configs
R# Configs
vrf definition 6vpe router bgp 109
R3 rd 1:1 bgp log-neighbor-changes
route-target export 1:1 no bgp default ipv4-unicast
route-target import 1:1 neighbor 10.1.0.0 remote-as 109
address-family ipv6 !
exit-address-family address-family vpnv6
ipv6 unicast-routing neighbor 10.1.0.0 send-community extended
ipv6 cef exit-address-family
! !
interface Loopback0 address-family ipv6 vrf 6vpe
ip address 10.1.3.1 255.255.255.255 neighbor 2001:DB8:1:2::5 remote-as 2
! neighbor 2001:DB8:1:2::5 activate
interface Ethernet0/0 exit-address-family
vrf forwarding 6vpe
ip address 10.1.1.2 255.255.255.0
ipv6 address 2001:DB8:1:2::3/64
!
ip address 10.1.0.5 255.255.255.254
mpls ip
!
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!
6VPE Lab: Configs
R# Configs
R4 ipv6 cef
!
ipv6 address 2001:DB8:1:1::4/64
!
!
ipv6 route ::/0 2001:DB8:1:1::1
6VPE Lab: Configs
R# Configs
ipv6 cef
!
interface Loopback0
ipv6 address 2001:DB8:1:5::3/128
!
ipv6 address 2001:DB8:1:2::5/64
!
router bgp 2
no bgp default ipv4-unicast
!
address-family ipv6
network 2001:DB8:1:5::3/128
exit-address-family
IPv6 Multicast Lab
IPv6 Multicast Lab Agenda
• IPv6 Multicast with static RP
• IPv6 Multicast with Embedded RP
IPv6 Multicast Lab Topology
IPv6 Multicast Instructions
• OSPFv2 is preconfigured on all the devices

• IPv4 multicast is preconfigured on all the devices with PIM
• R2 is RP for IPv6 multicast static RP lab and R1 is the RP for IPv6 multicast
Embedded RP lab
• OSPFv3 is enabled and preconfigured on all the devices
• All the devices are in area 0
Multicast Lab: IPv6 Multicast with static RP
• Enable IPv6 Multicast routing on R1, R2 and R3
• Configure static RP on R1, R2 and R3
• Configure MLD Join on “Receiver” for group FF1E::1 to simulate a receiver
R# Multicast configuration
R1 ipv6 multicast-routing
!
ipv6 pim rp-address 2001:db8:1::
!
!
Receiver interface Ethernet0/0
ipv6 mld join-group FF1E::1
• Verify that RP is properly configured with R2 loopback address
• Verify that MLD join has been received from R5 on R3
• Do we need to configure IGMP for IPv6 multicast?
R3 R3#sh ipv6 pim group-map ff1e::1
IP PIM Group Mapping Table
(* indicates group mappings being used)
FF00::/8*
SM, RP: 2001:DB8:1::
RPF: Et1/0,FE80::A8BB:CCFF:FE00:5200
Info source: Static
Uptime: 00:30:53, Groups: 1
R3#sh ipv6 mld groups

MLD Connected Group Membership
Group Address Interface Uptime Expires
FF1E::1 Ethernet0/0 00:28:50 00:03:22
R3#
• Verify that PIM neighbor relationships are up (R2).
• Verify that the PIM join has been received by the RP (R2).
• Why do we see tunnel4 as RPF interface?
R2 R2#sh ipv6 pim nei
PIM Neighbor Table
Mode: B - Bidir Capable, G - GenID Capable
Neighbor Address Interface Uptime Expires Mode DR pri
FE80::A8BB:CCFF:FE00:5301 Ethernet0/0 00:36:36 00:01:38 B G DR 1

FE80::A8BB:CCFF:FE00:5100 Serial1/0 00:36:48 00:01:33 B G 1
R2#sh ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
…
(*, FF1E::1), 00:38:08/00:02:39, RP 2001:DB8:1::, flags: S
Incoming interface: Tunnel4
RPF nbr: 2001:DB8:1::
Immediate Outgoing interface list:
Ethernet0/0, Forward, 00:38:08/00:02:39
• Ping multicast address FF1E::1 from R4 and verify echo replies are received on R5
• Verify that R3 has a (S,G) entry with an incoming interface towards R1 (first hop router)
R3 R3#sh ipv6 mroute
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State
…
(2001:DB8:1:1::4, FF1E::1), 00:00:03/00:03:28, flags: SJT
Incoming interface: Serial2/0
RPF nbr: FE80::A8BB:CCFF:FE00:5100
Inherited Outgoing interface list:
Ethernet0/0, Forward, 00:41:26/never
R3#
(Answers)
• IGMP has been replaced with MLD in IPv6 multicast. MLDv2 is required for SSM support.
• As stated in RFC4601, Cisco IOS uses a tunnel interface for the PIM register process. On the
RP, this tunnel interface is used as the incoming interface for (*,G) entries, as encapsulated
multicast packets will be received on that interface.
Multicast Lab: IPv6 Multicast with Embedded RP
• Make R1 an RP.
• Add MLD Join on “Receiver” for group FF7E:130:2001:DB8:1::99 to simulate a receiver.
• Can you identify R1 loopback address in the embedded RP multicast address?
R1 ipv6 pim rp-address 2001:db8:1::1
Receiver interface Ethernet0/0

ipv6 mld join-group FF7E:130:2001:DB8:1::99
• Verify that group is seen as embedded RP group.
• Verify that PIM join is sent towards embedded RP (R1).
R3 R3#sh ipv6 pim group-map FF7E:130:2001:DB8:1::99
IP PIM Group Mapping Table
(* indicates group mappings being used)
FF7E:130:2001:DB8:1::/80*
SM, RP: 2001:DB8:1::1
RPF: Se2/0,FE80::A8BB:CCFF:FE00:5100
Info source: Embedded
Uptime: 00:11:31, Groups: 1
R3#sh ipv6 mroute FF7E:130:2001:DB8:1::99
..
(*, FF7E:130:2001:DB8:1::99), 00:09:35/never, RP 2001:DB8:1::1, flags: SCJ
Incoming interface: Serial2/0
RPF nbr: FE80::A8BB:CCFF:FE00:5100
Ethernet0/0, Forward, 00:09:35/never
R3#
• Verify that RP (R1) has received the PIM join coming from R3
• Why do we see tunnel3 as RPF interface?
R1 R1#sh ipv6 mroute ff7e:130:2001:db8:1::99
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State
(*, FF7E:130:2001:DB8:1::99), 00:16:13/00:03:26, RP 2001:DB8:1::1, flags: S

RPF nbr: 2001:DB8:1::1
Serial2/0, Forward, 00:16:13/00:03:26
R1#
• Ping multicast address FF7E:130:2001:DB8:1::99 from R4 and verify echo replies are
received on R5
• Verify that R1 has a (S,G) entry for R4
R1 R1#sh ipv6 mroute FF7E:130:2001:DB8:1::99
..
(*, FF7E:130:2001:DB8:1::99), 00:20:43/00:02:56, RP 2001:DB8:1::1, flags: S
RPF nbr: 2001:DB8:1::1
Serial2/0, Forward, 00:20:43/00:02:56
(2001:DB8:1:1::4, FF7E:130:2001:DB8:1::99), 00:00:02/00:03:27, flags: SFT

Incoming interface: Ethernet0/0
RPF nbr: 2001:DB8:1:1::4
Serial2/0, Forward, 00:00:02/00:03:27
R1#
(Answers)
• FF7E:130:2001:DB8:1::99. The first 48 bits of the RP address (2001:db8:1::/48) can be

identified after 0x30. The value of 1 preceding 0x30 represents the last 4 bits of the RP
address. 0x30 (48 in decimal) is the actual length we use to retrieve the RP address.
• As stated in RFC4601, Cisco IOS uses a tunnel interface for the PIM register process. On the
RP, this tunnel interface is used as the incoming interface for (*,G) entries, as encapsulated
multicast packets will be received on that interface.
IPv6 Multicast Lab
Key
Multicast Lab: Configs
R# Configs
ipv6 unicast-routing !
R1 ipv6 cef ! For static RP exercise
ipv6 multicast-routing !
! ipv6 pim rp-address 2001:db8:1:: (R2 Loopback address)
interface Loopback0 !
ipv6 address 2001:DB8:1::1/128 ! For embedded RP exercise (local loopback address)
ipv6 ospf 1 area 0 !
! ipv6 pim rp-address 2001:DB8:1::1
ipv6 address 2001:DB8:1:1::1/64 ipv6 router ospf 1
ipv6 ospf 1 area 0
!
interface Serial1/0
ipv6 ospf 1 area 0
!
interface Serial2/0
ipv6 address 2001:DB8::3/64
ipv6 ospf 1 area 0
R# Configs
ipv6 cef
ipv6 multicast-routing
!
interface Loopback0
ipv6 address 2001:DB8:1::/128
ipv6 ospf 1 area 0
!
ipv6 ospf 1 area 0
!
interface Serial1/0
ipv6 ospf 1 area 0
!
! For static RP exercise
!
ipv6 pim rp-address 2001:DB8:1::
ipv6 router ospf 1
R# Configs
R3 ipv6 cef
ipv6 multicast-routing
!
interface Loopback0
ipv6 address 2001:DB8:1:3::3/128
ipv6 ospf 1 area 0
!
ipv6 address 2001:DB8:1:2::3/64
ipv6 ospf 1 area 0
!
ipv6 ospf 1 area 0
!
interface Serial2/0
ipv6 address 2001:DB8::5/64
ipv6 ospf 1 area 0
!
ipv6 pim rp-address 2001:DB8:1::
ipv6 router ospf 1
R# Configs
no ipv6 cef
R4(Source) !
ipv6 address 2001:DB8:1:1::4/64
!
no ipv6 cef
R5(Receiver) !
ipv6 address 2001:DB8:1:2::5/64
ipv6 mld join-group FF05::1:1
ipv6 mld join-group FF7E:130:2001:DB8:1::99
!
Complete your
online session
survey • Please complete your session survey
after each session. Your feedback
is very important.
• Complete a minimum of 4 session
surveys and the Overall Conference
survey (starting on Thursday) to
receive your Cisco Live t-shirt.
• All surveys can be taken in the Cisco Events
Mobile App or by logging in to the Content
Catalog on ciscolive.com/emea.
Cisco Live sessions will be available for viewing on

demand after the event at ciscolive.com.
Continue your education
Demos in the Walk-in

Cisco campus self-paced labs
Meet the engineer

Related sessions
1:1 meetings
Thank you

CiscoLive 2020 Barcelona - Advanced IPv6 Routing and Services Lab

Uploaded by

Copyright:

Available Formats

CiscoLive 2020 Barcelona - Advanced IPv6 Routing and Services Lab

Uploaded by

Document Information

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

CiscoLive 2020 Barcelona - Advanced IPv6 Routing and Services Lab

Uploaded by

Copyright:

Available Formats

IPv6 Routing and Services

BRKIP6-2191 Tuesday BRKRST-2619 Wednesday BRKSEC-3200 Friday

IPv6 IPv6 Track

• Each lab has a clear topology diagram with addressing details

• All IPv6 addresses are pre-assigned.

• Lab keys are given at the end of each lab

• Configure OSPFv3 as follows:

• R1-R4 in area 1, change it to totally stubby NSSA area

• Redistribute static IPv6 routes into OSPFv3 on R4

redistribute static subnets redistribute static

• Forwarding address are optional in OSPFv3

• All other characteristics of externals are same as in OSPFv2

• OSPFv3 picks up RID using the exact algorithm used by OSPFv2

• It’s a 32 bit number in dotted decimal format

• Has nothing to do with IPv4 addressing

• 0.0.0.0 is reserved and can not be used as RID

R# LSA OSPFv2 OSPFv3

R3 Link LSA sh ipv6 ospf data link self

R4 inter-area router sh ipv6 ospf data prefix

• OSPFv3 has almost similar type of LSA’s as OSPFv2

• Two new LSA’s has been introduced (Link & prefix)

• Summary LSA is now called “Inter-area network”

• Summary ASBR is now called “inter-area router”

• Router LSA in OSPFv3 are no longer identified by LS ID

• Network LSA are no longer identified by LSID

• Forwarding Address field are optional in External LSAs

• Configure a virtual link between R2 & R3

• OSPFv3 has the exact same way of configuring a virtual link

• The router ID does not have to be known in the routing table

• Instance ID is a new field introduced in OSPFv3 packet

• An interface can be included in more than 1 OSPFv3 area through instance ID

• Summarize area 0 routes in area 2

summary-address 10.1.4.4 summary-prefix 2001:DB8:1:4::4/127

area 0 range 10.1.0.0 255.255.255.252 area 0 range 2001:DB8:1::/126

• Just like OSPFv2, routes can be summarized in OSPFv3

• OSPFv3 sends its hellos over link local address

• Single Topology ISIS

• ISISv4 is preconfigured in area 49.0001 & 49.0002

• Level 2 routing already established between R1 and R2 for IPv4

• Static routes for IPv4 are already redistributed into ISISv4

• Redistribute static IPv6 routes into ISISv6 on R4

redistribute static level-1

R1 R1#sh ip route | i 10.1.4.5 R1#sh ipv6 route | i 2001:DB8:1:4::5

i L1 10.1.4.5/32 [115/10] via 10.1.1.4, 00:41:07, I1 2001:DB8:1:4::5/128 [115/10]

• To redistribute a route in ISISv6, you have to go under address-family ipv6

• In ISISv6, TLV 236 represents both Internal and external prefixes

• External prefixes are marked by setting an X bit in TLV 236

• All IPv6 prefix summarization needs to be done under address-family ipv6

• Summary-address has been changed to summary-prefix

• Enable ISISv6 over tunnel0

ipv6 router isis

sh isis neighbor | incl Tu0

ipv6 router isis

sh isis neighbor | incl Tu0

• ISISv6 can not run on ipv6 over ip tunnel

• Enable ISISv6 over E0/0 of R5 & R2 and S1/0 of R2

ipv6 router isis

ipv6 router isis

• Enable multi topology isis on R2

R3 L1 Et0/0 10.1.0.5 UP 9 R3.01