Archive
IPv6 operation and best practices – documents to read
Unfortunately I don’t get to do much v6 at my job yet but I still like to stay updated on
what is happening. Do you run any v6 in your network? If so, do you run it native or tunneled
or something like 6PE?
Here are some interesting sources for operation of v6.
draft-matthews-v6ops-design-guidelines-01
This document discusses if IPv4 and IPv6 traffic
should be mixed on the same interface or should different interfaces be used? Should
link local or global addressing be used for routing? Should v6 routes be transferred
over v4 in BGP sessions?
draft-ietf-v6ops-enterprise-incremental-ipv6-01
This document is for deploying v6 in an enterprise network. Things like security policy,
addressing plan and IPv6 myths are brought up.
This document is purely about the advantages and disadvantages of only running link local
addresses.
Also, don’t miss out on information that is freely available at Cisco Live. Here are
some interesting sessions on IPv6 from Melbourne.
BRKRST-2301 – Enterprise IPv6 Deployment (2013 Melbourne)
BRKRST-1069 – Understanding IPv6 (2013 Melbourne)
ITMGEN-1313 – Preparing for IPv6 in the Enterprise (2013 Melbourne)
BRKRST-2311 – IPv6 Planning, Deployment and Troubleshooting (2013 Melbourne)
BRKSEC-2003 – IPv6 Security Threats and Mitigations (2013 Melbourne)
COCRST-2464 – Inside Cisco IT: Making The Leap To IPv6 (2013 Melbourne)
As you can see. IPv6 is a pretty big deal these days at Cisco Live. Then you also have
books, configuration guides etc but this should give you a good start to see what challenges
and considerations you should have when deploying IPv6.
Frame-relay IPv6 speed drill
Going for the lab we need both speed and skills. I made a simple IPv6 frame-relay lab that should test your speed. Time yourself and post your time to configure in the comments. Just by looking at the time I could probably tell if you are typing manually or not. This is the scenario.
Routers R1, R2, R3 and R4 are connected to a frame-relay cloud. They are all spokes connecting to the hub R5. R1 has a DLCI 105 to R5 which is 501 from R5 POV. R2 has a DLCI that is 205 and 502 from R5 POV and so on. This is the task.
Configure all devices with a global address of 2001:1:0:1234::Y where Y is the device number.
Configure static mappings on all devices.
All devices should be able to ping each other.
Download the .net from here and then edit for your IOS version and working dir etc.
I didn’t time myself but I think I could do it in less than 2 minutes for sure. Later I will post some tips on how to improve speed.
IPv6 over frame relay
This post will look at IPv6 over frame-relay and describe some of the small things
that differ compared to IPv4 and some gotchas.
We start out with the same topology as in my previous frame-relay post.
We configure routers R1, R2 and R3 to be in the subnet 2001:CC1E:1:1::/64.
Remember that the pool of global IPv6 unicast addresses comes from 2000::/3
which means that all today legit IPv6 addresses will start with a 2 or a 3.
R1
interface Serial0/0
encapsulation frame-relay
ipv6 address 2001:CC1E:1:1::1/64
frame-relay map ipv6 2001:CC1E:1:1::2 102
frame-relay map ipv6 2001:CC1E:1:1::3 103
I won’t say much about this config as this should be known to you if you read
my previous post on frame relay. We are using a physical interface so all DLCI’s
will be available to us. The first thing to notice about IPv6 over frame relay is that
there is no inverse ARP. This means that we need static mappings or the
frame-relay interface-dlci command on point-to-point interfaces.
We configure R2 and to mix things up a bit we use a point-to-point interface.
interface Serial0/0
encapsulation frame-relay
frame-relay interface-dlci 201
Since this is a point-to-point interface there is no need for static mappings.
R3 will use a multipoint interface but not the physical interface. We will use a
static mapping.
interface Serial0/0
encapsulation frame-relay
interface Serial0/0.301 multipoint
ipv6 add 2001:CC1E:1:1::3/64
frame-relay map ipv6 2001:CC1E:1:1::1 301
When we use IPv6 we always have a link-local address assigned to all IPv6 enbabled
interfaces. This can be seen with the show ipv6 interface brief command.
R1#sh ipv6 int brief
FastEthernet0/0 [administratively down/down]
Serial0/0 [up/up]
FE80::C001:8FF:FEE0:0
2001:CC1E:1:1::1
The link-local address is calculated based on the MAC address.
R1#sh int | i bia
Hardware is Gt96k FE, address is c201.08e0.0000 (bia c201.08e0.0000)
Hardware is Gt96k FE, address is c201.08e0.0001 (bia c201.08e0.0001)
Our link-local address is based on the first MAC of this output. We want to use
an easier to remember address so we set the link local address to FE80::1 and
then the same on R2 and R3 but with ::2 and ::3.
R1(config)#int s0/0
R1(config-if)#ipv6 add FE80::1 link-local
Now it is time to do some routing. We start out with BGP. Knowing BGP is of
course a must when you are studying for the CCIE and the difference between
IPv4 and IPv6 is not that great. We need networks to announce so we create
some loopbacks on the routers.
R1
R1(config-if)#int lo0
R1(config-if)#ipv6 add 2001:CC1E:10:1::1/64
R2
R1(config-if)#int lo0
R1(config-if)#ipv6 add 2001:CC1E:11:1::2/64
R3
R1(config-if)#int lo0
R1(config-if)#ipv6 add 2001:CC1E:12:1::3/64
Don’t you just love being able to have IP addresses with CCIE in them?
Time to setup BGP. We will be using AS 100 for R1 and R2. R3 will be in AS 300.
R1
R1(config)#ipv6 unicast-routing
R1(config)#router bgp 100
R1(config-router)#nei 2001:CC1E:1:1::2 remote-as 100
R1(config-router)#address-family ipv6 unicast
R1(config-router-af)#neighbor 2001:CC1E:1:1::2 activate
R1(config-router-af)#network 2001:CC1E:10:1::/64
R1(config-router-af)#exit
R1(config-router)#bgp router-id 1.1.1.1
Notice that we need to set a router-ID because we have no IPv6 addresses
configured on the routers.
R2
R2(config)#ipv6 unicast-routing
R2(config)#router bgp 100
R2(config-router)#bgp router-id 2.2.2.2
R2(config-router)#nei 2001:CC1E:1:1::1 remote-as 100
R2(config-router)#address-family ipv6 unicast
R2(config-router-af)#nei 2001:CC1E:1:1::1 activate
R2(config-router-af)#network 2001:CC1E:11:1::/64
The session comes up and we receive one prefix.
*Mar 1 10:12:46.853: %BGP-5-ADJCHANGE: neighbor 2001:CC1E:1:1::2 Up
R1#sh bgp ipv6 uni sum
BGP router identifier 1.1.1.1, local AS number 100
BGP table version is 3, main routing table version 3
2 network entries using 304 bytes of memory
2 path entries using 152 bytes of memory
3/2 BGP path/bestpath attribute entries using 372 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 1) using 32 bytes of memory
BGP using 860 total bytes of memory
BGP activity 3/1 prefixes, 3/1 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2001:CC1E:1:1::2
4 100 8 8 3 0 0 00:04:03 1
Lets see if we have reachability.
R1#sh ipv6 route 2001:CC1E:11:1::/64
IPv6 Routing Table – 6 entries
Codes: C – Connected, L – Local, S – Static, R – RIP, B – BGP
U – Per-user Static route, M – MIPv6
I1 – ISIS L1, I2 – ISIS L2, IA – ISIS interarea, IS – ISIS summary
O – OSPF intra, OI – OSPF inter, OE1 – OSPF ext 1, OE2 – OSPF ext 2
ON1 – OSPF NSSA ext 1, ON2 – OSPF NSSA ext 2
D – EIGRP, EX – EIGRP external
B 2001:CC1E:11:1::/64 [200/0]
via 2001:CC1E:1:1::2
R1#ping 2001:CC1E:11:1::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:CC1E:11:1::2, timeout is 2 seconds:
!!!!!
Indeed we do, now lets setup peering between R1 and R3.
R1
R1(config-router)#nei 2001:CC1E:1:1::3 remote-as 300
R1(config-router)#address-family ipv6 unicast
R1(config-router-af)#nei 2001:CC1E:1:1::3 activate
R3
R3(config-router)#nei 2001:CC1E:1:1::1 remote-as 100
R3(config-router)#address-family ipv6 unicast
R3(config-router-af)#nei 2001:CC1E:1:1::1 activate
Now lets look at the BGP table on R1.
R1#sh bgp ipv6 uni
BGP table version is 12, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
*> 2001:CC1E:10:1::/64
:: 0 32768 i
*>i2001:CC1E:11:1::/64
2001:CC1E:1:1::2
0 100 0 i
*> 2001:CC1E:12:1::/64
2001:CC1E:1:1::3
0 0 300 i
We can see R3′s loopback, nothing weird, yet…We have a next-hop of
2001:CC1E:1:1::3 which is expected. Now look at the show ipv6 route bgp
output.
R1#sh ipv6 route bgp
IPv6 Routing Table – 7 entries
Codes: C – Connected, L – Local, S – Static, R – RIP, B – BGP
U – Per-user Static route, M – MIPv6
I1 – ISIS L1, I2 – ISIS L2, IA – ISIS interarea, IS – ISIS summary
O – OSPF intra, OI – OSPF inter, OE1 – OSPF ext 1, OE2 – OSPF ext 2
ON1 – OSPF NSSA ext 1, ON2 – OSPF NSSA ext 2
D – EIGRP, EX – EIGRP external
B 2001:CC1E:11:1::/64 [200/0]
via 2001:CC1E:1:1::2
B 2001:CC1E:12:1::/64 [20/0]
via FE80::3, Serial0/0
The route to 2001:CC1E:12:1::/64 has been resolved to a next-hop of FE80::3.
Do we have reachability to this network?
R1#ping 2001:CC1E:12:1::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:CC1E:12:1::3, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
No, we don’t. We don’t have a mapping for the link-local address. Debug frame-relay
packet should confirm this.
R1#debug frame-relay packet
Frame Relay packet debugging is on
R1#ping 2001:CC1E:12:1::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:CC1E:12:1::3, timeout is 2 seconds:
*Mar 1 00:35:52.759: Serial0/0:Encaps failed–no map entry link 79(IPV6).
*Mar 1 00:35:54.767: Serial0/0:Encaps failed–no map entry link 79(IPV6).
*Mar 1 00:35:56.767: Serial0/0:Encaps failed–no map entry link 79(IPV6).
*Mar 1 00:35:58.771: Serial0/0:Encaps failed–no map entry link 79(IPV6).
*Mar 1 00:36:00.775: Serial0/0:Encaps failed–no map entry link 79(IPV6).
Success rate is 0 percent (0/5)
Indeed, there is no mapping. Lets configure this.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int s0/0
R1(config-if)#frame-relay map ipv6 FE80::3 103
R1(config-if)#^Z
R1#ping 2001:CC1E:12:1::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:CC1E:12:1::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/37/88 ms
R1#
Success, but the question still is why do we have a link-local next-hop for
R3′s loopback interface? RFC 2545 – Use of BGP-4 Multiprotocol extensions
for IPv6 Inter-Domain Routing gives us a hint.
A BGP speaker shall advertise to its peer in the Network Address of
Next Hop field the global IPv6 address of the next hop, potentially
followed by the link-local IPv6 address of the next hop.
We must announce the global next-hop and potentially a link-local one.
The link-local address shall be included in the Next Hop field if and
only if the BGP speaker shares a common subnet with the entity
identified by the global IPv6 address carried in the Network Address
of Next Hop field and the peer the route is being advertised to.
If the BGP peers share a common subnet the link-local address shall be included.
Why doesn’t the route to R2′s loopback have a link-local next-hop?
Once again, RFC 2545 gives us the answer.
As a consequence, a BGP speaker that advertises a route to an
internal peer may modify the Network Address of Next Hop field by
removing the link-local IPv6 address of the next hop.
If announcing to an internal peer, we may modify the next-hop by removing the
link-local address. R1 and R2 are in the same AS so they are internal peers.
Now we have seen how BGP works, what about IGPs? Lets try to configure
OSPF between R1 and R2.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int s0/0
R1(config-if)#ipv6 ospf 1 area 0
R1(config)#ipv6 router ospf 1
R1(config-rtr)#router-id 1.1.1.1
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int s0/0.201
R2(config-subif)#ipv6 ospf 1 area 0
R2(config-subif)#exit
R2(config)#ipv6 router ospf 1
R2(config-rtr)#router-id 2.2.2.2
The peering won’t be successful, why? We turn off the route-cache and debug IPv6 packets.
R1(config)#int s0/0
R1(config-if)#no ip route-cache
R1(config-if)#^Z
R1#debug ipv6 packet
IPv6 unicast packet debugging is on
R1#
*Mar 1 08:59:20.181: IPV6: source FE80::2 (Serial0/0)
*Mar 1 08:59:20.185: dest FF02::5
*Mar 1 08:59:20.185: traffic class 224, flow 0×0, len 76+4, prot 89, hops 1, forward to ulp
Let’s try a ping to FF02::5 which is the destination address of IPv6 OSPF packets.
R1#ping FF02::5
Output Interface: Serial0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FF02::5, timeout is 2 seconds:
Packet sent with a source address of FE80::1
Request 0 timed out
Request 1 timed out
Request 2 timed out
Request 3 timed out
Request 4 timed out
Success rate is 0 percent (0/5)
0 multicast replies and 0 errors.
No success, we can see that the packets are source from FE80::2 which must
be mapped. Also, we must have broadcast capability on one PVC, does it matter
which one? This is output from debug frame-relay packet when doing a ping to FF02::5
R1#debug frame-relay packet
Frame Relay packet debugging is on
R1#ping FF02::5
Output Interface:
*Mar 1 09:04:41.549: Serial0/0(i): dlci 102(0×1861), pkt type 0x86DD, datagramsize 80Serial0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FF02::5, timeout is 2 seconds:
Packet sent with a source address of FE80::1
*Mar 1 09:04:45.349: Serial0/0: broadcast search
*Mar 1 09:04:45.353: Serial0/0:encaps failed on broadcast for link 79(IPV6)
Request 0 timed out
This shows us clearly that we have no broadcast capability. Lets look at what
frame-relay mappings we have, R2 is point-to-point only so no need for mappings there.
R1#sh run | i frame-relay map
frame-relay map ipv6 FE80::3 103
frame-relay map ipv6 2001:CC1E:1:1::3 103
frame-relay map ipv6 2001:CC1E:1:1::2 102
We don’t have a mapping for R2′s link-local address. We will need that and we
will also need broadcast capability for the PVC. To prove that we can add the
brodcast capability by configuring a map for the global address I will configure that.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int s0/0
R1(config-if)#frame-relay map ipv6 FE80::2 102
R1(config-if)#frame-relay map ipv6 2001:CC1E:1:1::2 102 broad
Can we ping FF02::5 now?
R1#ping FF02::5
Output Interface: Serial0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FF02::5, timeout is 2 seconds:
Packet sent with a source address of FE80::1
Reply to request 0 received from FE80::2, 40 ms
Reply to request 1 received from FE80::2, 52 ms
Reply to request 2 received from FE80::2, 96 ms
Reply to request 3 received from FE80::2, 40 ms
Reply to request 4 received from FE80::2, 128 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/71/128 ms
5 multicast replies and 0 errors.
Looking much better now. However, there is still no OSPF peering, why?
R1#sh ipv6 ospf interface
Serial0/0 is up, line protocol is up
Link Local Address FE80::1, Interface ID 6
Area 0, Process ID 1, Instance ID 0, Router ID 1.1.1.1
Network Type NON_BROADCAST, Cost: 64
R2#sh ipv6 ospf int
Serial0/0.201 is up, line protocol is up
Link Local Address FE80::2, Interface ID 14
Area 0, Process ID 1, Instance ID 0, Router ID 2.2.2.2
Network Type POINT_TO_POINT, Cost: 64
We have a mismatch in the network types. We will set both sides to broadcast.
R1(config)#int s0/0
R1(config-if)#ipv6 ospf network broadcast
R2(config)#int s0/0.201
R2(config-subif)#ipv6 ospf network broadcast
R2(config-subif)#
And finally we have a working peering.
*Mar 1 09:16:27.185: %OSPFv3-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Serial0/0.201 from LOADING to FULL, Loading Done
I hope this post has cleared some misconceptions about IPv6 over frame relay.
If you have any questions please post them in the comments section.
You can find the final configs for this lab here. You can find the topology for GNS3
in my earlier post on frame-relay.
IPv6 – notes
- Addresses are 128 bits long
- Separated with colons every 16 bits
- Address separated in prefix and interface id, most common is /64
- Leading zeroes can be omitted from address and double colon may be used to represent Successive zeroes, may only be used once
- Unicast, multicast and anycast, doesn’t use broadcast
Unicast
Currently addresses from 2000::/3 are being handed out (1/8 of total space)
Link-local
Only used on links (link-local), addresses from FE80::/10 span.
Interface addresses and routing
To enable routing use ipv6 unicast-routing
Enable IP addresses with ipv6 address and then the prefix with slash notation, note that
several IPv6 addresses can be present on an interface. Compare this to IPv4 where only one
address can be active and the other addresses are secondary.
Multicast
Multicast replaces broadcast in IPv6. Multicast addresses are always a destination, not a source. DHCP uses multicast instead of broadcast in IPv6. FF00::/8 is reserverd for multicast. Of the first 16 bits in a multicast address the first eight are always FF. The next four bits define the lifetime, where 0000 is permanent and 0001 is temporary. The four bits after that define the scope, these are the options:
0001 Node
0010 Link
0101 Site
1000 Organization
1110 Global
Well known multicast addresses
FF02::1 All hosts
FF02::2 All routers
FF02::5 OSPFv3 routers
FF02::6 OSPFv3 designated routers
FF02::A EIGRP routers
FF02::D PIM routers
Anycast
IP address that is used on multiple hosts/routers. Routing will decide which one is the closest and that one will reply. Anycast addresses should not be used as a source address. To define an interface as anycast, use the anycast keyword when configuring the IP address.
Unspecified address
The unspecified address is ::. This address is used as a source when the client hasn’t got
an address yet. May not be used as a destination.
Autoconfiguration
Autoconfiguration can be stateful or stateless. Statefull autoconfiguration uses DHCP
to provide the IP address. Stateless uses the local routers to tell the hosts what prefix
to used. The hosts can then append a 64 bit interface identifer through EUI-64 or other means.
EUI-64
Used to derive an interface ID. With Ethernet this is based on the MAC-address. The MAC address is 48 bits long and the interface ID is 64 bits long which means padding has to be done. The prefix FFFE is inserted in the middle of the MAC address. Also, the U/L bit (bit seven) has to be set to one to indicated that this is a locally administered address.
Neighbor discovery
Functions of neighbor discovery
- Stateless autoconfiguration
- Duplicate address detection (DAD)
- Router discovery
- Prefix discovery
- Neighbor discovery
- Neighbor address resolution (replaces ARP)
Types of ND messages
Router advertisements (RA) – Sent by routers to announce their presence, sent to FF02::1 (all hosts).
Router solicitation (RS) – Hosts query for routers on local link. Sent to FF02::2 (all routers).
Neighbor solicitation (NS) – Hosts query for other nodes link layer addresses. Used for DAD
and to verify neighbor reachability.
Neighbor advertisement (NA) – Sent in response to NS messages and also sent periodically to provide information to neighbors.
Redirect – Sent to inform host of better next-hop routers.
To find out the link-layer address of a host NS is used. The message is sent to the other nodes solicited multicast address.
Router advertisements are sent very 200 seconds by default. To suppress them use the ipv6 nd suppress-ra command.
When hosts boot they can send a RS to find a router instead of waiting for the next RA coming in (could take up to 200 seconds).
Hosts sends NS message to solicited node multicast address of local IP to ensure that the IP is unique which it should be if assigned through EUI-64. The message is sent with the unspecified :: address as a source. There should be no reply unless there is a IP address conflict.
IPv6 access lists
At the end there is an implicit permit for ND traffic or else it would not be possible to resolve layer two addresses. To override this behaviour deny statements are needed. The command syntax is ipv6 traffic-filter instead of access-group.
