Web Cache Communication Protocol (WCCP)

A customer implemented a transparant Cisco WSA (Ironport) for the redirection of the http and https traffic. WCCP had to be configured on their Cisco 3750 switch with IOS releas 12.2(55)SE9.
First some background info on WCCP:

The Cisco IOS WCCP feature allows utilization of Cisco Cache Engines (or other caches running WCCP) to localize web traffic patterns in the network, enabling content requests to be fulfilled locally. Traffic localization reduces transmission costs and download time.
WCCP enables Cisco IOS routing platforms to transparently redirect content requests. The main benefit of transparent redirection is that users need not configure their browsers to use a web proxy. Instead, they can use the target URL to request content, and have their requests automatically redirected to a cache engine. The word “transparent” is this case means that the end user does not know that a requested file (such as a web page) came from the cache engine instead of from the originally specified server.
When a cache engine receives a request, it attempts to service it from its own local cache. If the requested information is not present, the cache engine issues its own request to the originally targeted server to get the required information. When the cache engine retrieves the requested information, it forwards it to the requesting client and caches it to fulfill future requests, thus maximizing download performance and substantially reducing transmission costs.
WCCP enables a series of cache engines, called a cache engine cluster, to provide content to a router or multiple routers. Network administrators can easily scale their cache engines to handle heavy traffic loads through these clustering capabilities. Cisco clustering technology enables each cache member to work in parallel, resulting in linear scalability. Clustering cache engines greatly improves the scalability, redundancy, and availability of your caching solution. You can cluster up to 32 cache engines to scale to your desired capacity.

I took the above text from the Cisco website, so if you want to read more on the theory behind WCCP check out: http://www.cisco.com/c/en/us/td/docs/ios/12_2/configfun/configuration/guide/ffun_c/fcf018.html

To configure WCCP on a Cisco 3750 there are some constraints:

  • Make sure SDM prefer is on an routing image
  • Forwarding can only be L2 (in the WSA this is default GRE or L2, configure it hard on L2 only)
  • Assignement method can only be MASK (in the WSA this is default HASH or MASK, configure it hard on MASK only)
  • Make sure clients and WSA are on different vlan’s
  • Forwarding redirect list can only understand PERMIT statements
  • When usig a dynamic WCCP identifier configure in the WSA the ports that have to be redirected, in this example it has to be 80(http) and 443(https)

Configuration will look like below:
First configure the routed vlan’s
!
vlan 100
name WSA
!
vlan 200
name Clients
!
int vlan 100
ip address 10.10.10.254 255.255.255.0
no shut
!
int vlan 200
ip address 172.18.10.254 255.255.255.0
no shut
!

Then configure the access-lists to “catch” the client traffic that has to be redirected:
!
ip access-list extended 100
permit tcp 172.18.10.0 0.0.0.255 any eq www
permit tcp 172.18.10.0 0.0.0.255 any eq 443
!
I used a numbered ACL, so I can debug it. A named list can’t be debugged! Make the ACL as specific as possible!

Then create an ACL for the redirect-list. This ACL consists of the WSA addresses.
!
access-list 10 permit 10.10.10.1
access-list 10 permit 10.10.10.2
!

The actual WCCP configuration consist out of two command.
A global command:
!
ip wccp 100 redirect-list 10
!

And a command on the client vlan interface:
!
int vlan 200
ip wccp 100 redirect in
!

There isn’t more to it. To check if WCCP is functioning use the “show ip wccp 100 [detail|view]” command.
To check a little deeper, use the “debug ip wccp packets” command. If you see the “WCCP2_HERE_I_AM” and “WCCP2_I_SEE_YOU” packets than the WCCP mechanism is functioning.
Even if WCCP functions it’s possible traffic does not get redirected. This can be due to a dozen of problems. First step is to check if the client traffic is redirect at all. This can be done by using the “debug ip packet detail 100” command. If no traffic hits the ACL, traffic won’t be redirected to the WSA.

Advertisements

VSS on Cisco 4500-X

For a customer I recently configured two Cisco 4500-x switches with VSS (Virtual Switching System). VSS makes two 4500-x switches to function as one logical switch. By configuring VSS on botch switches, there is one active RP (Route Processor) and one hot standby RP. When the active RP fails, the hot standby RP will take over operations without the loss of data.

The VSS switches are connected by an VSL (Virtual Switch Link), which is normally build as an etherchannel. The VSL serves as logical connection that carries critical system control information such as hot-standby supervisor programming, line card status, Distributed Forwarding Card (DFC) card programming, system management, diagnostics, and more. In addition, VSL is also capable of carrying user data traffic when necessary.

By using VSS it’s possible to uplink a switch with two uplinks in an etherchannel.This is called a MEC (Multichassis Etherchannel). Because you connect the uplinks to two switches functioning as one, there is no need for spanning-tree to block one of the links. So instead of two uplinks with one blocked by spanning-tree, there are two active links which makes it possible to use a 2 x 1/10/40Gb etherchannel as uplink.

To prevent both switches from becoming active, there is a mechanism called “Dual active detection” or VSLP (Virtual Switch Link Protocol). Two modes are available, PagP and Fast-hello. In the following configuration example, I’ll give an example of VSS with “Fast-hello” dual active detection.

The picture below depicts the written above:
VSS

Now let’s take a look at the configuration:

First configure the switches seperatly
Switch1
!
conf t
!
switch virtual domain 100
switch 1
switch 1 priority 110
mac-address use-virtual
!
int pox
switchport
swi virtual link 1
no shutdown
!
int range tx/x/x – x
channel-group 101 mode on
no shut
!
switch set switch_num 1 local
switch read switch_num 1 local
!
end
!
wr
!

Switch2
!
conf t
!
switch virtual domain 100
switch 2
switch 2 priority 90
mac-address use-virtual
!
int poxx
switchport
sw virtual link 2
no shutdown
!
int range tx/x/x – x
no switchport nonegotiate
channel-group x mode on
no shutdown
!
end
!
switch set switch_num 2 local
switch read switch_num 2 local
!
wr
!

After this give the following command on both switches to convert them to VSS mode:
!
switch convert mode virtual
!

After rebooting the Fast-hello dual active detection can be configured.
Switch1
!
conf t
!
switch vitrual domain 100
dual-active detection fast-hello
!
int tx/x/x
dual-active fast-hello
no shut
!
end
!
wr
!

Switch2
!

conf t
!
switch virtual domain 100
dual-active detection fast-hello
!
!
int tx/x/x
dual-active fast-hello
no shut
!
end
!
wr
!

Make sure u use an IOS XE version higher than:  cat4500euniversal.SPA.03.04.03.SG.151-2.SG3.bin
The IOS XE version above supports only PagP dual active detection!

To be fully complete in the IOS XE version mentioned earlier is a bug. If you try to configure the Fast Ethernet ports for management, the won’t work. It’s possible to configure a IP address and so one. The “show ip int brie” commando will even say the interface is up, but it’s just not possible to ping the interface.
After an IOS upgrade everthing came to life and functioned as intended.

 

Protect your network against HSRP attacks!

As in my earlier post, I’m writing a series of postings to help protect your network against attacks. A good hacker will always find a way to hurt your network. But with the recommendations described in this series of postings it will be more difficult for the hacker to find a way in.

In this post I will describe the hacking of HSRP operations and off course I will describe a solution to this problem.

As always I use GNS3. Below the topology and the configuration of multilayer switch R2.
topology

R2
!
interface FastEthernet0/0
switchport mode trunk
!
interface FastEthernet0/5
switchport access vlan 13
no cdp enable
!
interface Vlan10
ip address 10.0.0.253 255.255.255.0
standby 10 ip 10.0.0.254
!
interface Vlan11
ip address 172.18.100.253 255.255.255.0
standby 11 ip 172.18.100.254
!
interface Vlan12
ip address 192.168.157.253 255.255.255.0
standby 12 ip 192.168.157.254
!
interface Vlan13
ip address 192.168.80.253 255.255.255.0
standby 13 ip 192.168.80.254
!

HSRP
The cisco.com website explains HSRP as follows:

“HSRP is Cisco’s standard method of providing high network availability by providing first-hop redundancy for IP hosts on an IEEE 802 LAN configured with a default gateway IP address. HSRP routes IP traffic without relying on the availability of any single router. It enables a set of router interfaces to work together to present the appearance of a single virtual router or default gateway to the hosts on a LAN. When HSRP is configured on a network or segment, it provides a virtual Media Access Control (MAC) address and an IP address that is shared among a group of configured routers. HSRP allows two or more HSRP-configured routers to use the MAC address and IP network address of a virtual router. The virtual router does not exist; it represents the common target for routers that are configured to provide backup to each other. One of the routers is selected to be the active router and another to be the standby router, which assumes control of the group MAC address and IP address should the designated active router fail.”

So in short, HSRP provides a virtual default gateway. And that’s the problem, when someone or something finds a way to hack into the HSRP operations it is possible to change the default gateway and reroute networktraffic or blackhole the networktraffic. This turns out to be very simple with Kali. Below a simple explanation how to change the behaviour of HSRP operations.

Start Kali, start yersinia, click the HSRP tab, choose to become active router, give in an ip address and that’s al there is:
hsrp_att

hsrp ip

 

When you have enable terminal monitor on your switch, you’ll see a state change
state change
Now check the HSRP settings with “show standby vlan 13” and you’ll see that the gateway has changed to 10.10.10.10
sh stand vlan 13

When you look closer to the config you’ll notice something else:
config change
For Yersinia to be able to take over the HSRP operations, it alters the config by entering a static entry to the mac address table!

Again this al there is to! To prevent this, make sure u use authetication on your HSRP interfaces as described in the following example:

First create a key-chain
key chain

 

Then configure the authentication on the vlan interface. If your are in a production network. First configure the standby unit, then the active unit. Otherwise the actions are disruptive!

 

stand auth

Now try the HSRP attack again and you’ll see it will not work this time!
stand vlan 13 auth

 

And to make it even more clear, when terminal monitor is enabled you’ll get the message depicted in the picture below
bad auth

 

 

 

Protect your network against CDP attacks!

As a network consultant/engineer you should be aware of network security risks. Today it is fairly simple to take down a network with the use of Kali Linux. There, it has been said: Kali Linux. This Linux distro is a hackers dream. It has all the necessary tools on board to damage a network very very hard! A hacker only needs a free outlet that is patched to a switch. Within minutes a company can be down on it’s knees!

First of all I’m writing this series of postings to point out the need for security on the network layer, not to make a hackers life easy! In this post I will describe how to use Kali Linux, but more important are the security solutions I give to prevent attacks on your network. This post will be about protecting your network against CDP attacks.

How do I test Kali, you probably guest it already when you read my earlier posts, I use GNS3 for it. Below the topology I use for testing.
topology

R1 and R2 are configured as two multilayer switches, with several (routed) vlan’s. For reference below the config of R1.

R1
!
interface FastEthernet0/0
description Trunk to R2
switchport mode trunk
!
!
interface FastEthernet0/4
switchport access vlan 11

!
!
interface Vlan10
ip address 10.0.0.252 255.255.255.0
standby 10 ip 10.0.0.254
!
interface Vlan11
ip address 172.18.100.252 255.255.255.0
standby 11 ip 172.18.100.254
!
interface Vlan12
ip address 192.168.157.252 255.255.255.0
standby 12 ip 192.168.157.254
!
interface Vlan13
ip address 192.168.80.252 255.255.255.0
standby 13 ip 192.168.80.254
!

CDP Flooding
CDP (Cisco Discovery Protocol) is a great tool when you have to make documentation of a network and most cases CDP is globally enabled on every switch en every switchport on the network. Great, but then a any given moment you check the cdp status on your switch and see this:

cdp_flood

and this:
proc_cpu

As you can see the cdp table is flooded with bogus entry’s and because of the ongoing stream of bogus cdp packets, the cpu spikes to 100%. It’s just a matter of time before the switch will reboot. Problem is, when the switch is rebooted it will be just the same because the stream of cdp packets just keeps going on.

How is this possible you think, well it’s really easy. Install Kali Linux, start the Yersinia program and click attack. Is it that easy I hear you think? Yes it’s that easy! Check it out:

Start Kali Linux:
kali

Start Yersinia
start yersinia

Click the cdp tab, click Launch Attack, choose “flooding CDP table” and click “OK”.
start attack

 

That’s it, your cdp table will be flood with bogus cdp packets. Now check your switch with the “show cdp table”, “show cdp traffic” and “show proc cpu sorted” command:
cdp_flood

proc_cpu

cdp traffic

Within two minutes my switch crashed and rebooted, so this is a real threat to the stability of your network.
To prevent this kind of attacks a couple of things can be done:

First of all, place switchports that are not in use in a dummy vlan and give them an admin down
Second, disable cdp on switchports that don’t need it. For example access ports that only contain a computer or a IP phone which don’t need the CDP protocol to function!
Third, ports that can’t be disabled, configure Port Security on them!

 

 

Multicast Routing with PIM-SM

To get a better understanding of Multicast PIM-SM routing I created a case study. In the picture below the GNS3 topology I used.

topology

I used EIGRP between the routers for full unicast connectivity. On all te routers I configured “IP multicast-routing” and on the connected interfaces I configured the “ip pim sparse-mode”. R3 serves as a Rendevouz Point (RP) and R4 serves as the Mapping Agent (MA).

First configure the full unicast connectivity. I will show one sample, the other routers are pretty straight forward.

R1
!
interface FastEthernet1/0
ip address 10.0.0.5 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet2/0
ip address 10.0.0.1 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet3/0
ip address 172.18.100.254 255.255.255.0
duplex auto
speed auto
!
router eigrp 10
network 1.1.1.1 0.0.0.0
network 10.0.0.0 0.0.0.3
network 10.0.0.4 0.0.0.3
network 172.18.100.0 0.0.0.255
no auto-summary
eigrp router-id 1.1.1.1
!

Make sure there is full unicast connectivity from 172.18.100.254 to 192.168.157.254. Check your routing table on router R1 and use the ping command. The routing table will look like the picture blow.
R1_RT

Now that we have full unicast connectivity we can start with the multicast basics. First configure multicast routing on all the routers. This can be done with the following command: “ip mulicast-routing”. After that configure the “ip pim sparse-mode” command on all the interfaces which are participating in the multicast routing. In my topology this means all physical interfaces and the Loopback interfaces on router R3 and R4.
After this we have basic multicast connectivity.

Now it’s time to configure the Rendevous Point, but first a little explanation about PIM-SM, Rendevouz Point’s and Mapping Agents.

PIM-SM*
PIM-SM is a protocol for efficiently routing IP packets to multicast groups that may span wide-area and inter-domain internets. The protocol is named protocol-independent because it is not dependent on any particular unicast routing protocol for topology discovery, and sparse-mode because it is suitable for groups where a very low percentage of the nodes will subscribe to the multicast session. Unlike earlier dense-mode multicast routing protocols such as DVMRP and dense-multicast routing which flooded packets across the network and then pruned off branches where there were no receivers, PIM-SM explicitly constructs a tree from each sender to the receivers in the multicast group
explicitly builds unidirectional shared trees rooted at a rendezvous point (RP) per group, and optionally creates shortest-path trees per source. PIM-SM generally scales fairly well for wide-area usage.

Rendevouz Point*
A Rendezvous Point (RP) is used as a temporary way to connect a would-be multicast receiver to an existing shared multicast tree passing through the rendezvous point. When volume of traffic crosses a threshold, the receiver is joined to a source-specific tree, and the feed through the RP is dropped. You can think of this as obtaining copies of something through a friend who already subscribes, and when it proves useful or interesting, it’s worth the bother to become a direct subscriber.

I used auto-RP to configure a RP, so a little more about auto-RP

auto-RP
Auto-RP automatically distributes information to routers as to what the RP address is for various multicast groups. It simplifies use of multiple RP’s for different multicast group ranges. It avoids manual configuration inconsistencies, and allows for multiple RP’s acting as backups to each other. Cisco routers automatically listen for this information.

Auto-RP relies on a router designated as RP mapping agent. Potential RP’s announce themselves to the mapping agent, and it resolves any conflicts. The mapping agent then sends out the multicast group-RP mapping information to the other routers.

Mapping-Agent
The RP mapping agent listens to the announced packets from the RPs, then sends RP-to-group mappings in a discovery message that is sent to 224.0.1.40. These discovery messages are used by the remaining routers for their RP-to-group map. You can use one RP that also serves as the mapping agent, or you can configure multiple RPs and multiple mapping agents for redundancy purposes.

If you want to know more about the theory behind multicast routing check out the “Routing TCP/IP Volume II book written by Jeff Doyle and Jennifer DeHAven Carroll. Or check out this link: http://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/9356-48.html

Let’s start configuring. To configure the RP on R3 use the commands as in the below configuration:

R3
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip pim sparse-mode
!
ip pim send-rp-announce Loopback0 scope 15
!

And configure the Mapping-Agent on router R4. RP and MA can be configured on the same router, but for the sake of the example I configure them on different routers.

R4
!
interface Loopback0
ip address 4.4.4.4 255.255.255.255
ip pim sparse-mode
!
ip pim send-rp-discovery Loopback0 scope 15
!

Basically this is all there is to make PIM-SM, RP and MA to function. To check if everthing works as expected, use the following commands:

Show ip pim rp mapping
pim rp map
As can be seen in the above picture the 224.0.0.0/4 groups are connected to the RP on router R3 and the RP is chosen via Aur0-RP

To check if there is multicast connectivity check the multicast routing table:

Show ip mroute
sh ip mrou

Now were up to the next part, how to stream a videofile over the multicast network to a multicast receiver.

In my example I used 3 virtual machines with windows 7 installed, I use VMware workstation for it. To stream the videofile I installed VLC on C1. See below the configuration I used to stream the file
C1
VLC sets the TTL default to 1. I the topology used, this won’t work because there are at least 4 hops between sender and receiver. I set the TTL to 12. Check this with a wireshark trace like in the picture below
ttl
Because I set the multicast (group)address to 239.255.255.250 on C1, check on router R1 if the correct multicast group is “created” with the “show ip igmp groups” command.
sh ip igmp grou

 

Now configure the client, as shown in the picture below

C2

And there we go! We are looking to an udp multicast videostream. To make C3 work, follow the same steps.

This is a faitly simple example of the of PIM-SM and multicast, but nevertheless it gives a perfect view of the multicast capabilities!

If you run into any trouble, there are some handy multicast troubleshooting tools like mtrace and mstat.

Mtrace is the multicast equivalent of traceroute
mtrace

The mstat command gives you an overview of the multicast path in ascii style. It shows drops, duplicates, TTL’s and delays between the nodes in the paths.
mstat

 

 

*Source of this information is http://www.cisco.com

 

DMVPN

One of the parts of my CCIE study is DMVPN’s. With this technique it’s very easy to built full meshed VPN networks without the need to connect every (branch) office physically with each other. DMVPN’s are built in a hub and spoke manner. Between the hub and the spoke tunnels (VPN’s) are built for connectivity. It’s also possible to connect a branch to a branch, without sendig all the traffic to the Hub, but directly to the spoke site.
To make all of this happen, DMVPN’s use a technique which is called NHRP.

NHRP*
In a computer network, the Next Hop Resolution Protocol (NHRP) is a protocol or method that can be used so that a computer sending data to another computer can learn the most direct route (the fewest number of hops to the receiving computer. If the receiving computer is in the same subnetwork, the use of NHRP will tell the sending computer that the receiving computer is local and it can send subsequent data packets directly to the receiving computer using its subnetwork address rather than its global network address. If the receiving computer is not in the same subnetwork, the use of NHRP will tell the sending computer the computer in the subnetwork whose router provides the most direct path to the receiving computer and the sender can now forward subsequent data packets to that router. In a way NHRP functions almost as a DNS server.

In the picture below the topology I used for this case study. The internetcloud is in my GNS3 configuration a router which routes the used subnets.

DMVPN

 

First configure the DMVPN hub, in my case this is router R1. I think configuring the local and external addresses a pretty forward, so I will only show the tunnel configuration.

R1 Tunnel0
!
interface Tunnel0
ip address 10.0.0.1 255.255.255.0
no ip redirects
ip nhrp authentication DMVPN
ip nhrp network-id 1
tunnel source FastEthernet1/0
tunnel mode gre multipoint
tunnel protection ipsec profile MGRE
!

As can be seen in the above configuration there is no tunnel destination configured. Instead of this the tunnel mode is configured as “tunnel mode gre multipoint”. With this configuration it is possible to connect several branches (spokes) to the same interface.

To connect a spoke to the hub location the following configuration is necessary on the spoke router.

R2
!
interface Tunnel0
ip address 10.0.0.2 255.255.255.0
no ip redirects
ip nhrp authentication DMVPN
ip nhrp map 10.0.0.1 201.1.1.1
ip nhrp network-id 1
ip nhrp nhs 10.0.0.1
tunnel source FastEthernet1/0
tunnel mode gre multipoint
tunnel protection ipsec profile MGRE
!

To connect a branch office to the hub location, you have to point the tunnel to the tunnel and external address of the hub location.

To check if the connection succeeded, use the “show dmvpn” command on the hub and spoke router.

R1
show_dmvpn_R1

R2
show_dmvpn_R2

As can be seen there is DMVPN connectivity between the hub and the spoke router. Only the traffic is not encrypted yet. For that we have to configure a crypto IPSEC profile. This can be done as below, I will not discuss this part of the configuration. For this I will write a seperate blogpost.

Configure on router R1
!
crypto isakmp policy 1
encr aes
hash md5
authentication pre-share
group 2
crypto isakmp key HEGGEL address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set MYSET esp-aes esp-md5-hmac
!
crypto ipsec profile MGRE
set security-association lifetime seconds 86400
set transform-set MYSET
!

Configure on router R2
!
crypto isakmp policy 1
encr aes
hash md5
authentication pre-share
group 2
crypto isakmp key HEGGEL address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set MYSET esp-aes esp-md5-hmac
!
crypto ipsec profile MGRE
set security-association lifetime seconds 86400
set transform-set MYSET
!

Now the traffic between hub and spoke are encrypted. To check this, you can make use of wireshark. I will ping the 10.10.10.254 interface of router R1 with a source address of 192.168.1.254.

wireshark_encr

When you open one of these packets you can see that ESP is used to encypt the packet

ESP

ESP*
Encapsulating Security Payload (ESP) is a member of the IPsec protocol suite. In IPsec it provides origin authenticity, integrity and confidentiality protection of packtes. ESP also supports encryption-only and authentication-only configurations, but using encryption without authentication is strongly discouraged because it is insecure. Unlike AH, ESP in transport mode does not provide integrity and authentication for the entire IP packet. However, in Tunnel mode, where the entire original IP packet is encapsulated with a new packet header added, ESP protection is afforded to the whole inner IP packet (including the inner header) while the outer header (including any outer IPv4 options or IPv6 extension headers) remains unprotected. ESP operates directly on top of IP, using IP protocol number 50.

To create a spoke-to-spoke connection, let’s say between R2 and R4, only the routes necessary have to be configured on R2 and R4. In a large scale full mesh network it’s easier to use a dynamic routing protocol. But in my example I want to show it’s also possible to connect only two spoke’s instead of a totally meshed network.

Configure on R2 the route to the LAN of R4
!
ip route 192.168.2.0 255.255.255.0 10.0.0.4
!

Configure on R4 the route to the LAN of R2
!
ip route 172.18.1.o 255.255.255.0 10.0.0.2
!

If you use the “show dmvpn” command on R2 and R4, there is an extra tunnel built between spoke routers R2 and R4.

R2
show_dmvpn_R2_HS

R4
show_dmvpn_R4_HS

As can be seen in the picture above, the tunnel between R2 and R4 is a dynamic tunnel. If you remove the previously created routes, the tunnel will be terminated.

 

 

*Source is http://www.cisco.com

IPv6 Fundamentals

While learning for my CCIE exam I realized that my understanding of IPv6 was really mediocre, although it was enough to clear the CCNP and CCDP exams. But I have to level up my knowledge of IPv6 to even think of passing the CCIE exam. Besides the cisco.com website I used two books: “IPv6 Fundamentals” written by Rick Graziani and “IPv6 for Enterprise Networks” written by Shannon McFarland, Muninder Sambi, Nikhil Sharma and Sanjay Hooda.
After reading these books and reading some config guides from the cisco.com website, my understanding of IPv6 had leveled up about 10 levels.

Therefore I thought it was time to create a case study. Below is the topology I used. Of course I used my great study companion GNS3 to create and configure my case study.

IPv6 Topology

First I configured routers R1 to R3. This is the basic network, which uses OSPFv3. Below the configs of routers R1 to R3.

R1:

!
interface FastEthernet1/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:A001::1/64
ipv6 ospf 10 area 0
!
interface FastEthernet2/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:A003::1/64
ipv6 ospf 10 area 0
!
interface FastEthernet3/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:C001::1/64
ipv6 ospf 10 area 0
!
ipv6 router ospf 10
router-id 1.1.1.1
log-adjacency-changes

R2:

!
interface FastEthernet1/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:A001::2/64
ipv6 ospf 10 area 0
!
interface FastEthernet2/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:C002::1/64
ipv6 ospf 10 area 0
!
interface FastEthernet3/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:A002::1/64
ipv6 ospf 10 area 0
!
ipv6 router ospf 10
router-id 2.2.2.2
log-adjacency-changes
!

 

R3:

!
interface FastEthernet1/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:C003::1/64
ipv6 ospf 10 area 0
!
interface FastEthernet2/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:A003::2/64
ipv6 ospf 10 area 0
!
interface FastEthernet3/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:A002::2/64
ipv6 ospf 10 area 0
!
ipv6 router ospf 10
router-id 3.3.3.3
log-adjacency-changes
!

As can be seen in the configurations, IPv6 isn’t that different than IPv4. Two things to remember, first the ospf configuration is done on the interface itself. Second, the router-id in OSPFv3 is a 32-bit dotted decimal number, yes indeed a IPv4 address format.

Check out the IPv6 routing table to confirm the configuration is working:

IPv6 route table R2

 

To test ip connectivity use Ping. This works the same as in IPv4:

ping_test_R2

As can be seen in the topology overview there is an IPv6 “island” that has only IPv4 connectivity to the “main” network. Here “6to4” tunnels come in handy. To create IPv6 connectivity between the main network and the IPv6 island, we create a 6to4 tunnel on routers R1 and R4. These tunnels encapsulate IPv6 traffic into IPv4 packtes. To make this happen the following configuration on R1 and R4 are necessary:

R1:

!
interface Tunnel0
no ip address
ipv6 enable
tunnel source FastEthernet0/0
tunnel destination 10.10.10.2
tunnel mode ipv6ip
!
interface FastEthernet0/0
no switchport
ip address 10.10.10.1 255.255.255.252
!
ipv6 route 2001:DB8:CAFE:F001::/64 Tunnel0
ipv6 route 2001:DB8:CAFE:F002::/64 Tunnel0
!
ipv6 router ospf 10
router-id 1.1.1.1
log-adjacency-changes
redistribute static metric 5
!

 

R4:

!
interface Tunnel0
no ip address
ipv6 enable
tunnel source FastEthernet1/0
tunnel destination 10.10.10.1
tunnel mode ipv6ip
!
interface FastEthernet1/0
ip address 10.10.10.2 255.255.255.252
duplex auto
speed auto
!
ipv6 route 2001:DB8:CAFE::/48 Tunnel0
!
ipv6 router ospf 11
router-id 4.4.4.4
log-adjacency-changes
redistribute static metric 5
!

The configuration is pretty straight forward. Create the tunnel, give in source and destination (in this case the IPv4 address of the other site) and create a statis route for the subnet that has to be reached pointing to the tunnel interface.
Don’t forget to redistribute the static route into the routing protocol. This works the same for OSPFv3 as it works in IPv4 OSPF. The only down-side of a manual 6to4 tunnel is that it doesn’t scale very well in large enterprise networks.
To verify the Tunnel configuration use the “show interface tunnel 0” command:

Tunnel 0 R1

Now it is possible to ping from C1 to C5:

Ping_C1-C5

To verify that the IPv6 traffic is indeed encapsulated in an IPv4 packet use the “debug ip packet detail” command. Protocol 41 has to be present in the packet header:

debug packet

After reading the books and make some configurations, I must conclude that IPv6 isn’t that hard at all. Maybe it is even more straightforward than IPv4, because there is little need for NAT and stuff. Offcourse there are some things to get used like the link local addresses or SLAAC e.g (in a later post more about this). In my opinion it’s just a change of mindset, after doing this IPv6 is easier than IPv4!

To be fully complete below the configuration of router R5:

R5:

!
interface FastEthernet1/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:F002::1/64
ipv6 ospf 11 area 0
!
interface FastEthernet2/0
no ip address
duplex auto
speed auto
ipv6 address 2001:DB8:CAFE:F001::2/64
ipv6 ospf 11 area 0
!
ipv6 router ospf 11
router-id 5.5.5.5
log-adjacency-changes
!