Routing between Docker containers using GNS3.


The idea is to route (IPv4 and IPv6) between Dockers containers using GNS3 and use them as end-hosts instead of Virtual Machines.

Containers use only the resources necessary for the application they run. They use an image of the host file system and can share the same environment (binaries and libraries).

In the other hand, virtual machines require entire OS’s, with reserved RAM and disk space.

Virtual machines vs Docker containers

Virtual machines vs Docker containers

 

If you are not familiar with Docker, I urge you to take a look at the below excellent short introduction and some additional explanation from Docker site. :

 

 

As for now, Docker has limited networking functionalities. This is where pipework comes to the rescue. Pipework allows more advanced networking settings like adding new interfaces, IP’s from a different subnets and set gateways and many more…

To be able to route between the containers using your own GNS3 topology (the sky the limit!), pipework allows to create a new interface inside a running container, connect it to a host bridge interface, give it an IP/mask in any subnet you want and set a default gateway pointing to a device in GNS3. Consequently all egress traffic from the container is routed to your GNS3 topology.

 

GNS3 connection to Docker a container

GNS3 connection to Docker a container

 

How pipework connects exposes container network

How pipework connects exposes container network

Lab requirements:

Docker:
https://docs.docker.com/installation/ubuntulinux/#docker-maintained-package-installation
Pipework:

sudo bash -c "curl https://raw.githubusercontent.com/jpetazzo/pipework/master/pipework\
 > /usr/local/bin/pipework"

For each container, we will generate docker image, run a container with an interactive terminal and set networking parameters (IP and default gateway).

To demonstrate docker flexibility, we will use 4 docker containers with 4 different subnets:

 

 

This is how containers are built for this lab:

 

 .

 .

Here is the general workflow for each container.

1- build image from Dockerfile (https://docs.docker.com/reference/builder/):

An image is readonly.

sudo docker build -t <image-tag> .

Or (docker v1.5) sudo docker build -t <image-tag> <DockerfileLocation>

2- Run the built image:

Spawn and run a writable container with interactive console.

The parameters of this command may differ slightly for each GUI containers.

sudo docker run -t -i <image id from `sudo docker images`> /bin/bash

3- Set container networking:

Create host bridge interface and link to a new interface inside the container, assign to it an IP and a new default gateway.

sudo pipework <bridge> -i <int> <container if from `sudo docker ps`> <ip/mask>@<gateway-ip

 

To avoid manipulating image id’s and container id’s for each of the images and the containers, I use a bash script to build and run all containers automatically:

https://github.com/AJNOURI/Docker-files/blob/master/gns3-docker.sh

 

#!/bin/bash
IMGLIST="$(sudo docker images | grep mybimage | awk '{ print $1; }')"
[[ $IMGLIST =~ "mybimage" ]] && sudo docker build -t mybimage -f phusion-dockerbase .
[[ $IMGLIST =~ "myapache" ]] && sudo docker build -t myapache -f apache-docker .
[[ $IMGLIST =~ "myfirefox" ]] && sudo docker build -t myfirefox -f firefox-docker .

BASE_I1="$(sudo docker images | grep mybimage | awk '{ print $3; }')"
lxterminal -e "sudo docker run -t -i --name baseimage1 $BASE_I1 /bin/bash"
sleep 2
BASE_C1="$(sudo docker ps | grep baseimage1 | awk '{ print $1; }')"
sudo pipework br4 -i eth1 $BASE_C1 192.168.44.1/24@192.168.44.100 

BASE_I2="$(sudo docker images | grep mybimage | awk '{ print $3; }')"
lxterminal -e "sudo docker run -t -i --name baseimage2 $BASE_I2 /bin/bash"
sleep 2
BASE_C2="$(sudo docker ps | grep baseimage2 | awk '{ print $1; }')"
sudo pipework br5 -i eth1 $BASE_C2 192.168.55.1/24@192.168.55.100 

APACHE_I1="$(sudo docker images | grep myapache | awk '{ print $3; }')"
lxterminal -t "Base apache" -e "sudo docker run -t -i --name apache1 $APACHE_I1 /bin/bash"
sleep 2
APACHE_C1="$(sudo docker ps | grep apache1 | awk '{ print $1; }')"
sudo pipework br6 -i eth1 $APACHE_C1 192.168.66.1/24@192.168.66.100 

lxterminal -t "Firefox" -e "sudo docker run -ti --name firefox1 --rm -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix myfirefox"
sleep 2
FIREFOX_C1="$(sudo docker ps | grep firefox1 | awk '{ print $1; }')"
sudo pipework br7 -i eth1 $FIREFOX_C1 192.168.77.1/24@192.168.77.100

 

And we end up with the following conainers:

Containers, images and dependencies.

Containers, images and dependencies.


 

GNS3

All you have to do is to bind a separate cloud to each bridge interface (br4,br5,br6 and br7) created by pipework, and then connect them to the appropriate segment in your topology.

 

Lab topology

Lab topology

Note that GNS3 topology is already configured for IPv6, so as soon as you start the routers, Docker containers will be assigned IPv6 addresses from the routers through SLAAC (Stateles Auto Configuration) which makes them reachable through IPv6.

 

Here is a video on how to launch the lab:


 

Cleaning up

To clean your host from all containers and images use the following bash script:

https://github.com/AJNOURI/Docker-files/blob/master/clean_docker.sh which uses the below docker commands:

Stop running containers:

  • sudo docker stop <container id’s from `sudo docker ps`>

Remove the stopped container:

  • sudo docker rm <container id’s from `sudo docker ps -a`>

Remove the image:

  • sudo docker rmi <image id’s from `sudo docker images`>
sudo ./clean_docker.sh
Stopping all running containers...
bf3d37220391
f8ad6f5c354f
Removing all stopped containers...
bf3d37220391
f8ad6f5c354f
Erasing all images...
Make sure you are generating image from a Dockerfile
or have pushed your images to DockerHub.
*** Do you want to continue? No

I answered “No”, because I still need those images to spawn containers, you can answer “Yes” to the question if you don’t need the images anymore or if you need to change the images.


 

References:

Docker:

pipework for advanced Docker networking:

Running firefox inside Docker container:

Baseimage-Docker:

3D model shipping container:

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


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

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

Without SIA

Browse in separate page

With SIA

Browse in separate page

OSPF inter-area and intra-area routing rules


The following lab focuses on intra-area and inter-area route selection process.

For the sake of clarity, I put the final conclusions first, wrapped in a table form, with some explanations to ponder upon, followed by the different lab cases used to check OSPF route selection rules.

For each case, I used interface costs and states to illustrate OSPF selection rules in action.

 

Order of preference and criteria Rules
1. Intra-area (O)

  • Lowest cost
  • Multipath
– Intra-area routes are always preferred over inter-area ones.

– Intra-area routing to a destination inside a non-backbone area will take the shortest path without traversing the backbone area.- Intra-area routing to a destination inside a backbone area will take the shortest path without traversing a non-backbone area.
– ABR’s advertise only intra-area routes from non-backbone area to the backbone area and advertise intra-area and inter-area routes from backbone area to a non-backbone area.
– ABRs do not take into account in SPF calculations LSAs received from non-backbone areas.
2. Inter-area (IA) – Inter-area route between two non-backbone areas must pass through the backbone area.
– Inter-area route will take the path with the shortest total cost.
3. External routes
3a. Type 1:

  • Lowest total cost
  • Multipath

3b. Type 2:

  • Redistribution cost
  • Total cost
  • Multipath
For more information about comparing OSPF external routes, please refer to the lab OSPF external E1, E2, N1, N2…Who is the winner?

 

  • References from RFCs:

rfc3509

OSPF prevents inter-area routing loops by implementing a split-horizon mechanism, allowing ABRs to inject into the backbone only Summary-LSAs derived from the intra-area routes, and limiting ABRs’ SPF calculation to consider only Summary-LSAs in the backbone area’s link-state database.

 

rfc2328

Routing in the Autonomous System takes place on two levels, depending on whether the source and destination of a packet reside in the same area (intra-area routing is used) or different areas (inter-area routing is used). In intra-area routing, the packet is routed solely on information obtained within the area; no routing information obtained from outside the area can be used.   This protects intra-area routing from the injection of bad routing information.

 

3.2.   Inter-area routingWhen routing a packet between two non-backbone areas the backbone is used. The path that the packet will travel can be broken up into three contiguous pieces: an intra-area path from the source to an area border router, a backbone path between the source and destination areas, and then another intra-area path to the destination. The algorithm finds the set of such paths that have the smallest cost.The topology of the backbone dictates the backbone paths used between areas.

 


There are four possible types of paths used to route traffic to the destination, listed here in decreasing order of preference:
intra-area, inter-area, type 1 external or type 2 external.

To understand OSPF mechanism of loop prevention, think conceptually of OSPF areas as nodes in a loop-free tree with depth never bigger than 2.

 

OSPF tree: loop-free

OSPF tree: loop-free

You can visually see why 2 non-backbone areas cannot directly exchange routes and they must have area0 as an intermediate area to avoid loops:

 

OSPF tree: loop

OSPF tree: loop

Important notes:

  • Throughout the lab, I am using cost to manipulate route selection.

  • OSPF takes into account the cost of output interface toward the destination, so be careful when you change the cost on one end of a link, this can cause unwanted asymmetric routing.

  • IGP protocols split the router (advertise routes through interfaces) whereas BGP splits the link between routers, this fundamental difference should be clearly depicted in the topology to avoid confusion.

  • If you are advertising your loopback networks with mask less than 32 you will have to to set their ospf network type point-to-point (refer to this lab for more information).

  • Observe the ospf database inf. for LSA3 “Routing Bit Set on this LSA“, this is a Cisco-specific implementation of OSPF protocol, indicating that a specific LSA is taken into account in the calculation of the best route.

  • Multipath selection is considered locally through FIB and provided by CEF load balancing mechanism, if there next-hops leading to the same destination.

 

Low-level lab design topology

Here is the lab topology used for testing:

Figure3: Low Level Design Lab topology

Figure3: Low Level Design Lab topology

 

Test cases

Case1:

  • Traffic between R1 10.10.0.1 (area 123) to R5 50.10.0.5 (area0)
  • Default interface ospf costs
Figure4: Case1

Figure4: Case1

R1#Ping 50.10.0.5 source 10.10.0.1 repeat 5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 50.10.0.5, timeout is 2 seconds:
Packet sent with a source address of 10.10.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/27/40 ms
R1#trace 50.10.0.5 source 10.10.0.1

Type escape sequence to abort.
Tracing the route to 50.10.0.5

  1 192.168.31.3 8 msec
    192.168.21.2 12 msec
    192.168.31.3 16 msec
  2 192.168.42.4 16 msec
    192.168.43.4 16 msec
    192.168.42.4 32 msec
  3 192.168.54.5 28 msec 40 msec 40 msec
R1#sh ip route 50.10.0.5

Routing entry for 50.10.0.5/32

  Known via &quot;ospf 666&quot;, distance 110, metric 4, type inter area

  Last update from 192.168.12.2 on FastEthernet1/0, 00:42:05 ago

  Routing Descriptor Blocks:

  * 192.168.13.3, from 3.3.3.3, 00:42:15 ago, via FastEthernet1/1

      Route metric is 4, traffic share count is 1

    192.168.12.2, from 2.2.2.2, 00:42:05 ago, via FastEthernet1/0

      Route metric is 4, traffic share count is 1

R1#
R1#sh ip ospf database summary 50.10.0.5

            OSPF Router with ID (1.1.1.1) (Process ID 666)

        Summary Net Link States (Area 123)

  Routing Bit Set on this LSA

  LS age: 543

  Options: (No TOS-capability, DC, Upward)

  LS Type: Summary Links(Network)

  Link State ID: 50.10.0.5 (summary Network Number)

  Advertising Router: 2.2.2.2

  LS Seq Number: 80000002

  Checksum: 0x32BD

  Length: 28

  Network Mask: /32

    TOS: 0     Metric: 3 

  Routing Bit Set on this LSA

  LS age: 587

  Options: (No TOS-capability, DC, Upward)

  LS Type: Summary Links(Network)

  Link State ID: 50.10.0.5 (summary Network Number)

  Advertising Router: 3.3.3.3

  LS Seq Number: 80000002

  Checksum: 0x14D7

  Length: 28

  Network Mask: /32

    TOS: 0     Metric: 3 

R1#

R1#

 

Case2:

  • Traffic from R1 10.10.0.1 (area123) to R5 50.20.0.5 (backbone)
  • R1 fa1/0 cost = 10
  • R2 fa1/1 cost = 10
Figure5: Case2

Figure5: Case2

Making two inter-area paths with unequal total costs, (unequal intra-area costs)

R1#trace 50.10.0.5 source 10.10.0.1

Type escape sequence to abort.
Tracing the route to 50.10.0.5

  1  *
    192.168.13.3 12 msec 28 msec
  2  *
    192.168.34.4 16 msec 16 msec
  3  *
    192.168.45.5 44 msec 44 msec
R1#sh ip route 50.10.0.5
Routing entry for 50.10.0.5/32
  Known via &quot;ospf 666&quot;, distance 110, metric 4, type inter area
  Last update from 192.168.13.3 on FastEthernet1/1, 00:48:22 ago
  Routing Descriptor Blocks:
  * 192.168.13.3, from 3.3.3.3, 01:06:54 ago, via FastEthernet1/1
      Route metric is 4, traffic share count is 1

R1#

R1#sh ip ospf database summary 50.10.0.5

            OSPF Router with ID (1.1.1.1) (Process ID 666)

        Summary Net Link States (Area 123)

  LS age: 827
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 50.10.0.5 (summary Network Number)
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000007
  Checksum: 0x825F
  Length: 28
  Network Mask: /32
    TOS: 0     Metric: 12 

  Routing Bit Set on this LSA
  LS age: 90
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 50.10.0.5 (summary Network Number)
  Advertising Router: 3.3.3.3
  LS Seq Number: 8000000A
  Checksum: 0x4DF
  Length: 28
  Network Mask: /32
    TOS: 0     Metric: 3 

R1#

 

R5#trace 10.10.0.1 source 50.10.0.5

Type escape sequence to abort.
Tracing the route to 10.10.0.1

  1 192.168.45.4 8 msec 4 msec 8 msec
  2 192.168.34.3 16 msec *  32 msec
  3  *
    192.168.13.1 44 msec *
R5#

R5#sh ip ospf database summ 10.10.0.1

            OSPF Router with ID (5.5.5.5) (Process ID 666)

        Summary Net Link States (Area 0)

  LS age: 194
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 10.10.0.1 (summary Network Number)
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000007
  Checksum: 0x50C7
  Length: 28
  Network Mask: /32
    TOS: 0     Metric: 2 

  Routing Bit Set on this LSA
  LS age: 691
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 10.10.0.1 (summary Network Number)
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000008
  Checksum: 0x30E2
  Length: 28
  Network Mask: /32
    TOS: 0     Metric: 2 

        Summary Net Link States (Area 25)

  LS age: 198
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 10.10.0.1 (summary Network Number)
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000007
  Checksum: 0x50C7
  Length: 28
  Network Mask: /32
    TOS: 0     Metric: 2 

  LS age: 203
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 10.10.0.1 (summary Network Number)
  Advertising Router: 5.5.5.5
  LS Seq Number: 80000007
  Checksum: 0xAFF
  Length: 28
  Network Mask: /32
    TOS: 0     Metric: 4 

R5#

Note that, for the return traffic R5 will receive both summary LSA3 from R2 and R3, but will take into account only R3 because of the ABR’s router ID = 3.3.3.3

Multipath is not considered because there is only one next-hop (R4) in the FIB.

Case3:

  • Traffic from R1 10.10.0.1 (area 123) to R5 50.10.0.2 (backbone)
  • R1 fa1/0 cost = 10
  • R3 fa1/2 cost = 100
Figure6: Case3

Figure6: Case3

R1#sh ip ospf database summ 50.10.0.5

            OSPF Router with ID (1.1.1.1) (Process ID 666)

        Summary Net Link States (Area 123)

  Routing Bit Set on this LSA
  LS age: 697
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 50.10.0.5 (summary Network Number)
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000004
  Checksum: 0x2EBF
  Length: 28
  Network Mask: /32
    TOS: 0     Metric: 3

  LS age: 46
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 50.10.0.5 (summary Network Number)
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000002
  Checksum: 0xF592
  Length: 28
  Network Mask: /32
    TOS: 0     Metric: 102

R1#      
R1#sh ip route 50.10.0.5             
Routing entry for 50.10.0.5/32
  Known via &quot;ospf 666&quot;, distance 110, metric 13, type inter area
  Last update from 192.168.12.2 on FastEthernet1/0, 00:01:22 ago
  Routing Descriptor Blocks:
  * 192.168.12.2, from 2.2.2.2, 00:01:22 ago, via FastEthernet1/0
      Route metric is 13, traffic share count is 1

R1#
R1#trace 50.10.0.5 source 10.10.0.1         

Type escape sequence to abort.
Tracing the route to 50.10.0.5

  1 192.168.12.2 20 msec 20 msec 20 msec
  2 192.168.24.4 28 msec 20 msec 24 msec
  3 192.168.45.5 28 msec 36 msec 40 msec
R1#

 

With unequal costs to ABRs and unequal costs advertised by ABRs, R1 OSPF has chosen the path with the lowest total cost to destination: cost to ABRs + cost of LSA3 summary advertised by each ABR.

Case4:

  • Traffic from R1 10.10.0.1 (area 123) to R5 50.10.0.2 (backbone)
  • R1 fa1/0 cost = 10
  • R3 fa1/2 cost = 10
Figure7: Case4

Figure7: Case4

R1#sh ip ospf database summ 50.10.0.5    

            OSPF Router with ID (1.1.1.1) (Process ID 666)

        Summary Net Link States (Area 123)

  Routing Bit Set on this LSA
  LS age: 1072
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 50.10.0.5 (summary Network Number)
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000004
  Checksum: 0x2EBF
  Length: 28
  Network Mask: /32
    TOS: 0     Metric: 3

  Routing Bit Set on this LSA
  LS age: 12
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 50.10.0.5 (summary Network Number)
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000003
  Checksum: 0x6C75
  Length: 28
  Network Mask: /32
    TOS: 0     Metric: 12

R1#
R1#sh ip route 50.10.0.5                 
Routing entry for 50.10.0.5/32
  Known via &quot;ospf 666&quot;, distance 110, metric 13, type inter area
  Last update from 192.168.13.3 on FastEthernet1/1, 00:01:21 ago
  Routing Descriptor Blocks:
    192.168.13.3, from 3.3.3.3, 00:01:21 ago, via FastEthernet1/1
      Route metric is 13, traffic share count is 1
  * 192.168.12.2, from 2.2.2.2, 00:08:09 ago, via FastEthernet1/0
      Route metric is 13, traffic share count is 1

R1#
R1#trace 50.10.0.5 source 10.10.0.1  

Type escape sequence to abort.
Tracing the route to 50.10.0.5

  1 192.168.13.3 8 msec
    192.168.12.2 8 msec
    192.168.13.3 8 msec
  2 192.168.24.4 20 msec
    192.168.34.4 24 msec
    192.168.24.4 16 msec
  3 192.168.45.5 20 msec 32 msec 24 msec
R1#

 

With unequal costs to ABRs and unequal costs advertised by ABRs, R1 OSPF has chosen multipath because of the equal total cost to destination: cost to ABRs + cost of LSA3 summary advertised by each ABR.

Case5:

  • Traffic from R5 50.10.0.5 (backbone) to R1 10.10.0.1 (area 123)
  • R3 fa1/1 cost = 10
Figure8: Case5

Figure8: Case5

R5#sh ip ospf database summary 10.10.0.1

            OSPF Router with ID (50.10.0.5) (Process ID 666)

        Summary Net Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 1906
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 10.10.0.1 (summary Network Number)
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000011
  Checksum: 0x3CD1
  Length: 28
  Network Mask: /32
    TOS: 0     Metric: 2

  LS age: 19
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 10.10.0.1 (summary Network Number)
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000003
  Checksum: 0x947A
  Length: 28
  Network Mask: /32
        TOS: 0     Metric: 11
          
...
R5#
R5#sh ip route 10.10.0.1                
Routing entry for 10.10.0.1/32
  Known via &quot;ospf 666&quot;, distance 110, metric 4, type inter area
  Last update from 192.168.45.4 on FastEthernet1/0, 00:02:53 ago
  Routing Descriptor Blocks:
  * 192.168.45.4, from 2.2.2.2, 00:02:53 ago, via FastEthernet1/0
      Route metric is 4, traffic share count is 1

R5#
R5#trace 10.10.0.1 source 50.10.0.5     

Type escape sequence to abort.
Tracing the route to 10.10.0.1

  1 192.168.45.4 4 msec 12 msec 8 msec
  2 192.168.24.2 24 msec 20 msec 20 msec
  3 192.168.12.1 20 msec 28 msec 20 msec
R5#

 

With equal paths to ABRs R2 and R3, R5 ospf choose the path with the lowest total cost (cost to ABR + cost advertised by ABR)

Case6:

  • Traffic from R5 50.10.0.5 (backbone) to R1 10.10.0.1 (area 123)
  • R3 fa1/1 cost = 10
  • R4 fa1/1 cost = 5
Figure9: Case6

Figure9: Case6

R5#sh ip ospf database summary 10.10.0.1

            OSPF Router with ID (50.10.0.5) (Process ID 666)

        Summary Net Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 573
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 10.10.0.1 (summary Network Number)
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000012
  Checksum: 0x3AD2
  Length: 28
  Network Mask: /32
    TOS: 0     Metric: 2

  LS age: 710
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 10.10.0.1 (summary Network Number)
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000003
  Checksum: 0x947A
  Length: 28
  Network Mask: /32
        TOS: 0     Metric: 11
          
...   
R5#
R5#sh ip route 10.10.0.1                
Routing entry for 10.10.0.1/32
  Known via &quot;ospf 666&quot;, distance 110, metric 8, type inter area
  Last update from 192.168.45.4 on FastEthernet1/0, 00:02:49 ago
  Routing Descriptor Blocks:
  * 192.168.45.4, from 2.2.2.2, 00:02:49 ago, via FastEthernet1/0
      Route metric is 8, traffic share count is 1

R5#
R5#trace 10.10.0.1 source 50.10.0.5     

Type escape sequence to abort.
Tracing the route to 10.10.0.1

  1 192.168.45.4 16 msec 12 msec 8 msec
  2 192.168.24.2 20 msec 20 msec 20 msec
  3 192.168.12.1 28 msec 24 msec 20 msec
R5#

 

Note that OSPF on R5 did not choose the shortest path to ABR (R3), but the total cost.

==> The same from area0 to non-backbone area, the router looks at the total cost of LSA3 + cost of the route inside area0

Case7:

  • Traffic from R1 10.10.0.1 (area123) to R2 20.10.0.2 (area 123)
  • R1 fa1/0 cost = 100
Figure10: Case7

Figure10: Case7

R1#sh ip route 20.10.0.2
Routing entry for 20.10.0.2/32
  Known via &quot;ospf 666&quot;, distance 110, metric 101, type intra area
  Last update from 192.168.12.2 on FastEthernet1/0, 00:00:11 ago
  Routing Descriptor Blocks:
  * 192.168.12.2, from 2.2.2.2, 00:00:11 ago, via FastEthernet1/0
      Route metric is 101, traffic share count is 1

R1#trace 20.10.0.2 source 10.10.0.1

Type escape sequence to abort.
Tracing the route to 20.10.0.2

  1 192.168.12.2 16 msec 12 msec 8 msec
R1#

 

R3#sh ip route 20.10.0.2
Routing entry for 20.10.0.2/32
  Known via &quot;ospf 666&quot;, distance 110, metric 102, type intra area
  Last update from 192.168.13.1 on FastEthernet1/1, 00:01:24 ago
  Routing Descriptor Blocks:
  * 192.168.13.1, from 2.2.2.2, 00:01:24 ago, via FastEthernet1/1
      Route metric is 102, traffic share count is 1

R3#

 

Case8:

  • Traffic from R1 10.10.0.1 (area123) to R2 20.10.0.2 (area 123)
  • R1-R2 link down (no inter-area route to 20.10.0.2)
Figure11: Case8

Figure11: Case8

R1#sh ip route 20.10.0.2
% Subnet not in table
R1#
R1#
R1#sh ip ospf database summ
R1#sh ip ospf database summary 20.10.0.2

            OSPF Router with ID (1.1.1.1) (Process ID 666)
R1#

 

R1 can no more reach the destination in the same area, though it is reachable from R3 which is itself reachable to R1

R3#sh ip route 20.10.0.2
Routing entry for 20.10.0.2/32
  Known via &quot;ospf 666&quot;, distance 110, metric 3, type inter area
  Last update from 192.168.34.4 on FastEthernet1/2, 00:01:12 ago
  Routing Descriptor Blocks:
  * 192.168.34.4, from 2.2.2.2, 00:01:12 ago, via FastEthernet1/2
      Route metric is 3, traffic share count is 1

R3#ping 20.10.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.10.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/27/32 ms
R3#trace 20.10.0.2

Type escape sequence to abort.
Tracing the route to 20.10.0.2

  1 192.168.34.4 12 msec 8 msec 12 msec
  2 192.168.24.2 16 msec 24 msec 16 msec
R3#

 

OSPF will always choose the intra-area path without crossing area 0

Case9:

  • Intra-area traffic from R4 40.10.0.4 (backbone) to R2 20.10.0.2 (backbone)
  • R4 f1/1 cost = 100
Figure12: Case9

Figure12: Case9

R4#sh ip route 20.20.0.2
Routing entry for 20.20.0.2/32
  Known via &quot;ospf 666&quot;, distance 110, metric 101, type intra area
  Last update from 192.168.24.2 on FastEthernet1/1, 00:01:51 ago
  Routing Descriptor Blocks:
  * 192.168.24.2, from 2.2.2.2, 00:01:51 ago, via FastEthernet1/1
      Route metric is 101, traffic share count is 1

R4#trace 20.20.0.2 source 40.10.0.4

Type escape sequence to abort.
Tracing the route to 20.20.0.2

  1 192.168.24.2 20 msec 12 msec 8 msec
R4#

 

R3#sh ip route 20.20.0.2
Routing entry for 20.20.0.2/32
  Known via &quot;ospf 666&quot;, distance 110, metric 102, type intra area
  Last update from 192.168.34.4 on FastEthernet1/2, 00:02:44 ago
  Routing Descriptor Blocks:
  * 192.168.34.4, from 2.2.2.2, 00:02:44 ago, via FastEthernet1/2
      Route metric is 102, traffic share count is 1

R3#

 

R4 chose the worse path through R2 inside the backbone without crossing non-backbone area.

Case10:

  • Traffic from R1 10.10.0.2 (area123) to R2 20.20.0.2 (backbone)
  • R4-R2 link down (no inter-area route to 20.20.0.2)
Figure13: Case10

Figure13: Case10

R1#sh ip route 20.20.0.2
Routing entry for 20.20.0.2/32
  Known via &quot;ospf 666&quot;, distance 110, metric 2, type inter area
  Last update from 192.168.12.2 on FastEthernet1/0, 00:00:02 ago
  Routing Descriptor Blocks:
  * 192.168.12.2, from 2.2.2.2, 00:00:02 ago, via FastEthernet1/0
      Route metric is 2, traffic share count is 1

R1#trace 20.20.0.2 source 10.10.0.2

Type escape sequence to abort.
Tracing the route to 20.20.0.2

  1 192.168.12.2 12 msec 8 msec 8 msec
R1#

R4#sh ip route 20.20.0.2
% Network not in table
R4#
R4#sh ip ospf data summ 20.20.0.2  

            OSPF Router with ID (4.4.4.4) (Process ID 666)
R4#
R3#sh ip route 20.20.0.2
% Network not in table
R3#sh ip ospf data summary  20.20.0.2

            OSPF Router with ID (3.3.3.3) (Process ID 666)

        Summary Net Link States (Area 123)

  LS age: 3429
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 20.20.0.2 (summary Network Number)
  Advertising Router: 2.2.2.2
  LS Seq Number: 8000001C
  Checksum: 0x17D7
  Length: 28
  Network Mask: /32
    TOS: 0     Metric: 1

R3#

Though R3 has received the summary LSA3 from R2 though the non-backbone area 123, it did not include it in the routing table, even if it is reachable from R1

Case11:

  • Traffic between two non-backbone areas. From area123 to area25.
  • Default interface costs
Figure14: Case11

Figure14: Case11

R1#sh ip route 50.20.0.5
Routing entry for 50.20.0.5/32
  Known via &quot;ospf 666&quot;, distance 110, metric 3, type inter area
  Last update from 192.168.12.2 on FastEthernet1/0, 00:02:54 ago
  Routing Descriptor Blocks:
  * 192.168.12.2, from 2.2.2.2, 00:02:54 ago, via FastEthernet1/0
      Route metric is 3, traffic share count is 1

R1#trace 50.20.0.5 source 10.10.0.1

Type escape sequence to abort.
Tracing the route to 50.20.0.5

  1 192.168.12.2 16 msec 0 msec 8 msec
  2 192.168.25.5 20 msec 24 msec 32 msec
R1#

From R1, OSPF will choose the path with the lowest total cost within area 123, the backbone and area 25. This happens to be the path through R2, which is directly connected to area25. This seems to defeat the rule B, but it doesn’t, because the ABR R2 has an interface in the backbone.

Case12:

  • Traffic generated from R2: 20.10.0.2 (area 123) to R5 50.20.0.5 (area 25).
  • R2 fa1/2 cost = 100
Figure15: Case12

Figure15: Case12

R2(config-if)#do sh ip route 50.20.0.5           
Routing entry for 50.20.0.5/32
  Known via &quot;ospf 666&quot;, distance 110, metric 101, type intra area
  Last update from 192.168.25.5 on FastEthernet1/2, 00:04:03 ago
  Routing Descriptor Blocks:
  * 192.168.25.5, from 5.5.5.5, 00:04:03 ago, via FastEthernet1/2
      Route metric is 101, traffic share count is 1

R2(config-if)#
R2(config-if)#do trace 50.20.0.5 source 20.10.0.2

Type escape sequence to abort.
Tracing the route to 50.20.0.5

  1 192.168.25.5 20 msec 24 msec 20 msec
R2(config-if)#

Even though inter-area link cost is made worse (higher cost), R2 ospf will choose the shortest path without crossing the backbone.

Case13:

  • R2 fa1/1 Down
Figure16: Case13

Figure16: Case13

R2#sh ip route 50.20.0.2
% Subnet not in table
R2#
R1#sh ip route 50.20.0.5           
Routing entry for 50.20.0.5/32
  Known via &quot;ospf 666&quot;, distance 110, metric 4, type inter area
  Last update from 192.168.13.3 on FastEthernet1/1, 00:08:28 ago
  Routing Descriptor Blocks:
  * 192.168.13.3, from 3.3.3.3, 00:12:15 ago, via FastEthernet1/1
      Route metric is 4, traffic share count is 1

R1#trace 50.20.0.5 source 10.10.0.1

Type escape sequence to abort.
Tracing the route to 50.20.0.5

  1 192.168.13.3 12 msec 8 msec 8 msec
  2 192.168.34.4 16 msec 16 msec 20 msec
  3 192.168.45.5 20 msec 28 msec 28 msec
R1#

Note that, as soon as R2 interface connected to the backbone is down, R2 can no more reach area25. And R1 will turn to the path advertised through R3.

Case14:

  • R2 fa1/1 Down
  • R1 fa1/1 Down
Figure17: Case14

Figure17: Case14

R1#sh ip route 50.20.0.5           
% Network not in table
R1#t  

Even though R1 link to R2 is up and R2 link (area 25) to R5 is up, R1 will not be able to use the inter-area path, because it doesn’t cross the backbone (not even a connected interface to the backbone).

 

 

DMVPN animation


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

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

Studied topology:

DMVPN animation

Animation

Offline Lab

You might consider the following key points for troubleshooting:

Routing protocols:

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

EIGRP

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

OSPF

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

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

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

Layered approach:

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

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

Quiz

Read more of this post

IPv6 multicast over IPv6 IPSec VTI


IPv4 IPSec doesn’t support multicast, we need to use GRE (unicast) to encapsulate multicast traffic and encrypt it. As a consequence, more complication and an additional level of routing, so less performance.

One of the advantages of IPv6 is the support of IPSec authentication and encryption (AH, ESP) right in the extension headers, which makes it natively support IPv6 multicast.

In this lab we will be using IPv6 IPSec site-to-site protection using VTI to natively support IPv6 multicast.

The configuration involves three topics: IPv6 routing, IPv6 IPSec and IPv6 multicast. Each process is built on the top the previous one, so before touching IPsec, make sure you have local connectivity for each segment of the network and complete reachability through IPv6 routing.

Next step, you can move to IPv6 IPSec and change routing configuration accordingly (through VTI).

IPv6 multicast relies on a solid foundation of unicast reachability, so once you have routes exchanged between the two sides through the secure connection you can start configuring IPv6 multicast (BSR, RP, client and server simulation).

Picture1: Lab topology

IPv6 multicast over IPv6 IPSec VTI

Lab outline

  • Routing
    • OSPFv3
    • EIGRP for IPv6
  • IPv6 IPSec
    • Using IPv6 IPSec VTI
    • Using OSPFv3 IPSec security feature
  • IPv6 Multicast
    • IPv6 PIM BSR
  • Offline lab
  • Troubleshooting cases
  • Performance testing

Routing

Note:
IPv6 Routing relies on link-local addresses, so for troubleshooting purpose, link-local IPs are configured to be similar to their respective global addresses, so they are easily recognisable. This will be of a tremendous help during troubleshooting. Otherwise you will find yourself trying to decode the matrix : )

OSPFv3

Needs an interface configured with IPv4 address for Router-id

OSPFv3 offloads security to IPv6 native IPv6, so you can secure OSPFv3 communications on purpose: per- interface or per-area basis.
  Table1: OSPFv3 configuration

  R2 R1
IPv6 routing processes need IPv4-format router ids ipv6 router ospf 12
router-id 2.2.2.2
 ipv6 router ospf 12
router-id 1.1.1.1
Announce respective LAN interfaces interface FastEthernet0/1
ipv6 ospf 12 area 22
interface FastEthernet0/1
ipv6 ospf 12 area 11 
Disable routing on the physical BTB connection to avoid RPF failure interface FastEthernet0/0
 ipv6 ospf 12 … 
interface FastEthernet0/0
 ipv6 ospf 12 …
IPv6 gateways exchange routes through the VTI encrypted interface interface Tunnel12
ipv6 ospf network point-to-point
ipv6 ospf 12 area 0
interface Tunnel12
ipv6 ospf network point-to-point
ipv6 ospf 12 area 0
Set the ospf network type on loopback interfaces if you want to advertise masks other that 128-length interface Loopback0
ipv6 ospf network point-to-point
ipv6 ospf 12 area 0
interface Loopback0
ipv6 ospf network point-to-point
ipv6 ospf 12 area 0
Table2: EIGRP for IPv6 configuration
  R2 R1
IPv6 routing processes need IPv4-format router ids ipv6 router eigrp 12
eigrp router-id 2.2.2.2
ipv6 router eigrp 12
eigrp router-id 1.1.1.1
Announce respective LAN interfaces interface FastEthernet0/1
ipv6 eigrp 12
interface FastEthernet0/1
ipv6 eigrp 12
Disable routing on the physical BTB connection to avoid RPF failure interface FastEthernet0/0
ipv6 eigrp 12
interface FastEthernet0/0
ipv6 eigrp 12
IPv6 gateways exchange routes through the VTI encrypted interface interface Tunnel12
ipv6 eigrp 12
interface Tunnel12
ipv6 eigrp 12
Set the ospf network type on loopback interfaces if you want to advertise masks other that 128-length interface Loopback0
ipv6 ospf network point-to-point
ipv6 ospf 12 area 0
interface Loopback0
ipv6 ospf network point-to-point
ipv6 ospf 12 area 0
Enable EIGRP process ipv6 router eigrp 12
no shutdown
ipv6 router eigrp 12
no shutdown

In case you want to configure EIGRP for IPv6:

– No shutdown inside EIGRP configuration mode

– Similarly to OSPFv3, we need an interface configured with IPv4 address for Router-id

IPv6 IPSec

  • Using IPv6 IPSec VTI
Table3: IPSec configuration
  R1 R2
Set the type of ISAKMP authentication crypto keyring keyring1
pre-shared-key address ipv6 2001:DB8::2/128 key cisco
crypto keyring keyring1
pre-shared-key address ipv6 2001:DB8::1/128 key cisco
  crypto isakmp key cisco address ipv6 2001:DB8::2/128 crypto isakmp key cisco address ipv6 2001:DB8::1/128
ISAKMP profile crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
lifetime 3600
crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
lifetime 3600
Transform sets: symmetric encryption and signed hash algorithms crypto ipsec transform-set 3des ah-sha-hmac esp-3des crypto ipsec transform-set 3des ah-sha-hmac esp-3des
  crypto ipsec profile profile0
set transform-set 3des
crypto ipsec profile profile0
set transform-set 3des
Tunnel mode and bind the ipsec profile interface Tunnel12
ipv6 address FE80::DB8:12:1 link-local
ipv6 address 2001:DB8:12::1/64
tunnel source FastEthernet0/0
tunnel destination 2001:DB8::2
tunnel mode ipsec ipv6
tunnel protection ipsec profile profile0
interface Tunnel12
ipv6 address FE80::DB8:12:2 link-local
ipv6 address 2001:DB8:12::2/64
tunnel source FastEthernet0/0
tunnel destination 2001:DB8::1
tunnel mode ipsec ipv6
tunnel protection ipsec profile profile0
Make sure to not advertise the routes through the physical interface to avoid RPF failures (when the source of the multicast traffic is reached from an different interface than the one provided by the RIB) interface FastEthernet0/0
ipv6 address FE80::DB8:1 link-local
ipv6 address 2001:DB8::1/64
ipv6 enable
interface FastEthernet0/0
ipv6 address FE80::DB8:2 link-local
ipv6 address 2001:DB8::2/64
ipv6 enable
 

Here is a capture of the traffic (secured) between R1 and R2 gateways

Picture2: Wireshark IPv6 IPSec trafic capture

IPv6-IPSec-VTI

What could go wrong?

– Encryption doesn’t match

– Shared key doesn’t match

– Wrong ISAKMP peers

– ACL in the path between the 2 gateways blocking gateways IPs or protocol 500

– IPSec profile no assigned to the tunnel int ( tunnel protection ipsec profile < …>)

– Ipsec Encryption and/or signed hashes don’t match.

  • Using OSPFv3 IPSec security feature

You still can use IPv6 IPSec to encrypt and authenticate only OSPF per-interface basis.

OSPFv3 will use the IPv6-enabled IP Security (IPsec) secure socket API.

R1

interface FastEthernet0/0
ipv6 ospf 12 area 0
ipv6 ospf encryption ipsec spi 256 esp 3des 123456789A123456789A123456789A123456789A12345678 md5 123456789A123456789A123456789A12

R2

interface FastEthernet0/0
ipv6 ospf 12 area 0
ipv6 ospf encryption ipsec spi 256 esp 3des 123456789A123456789A123456789A123456789A12345678 md5 123456789A123456789A123456789A12

Picture4: Wireshark traffic capture – OSPFv3 IPSec feature :

ipv6-ospf-feature

Note only OSPFv3 traffic is encrypted

IPv6 Multicast

IPv6 PIM BSR

The RP (Rendez-vous point) is the point where multicast server offer meets member’s demand.

First hop routers build (S,G) source trees with candidate RPs and register directly connected multicast sources.

Candidate- RPs announce themselves to candidate-BSRs, and the latter announce the inf. to all PIM routers.

All PIM routers looking for a particular multicast group learn Candidate RP IP addresses from BSR and build (*, G) shared trees.

Table4: Multicast configuration

  R1(candidate RP) R2(candidate BSR)
Enable multicast routing ipv6 multicast-routing ipv6 multicast-routing
R1 announced as BSR candidate ipv6 pim bsr candidate bsr 2001:DB8:10::1  
R2 announced as RP candidate   ipv6 pim bsr candidate rp 2001:DB8:20::2
Everything should be routed through the tunnel interface, to be encrypted ipv6 route ::/0 Tunnel12 FE80::DB8:12:2 ipv6 route ::/0 Tunnel12 FE80::DB8:12:1
For testing purpose, make one router join a multicast traffic and ping it from a LAN router on the other side or you can opt for more fun by running VLC on one host to read a network stream and stream a video from a host on the other side.   interface FastEthernet0/1
ipv6 mld join-group ff0E::5AB

Make sure that:

  • At least one router is manually configured as a candidate RP
  • At least one router is manually configured as a candidate BSR
During multicasting of the traffic, sll PIM routers knows about the RP and the BSR

– (*,G) shared tree is spread over PIM routers from the last hop router (connected to multicast members).

– (S,G) source tree is established between the first hop router (connected to the multicast server) and the RP.

– The idea behind IPv6 PIM BSR is the same as in IPv4; here an animation explaining the process for IPv4.

Let’s check end-to-end multicast streaming:

Before going to troubleshooting here is the offline lab with all commands:

Troubleshooting

If something doesn’t work and you are stuck, isolate the area of work and inspect each process separately step by step.

Check each step using “show…” commands, so you know each time what you are looking for to spot what is wrong.

“sh run” and script comparison technique is limited by the visual perception capability which is illusory and far from being reliable.

Common routing issues

– Make sure you have successful back-to-back connectivity everywhere.

– With EIGRP for IPv6 make sure the process is enabled.

– If routing neighbors are connected through NBMA network, make sure to enable pseudo broadcasting and manually set neighbor commands.

Common IPSec issues

– ISAKMP phase

– Wrong peer

– Wrong shared password

– Not matching isakmp profile

– IPSec phase

– Not matching ipsec profile

Common PIM issues

– If routing neighbors are connected through NBMA network, make sure C-RPs and C-BSRs are locate on the main site.

– Issue with the client: => no (*,G)

– MLD query issue with the last hop.

– Last hop PIM router cannot build the shared tree.

– Issue with RP registration  => no (S,G)

– Multicast server MLD issue with the 1st hop router

– 1st hop router cannot register with th RP.

– Issue with C-BSR candidate doesn’t advertise RP inf. to PIM routers (BSRs collect all candidate RPs and announce them to all PIM routers to choose the best RP for each group)

– Issue with C-RP candidate doesn’t announce themselves to C-BSRs (RPs announce to C-BSRs which multicast groups they are responsible for)

-RPF failure (the interface used to reach the multicast source, through RIB, is not the interface sourcing the multicast traffic)

Picture5: RPF Failure

Replace test case 6 with RPF failure (enable PIM & routing through physical int.)

Table5: troubleshooting cases
Case Description Simulated wrong configuration Correct configuration
ISAKMP policy, encryption key mismatch crypto isakmp policy 10
encr aes
crypto isakmp policy 10
encr 3des
2 ISAKMP policy, Hash algorithm mismatch crypto isakmp policy 10
Hash sha
crypto isakmp policy 10
Hash md5 
3 Wrong ISAKMP peer crypto isakmp key cisco address ipv6 2001:DB8::3/128 crypto isakmp key cisco address ipv6 2001:DB8::2/128 
4 Wrong ISAKMP key crypto isakmp key cisco1 address ipv6 2001:DB8::2/128 crypto isakmp key cisco address ipv6 2001:DB8::2/128 
5 Wrong tunnel destination interface Tunnel12
tunnel destination 2001:DB8::3
interface Tunnel12
tunnel destination 2001:DB8::2 
6 Wrong tunnel source interface Tunnel12
tunnel source FastEthernet0/1
interface Tunnel12
tunnel source FastEthernet0/0
 

For more details about each case, refer to the offline lab below, you will find an extensive coverage of all important commands along with debug for each case:

Performance testing

Three cases are tested: multicast traffic between R1 and R2 is routed through:

– Physical interfaces (serial connection): MTU=1500 bytes

– IPv6 GRE: MTU=1456 bytes

– IPv6 IPSec VTI: MTU=1391 bytes

The following tests are performed using iperf in GNS3 lab environment, so results are to keep relative.

Picture6: Iperf testing

perfs

References

http://www.faqs.org/rfcs/rfc6226.html

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

http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-multicast.html#wp1055997

https://supportforums.cisco.com/docs/DOC-27971

http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-tunnel_external_docbase_0900e4b1805a3c71_4container_external_docbase_0900e4b181b83f78.html

http://www.cisco.com/web/learning/le21/le39/docs/TDW_112_Prezo.pdf

http://networklessons.com/multicast/ipv6-pim-mld-example/

http://www.gogo6.com/profiles/blogs/ietf-discusses-deprecating-ipv6-fragments

http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-01

https://datatracker.ietf.org/doc/draft-bonica-6man-frag-deprecate

http://blog.initialdraft.com/archives/1648/

OSPF external E1, E2, N1, N2…Who is the winner?


This lab focuses on route selection mechanism of OSPF external routes. The complexity of OSPF selection process is due to its inherent hierarchical structure.

The following selection order should be familiar to you:

  1. intra-area (O)
  2. inter-area (IA)
  3. external routes

OSPF provides more flexibility for external routes by manipulating the following criteria:

  • Regular areas or NSSA (Not So Stubby Area)
  • type1 or type2
  • total cost, cost to ABR and cost to ASBR

The idea is to provide a lab topology in which all types of external routes are artificially available in the same time to the main router (R1). This is done by injecting an overlapping prefix 10.10.10.1/32 through different areas into the same OSPF process.

R1(made the DR) is configured not to advertise LSAs and prefixes between its interfaces.

Each lab starts with all paths available (case1), then the forwarding interface of the best elected path is shutdown (case2) to see who is the next best route. And so on until the last preferable path.

Three topologies are used to narrow down the tests:

  • The 1st lab (Mix of external routes): Compare all types of external routes
  • The 2nd lab (All E2): Compare E2 routes with the same redistribution cost, but different costs to ABR and costs to ASBR.
  • The 3rd lab (All E1): Compare E1 routes with the same total cost, but different costs to ABR and costs to ASBR.

For each lab, the following is provided:

  • Lab topology
  • The result table for studied cases
  • Verification commands
  • An offline lab (A comprehensive report of the network state during each test case)
To keep visible the general structure of the post, verifications commands, configuration listings and the gory details of router configurations are kept in compact flash boxes with selectable text.

Lab1

Lab1 topology

ospfmix

Table1: Lab1 (Mix of external routes)

Case

Route type

Route cost

Next-hop

Cost to ABR

Cost to ASBR

From ABR (LSA4)

ASBR

Redistribution Cost

1 E1 22 192.168.121.2 1 1 192.168.61.8 20
2 E1 22 192.168.121.2 1 64 192.168.62.8 20
3 N1 30 192.168.161.6 10 192.168.161.6 20
4 N1 84 192.168.162.6 64 192.168.162.6 20
5 E1 85 192.168.122.2 64 64 192.168.62.8 20
*** N2 20 192.168.163.7 1 192.168.163.7 20
6 N2 20 192.168.164.7 64 192.168.164.7 20
7 E2 83 192.168.131.3 1 62 192.168.63.9 20
8 E2 83 192.168.131.3 1 64 192.168.64.9 20
9 E2 83 192.168.132.3 64 64 192.168.64.9 20
*** During the automatic testing the link from R1 to R2 (192.168.167) was unstable, so R1 RIB didn’t take it into account. But, theoretically it should be there.

Results:

Obviously OSPF consider type1 before type2 as indicated by RFC2328 (http://www.ietf.org/rfc/rfc2328.txt)


There are four possible types of paths used to route traffic to
the destination, listed here in decreasing order of preference:
intra-area, inter-area, type 1 external or type 2 external.

Knowing that type 1 cost is equal to the total cost of the route (redistribution cost + cost inside OSPF domain), OSPF does not differentiate between external routes from regular areas and NSSA areas. The one with the lowest total cost wins (N1 and E1 in table1).

Lab1 verification commands

Lab1 offline

Lab2 (All E2)

Lab2 topology

ospfalle2

According to lab1 results, though the cost of type 2 route is equal to the cost of the redistribution, it looks like among routes with the same cost OSPF considers other criteria.

Let’s consider a separated lab to compare routes with the same redistribution cost but different combinations of (cost to ABR + cost to ASBR).

Table2: Lab2 (All E2)

Case

Route type

Route cost

Next-hop

Cost to ABR

Cost to ASBR

From ABR (LSA4)

Redistribution Cost

1 E2 20 192.168.163.7 1 1 20
2 E2 20 192.168.162.6 64 1 20
E2 20 192.168.131.3 1 64 20
3 E2 20 192.168.122.2 64 64 20

Results:

According to the table, even though E2 cost is equal to the cost of redistribution, among routes with the same cost, OSPF consider the total cost as the tie breaker.

E2 selection process:

  1. Redistribution cost
  2. Total cost
  3. Multiple path installed

Lab2 verification commands

Lab2 offline

Lab3 (All E1)

Lab3 topology

top1

Table3: Lab3 (All E1)

Case

Route type

Route cost

Next-hop

Cost to ABR

Cost to ASBR

From ABR (LSA4)

Redistribution Cost

1 E1 148 192.168.163.7 1 1 146
E1 148 192.168.162.6 64 1 83
E1 148 192.168.131.3 1 64 83
E1 148 192.168.122.2 64 64 20

Results

For E1 routes, it looks like nothing counts but the total cost.

Lab3 verification commands

Lab3 offline

Conclusion

According to lab results, OSPF external route selection process works as follow:

  1. External routes type 1:
    1. Lowest total cost
    2. Multipath
  2. External routes type 2:
    1. Redistribution cost
    2. Total cost
    3. Multipath

Administrative Distance, prefix length, metric… Who is the winner?


  • The Concept
  • Procedural tasks
  • Result table
  • Conclusion

The concept

The idea of the lab is to test the RIB best route election criteria of a border router. To do so, four overlapping subnets are configured in different parts of the network and available to a border router through different routing protocols. One of them is directly connected.

All prefixes are made available and reachable in the same time to see who is going to be elected as best route, then remove the winner from the competition by making the corresponding path unavailable and iterate the selection process until the last path.

One directly connected segment and three routing protocols, so four administrative distances: directly connected (AD=0), RIP(AD=120),OSPF(AD=110) and EIGRP internal(AD=90).

Each protocol has two unequal paths (different metrics) to reach the same prefix.

Prefix masks are configured to be inversely proportional to routing protocol administrative distances.

Lab topology

6VPE MPLS

Procedural tasks

For each test case, the routing table is checked for the best route, a trace route to check the path and make the winner path unavailable.




Result table

Classification

Mask length

metric

AD

prefix

Path

Routing protocol

4

28

110

110

192.168.1.64

A

OSPF

3

74

192.168.1.64

B

1

29

1

120

192.168.1.64

C

RIP

2

2

192.168.1.64

D

6

27

32195456

90

192.168.1.64

E

EIGRP

5

2195456

192.168.1.64

F

7

26

0

0

192.168.1.64

G


Directly connected

RIB looks at the mask length first. The directly connected prefix with the shortest mask length is considered last as the longer the mask, the more accurate the prefix.

Conclusion

With the same prefix and different mask lengths, the border router considers the following criteria in order of preference:

  1. Longest mask among all routing protocols
  2. Lowest cost with the same routing protocol
%d bloggers like this: