ardenpackeer.com » Routing Protocols

Tutorial: BGP Route Aggregation Part 1 – Using an Advertise-Map to control aggregation

Arden Packeer, CCIE #20716 — Sun, 18 Jan 2009 23:56:23 +0000

BGP Route Aggregation is not only an important topic to learn for the CCIE exam, its what keeps the internet routing tables manageable. The basic idea is simple, instead of BGP advertising lots of different prefixes, we can summarize individual prefixes as an aggregate. In this series of articles we will be looking at BGP Route Aggregation using various methods that you should be familiar with before attempting the CCIE lab in case one of those evil proctors decides to limit the use of one or the other.

In this article we will be introducing the aggregate-address command to create route aggregates. We will be using the following topology for this tutorial:

Dynagen .net Configuration File:

ghostios = True
sparsemem = True
model = 3640

[localhost]

    [[3640]]
        image = \Program Files\Dynamips\images\c3640-jk9o3s-mz.124-12.bin
        # On Linux / Unix use forward slashes:
        # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
        ram = 128

        [[router R1]]
                model = 3640
                console = 2000
                e1/0 = LAN 12

        [[router R2]]
                model = 3640
                console = 2001
                e1/0 = LAN 12
                e1/1 = LAN 23
                e1/2 = LAN 24

        [[router R3]]
                model = 3640
                console = 2002
                e1/0 = LAN 23

        [[router R4]]
                model = 3640
                console = 2003
                e1/0 = LAN 24

You can download the pre-configured .net dynagen configuration file for this tutorial here.

Basic Configuration

Let’s take a look at the basic configuration for this topology:

hostname R1
!
interface Loopback0
 ip address 10.0.0.1 255.255.255.0
!
interface Loopback1
 ip address 10.0.1.1 255.255.255.0
!
interface Ethernet1/0
 ip address 192.168.12.1 255.255.255.0
 full-duplex
 no shut
!
router bgp 1
 no synchronization
 bgp router-id 1.1.1.1
 network 10.0.0.0 mask 255.255.255.0
 network 10.0.1.0 mask 255.255.255.0
 neighbor 192.168.12.2 remote-as 2
 no auto-summary

hostname R2
!
interface Ethernet1/0
 ip address 192.168.12.2 255.255.255.0
 full-duplex
 no shut
!
interface Ethernet1/1
 ip address 192.168.23.2 255.255.255.0
 full-duplex
 no shut
!
interface Ethernet1/2
 ip address 192.168.24.2 255.255.255.0
 full-duplex
 no shut
!
router bgp 2
 no synchronization
 bgp router-id 2.2.2.2
 neighbor 192.168.12.1 remote-as 1
 neighbor 192.168.23.3 remote-as 3
 neighbor 192.168.24.4 remote-as 4
 no auto-summary

hostname R3
!
interface Loopback0
 ip address 10.0.2.1 255.255.255.0
!
interface Loopback1
 ip address 10.0.3.1 255.255.255.0
!
interface Ethernet1/0
 ip address 192.168.23.3 255.255.255.0
 full-duplex
 no shut
!
router bgp 3
 no synchronization
 bgp router-id 3.3.3.3
 network 10.0.2.0 mask 255.255.255.0
 network 10.0.3.0 mask 255.255.255.0
 neighbor 192.168.23.2 remote-as 2
 no auto-summary

hostname R4
!
interface Ethernet1/0
 ip address 192.168.24.4 255.255.255.0
 full-duplex
 no shut
!
router bgp 4
 no synchronization
 bgp router-id 4.4.4.4
 bgp log-neighbor-changes
 neighbor 192.168.24.2 remote-as 2
 no auto-summary

You can see in the configuration above we have four routers: R1, R2, R3 and R4 each in their own AS. R1 has two loopbacks defined which it is advertising into BGP. R3 also has two loopbacks defined which it is also advertising into BGP. Lets verify these advertised BGP prefixes:

R1#sh ip bgp
BGP table version is 5, 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
*> 10.0.0.0/24      0.0.0.0                  0         32768 i
*> 10.0.1.0/24      0.0.0.0                  0         32768 i
*> 10.0.2.0/24      192.168.12.2                           0 2 3 i
*> 10.0.3.0/24      192.168.12.2                           0 2 3 i

R2#sh ip bgp
BGP table version is 5, local router ID is 2.2.2.2
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
*> 10.0.0.0/24      192.168.12.1             0             0 1 i
*> 10.0.1.0/24      192.168.12.1             0             0 1 i
*> 10.0.2.0/24      192.168.23.3             0             0 3 i
*> 10.0.3.0/24      192.168.23.3             0             0 3 i

R3#sh ip bgp
BGP table version is 5, local router ID is 3.3.3.3
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
*> 10.0.0.0/24      192.168.23.2                           0 2 1 i
*> 10.0.1.0/24      192.168.23.2                           0 2 1 i
*> 10.0.2.0/24      0.0.0.0                  0         32768 i
*> 10.0.3.0/24      0.0.0.0                  0         32768 i

R4#sh ip bgp
BGP table version is 5, local router ID is 4.4.4.4
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
*> 10.0.0.0/24      192.168.24.2                           0 2 1 i
*> 10.0.1.0/24      192.168.24.2                           0 2 1 i
*> 10.0.2.0/24      192.168.24.2                           0 2 3 i
*> 10.0.3.0/24      192.168.24.2                           0 2 3 i

You can see clearly above that the networks have been advertised into BGP. Let’s verify connectivity.

R1#ping 10.0.2.1 source 10.0.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.2.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 116/213/296 ms

Looks like we have connectivity from the networks that R1 is advertising (10.0.0.0/24 and 10.0.1.0/24) and the networks that R3 is advertising (10.0.2.0/24 and 10.0.3.0/24). We haven’t run an IGP here as we don’t usually have an IGP running between AS’s (thats the whole purpose of BGP!). When we did the ping, we have to source the address from R1’s loopback for connectivity. If we didn’t do that the source address of the ping packet would be 192.168.12.1, which R3 does not have a route for. We can run an IGP protocol here, but it is not needed for these examples.

Basic BGP Aggregation using the aggregate-address command

Lets do some aggregation! We will be using the aggregate-address command to create a summary.

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router bgp 2
R2(config-router)#aggregate-address 10.0.0.0 255.255.252.0

We have created an aggregrate address on R2 here that summarizes the 10.0.0.0/24, 10.0.1.0/24, 10.0.2.0/24 and 10.0.3.0/24 networks. If you look at the four networks in binary we get:

10.0.0.0/24 = 00001010.00000000.00000000.00000000
10.0.1.0/24 = 00001010.00000000.00000001.00000000
10.0.2.0/24 = 00001010.00000000.00000010.00000000
10.0.3.0/24 = 00001010.00000000.00000011.00000000

The first 22 bits of these are common, hence an aggregate of 10.0.0.0/22.

One of the first things we need to remember is that we cannot aggregate an address unless at least one of the more specific routes we are trying to aggregate exists in the routing table already. If all the prefixes that we are summarizing in our aggregate go down, the router will remove the aggregate from the BGP table.

Let’s verify the aggregate:

R2#sh ip bgp
BGP table version is 6, local router ID is 2.2.2.2
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
*> 10.0.0.0/24      192.168.12.1             0             0 1 i
*> 10.0.0.0/22      0.0.0.0                            32768 i
*> 10.0.1.0/24      192.168.12.1             0             0 1 i
*> 10.0.2.0/24      192.168.23.3             0             0 3 i
*> 10.0.3.0/24      192.168.23.3             0             0 3 i

R2#sh ip route | b Gateway
Gateway of last resort is not set

C    192.168.12.0/24 is directly connected, Ethernet1/0
C    192.168.24.0/24 is directly connected, Ethernet1/2
     10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B       10.0.2.0/24 [20/0] via 192.168.23.3, 00:10:57
B       10.0.3.0/24 [20/0] via 192.168.23.3, 00:10:57
B       10.0.0.0/24 [20/0] via 192.168.12.1, 00:10:57
B       10.0.0.0/22 [200/0] via 0.0.0.0, 00:10:57, Null0
B       10.0.1.0/24 [20/0] via 192.168.12.1, 00:10:57
C    192.168.23.0/24 is directly connected, Ethernet1/1

Looking at the routing table above we can see that we have an entry in the routing table to Null0 on R2.

Null0 – The road to nowhere

Why does an aggregate create an entry to Null0? Good question lets think about this. Say we had this scenario:

On R3 lets say we created 4 more loopbacks that we advertise into BGP: 150.0.0.0/24, 150.0.1.0/24, 150.0.2.0/24, 150.0.3.0/24.

R3(config)#int lo10
R3(config-if)#ip add 150.0.0.1 255.255.255.0
R3(config-if)#int lo11
R3(config-if)#ip add 150.0.1.1 255.255.255.0
R3(config-if)#int lo12
R3(config-if)#ip add 150.0.2.1 255.255.255.0
R3(config-if)#int lo13
R3(config-if)#ip add 150.0.3.1 255.255.255.0
R3(config-if)#router bgp 3
R3(config-router)#network 150.0.0.0 mask 255.255.255.0
R3(config-router)#network 150.0.1.0 mask 255.255.255.0
R3(config-router)#network 150.0.2.0 mask 255.255.255.0
R3(config-router)#network 150.0.3.0 mask 255.255.255.0

R2#sh ip bgp
BGP table version is 10, local router ID is 2.2.2.2
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
*> 10.0.0.0/24      192.168.12.1             0             0 1 i
*> 10.0.0.0/22      0.0.0.0                            32768 i
*> 10.0.1.0/24      192.168.12.1             0             0 1 i
*> 10.0.2.0/24      192.168.23.3             0             0 3 i
*> 10.0.3.0/24      192.168.23.3             0             0 3 i
*> 150.0.0.0/24     192.168.23.3             0             0 3 i
*> 150.0.1.0/24     192.168.23.3             0             0 3 i
*> 150.0.2.0/24     192.168.23.3             0             0 3 i
*> 150.0.3.0/24     192.168.23.3             0             0 3 i

R2 then aggregates this as 150.0.0.0/22 and creates a Null0 route in its routing table.

R2(config)#router bgp 2
R2(config-router)#aggregate-address 150.0.0.0  255.255.252.0

R2#sh ip route | b Gateway
Gateway of last resort is not set

C    192.168.12.0/24 is directly connected, Ethernet1/0
C    192.168.24.0/24 is directly connected, Ethernet1/2
     10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B       10.0.2.0/24 [20/0] via 192.168.23.3, 00:48:15
B       10.0.3.0/24 [20/0] via 192.168.23.3, 00:48:15
B       10.0.0.0/24 [20/0] via 192.168.12.1, 00:48:15
B       10.0.0.0/22 [200/0] via 0.0.0.0, 00:30:07, Null0
B       10.0.1.0/24 [20/0] via 192.168.12.1, 00:48:15
C    192.168.23.0/24 is directly connected, Ethernet1/1
     150.0.0.0/16 is variably subnetted, 5 subnets, 2 masks
B       150.0.2.0/24 [20/0] via 192.168.23.3, 00:12:54
B       150.0.3.0/24 [20/0] via 192.168.23.3, 00:12:54
B       150.0.0.0/24 [20/0] via 192.168.23.3, 00:13:24
B       150.0.0.0/22 [200/0] via 0.0.0.0, 00:12:01, Null0
B       150.0.1.0/24 [20/0] via 192.168.23.3, 00:01:31

This aggregate is then passed it on to R1. Lets also say that R2 has a default gateway set to R1.

R2(config)#ip route 0.0.0.0 0.0.0.0 192.168.12.1

R2#sh ip route | b Gateway
Gateway of last resort is 192.168.12.1 to network 0.0.0.0

C    192.168.12.0/24 is directly connected, Ethernet1/0
C    192.168.24.0/24 is directly connected, Ethernet1/2
     10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B       10.0.2.0/24 [20/0] via 192.168.23.3, 00:50:08
B       10.0.3.0/24 [20/0] via 192.168.23.3, 00:50:08
B       10.0.0.0/24 [20/0] via 192.168.12.1, 00:50:08
B       10.0.0.0/22 [200/0] via 0.0.0.0, 00:32:00, Null0
B       10.0.1.0/24 [20/0] via 192.168.12.1, 00:50:08
C    192.168.23.0/24 is directly connected, Ethernet1/1
     150.0.0.0/16 is variably subnetted, 5 subnets, 2 masks
B       150.0.2.0/24 [20/0] via 192.168.23.3, 00:14:46
B       150.0.3.0/24 [20/0] via 192.168.23.3, 00:14:46
B       150.0.0.0/24 [20/0] via 192.168.23.3, 00:15:17
B       150.0.0.0/22 [200/0] via 0.0.0.0, 00:13:53, Null0
B       150.0.1.0/24 [20/0] via 192.168.23.3, 00:03:24
S*   0.0.0.0/0 [1/0] via 192.168.12.1

What would happen if the network 150.0.1.0/24 went down on R3 and we didn’t have that Null0 route on R2?
R3

R3(config)#int lo11
R3(config-if)#shut

R2#sh ip bgp
BGP table version is 14, local router ID is 2.2.2.2
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
*> 10.0.0.0/24      192.168.12.1             0             0 1 i
*> 10.0.0.0/22      0.0.0.0                            32768 i
*> 10.0.1.0/24      192.168.12.1             0             0 1 i
*> 10.0.2.0/24      192.168.23.3             0             0 3 i
*> 10.0.3.0/24      192.168.23.3             0             0 3 i
*> 150.0.0.0/24     192.168.23.3             0             0 3 i
*> 150.0.0.0/22     0.0.0.0                            32768 i
*> 150.0.2.0/24     192.168.23.3             0             0 3 i
*> 150.0.3.0/24     192.168.23.3             0             0 3 i

R2#sh ip route | b Gateway
Gateway of last resort is 192.168.12.1 to network 0.0.0.0

C    192.168.12.0/24 is directly connected, Ethernet1/0
C    192.168.24.0/24 is directly connected, Ethernet1/2
     10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
B       10.0.2.0/24 [20/0] via 192.168.23.3, 00:51:18
B       10.0.3.0/24 [20/0] via 192.168.23.3, 00:51:18
B       10.0.0.0/24 [20/0] via 192.168.12.1, 00:51:18
B       10.0.0.0/22 [200/0] via 0.0.0.0, 00:33:10, Null0
B       10.0.1.0/24 [20/0] via 192.168.12.1, 00:51:18
C    192.168.23.0/24 is directly connected, Ethernet1/1
     150.0.0.0/16 is variably subnetted, 4 subnets, 2 masks
B       150.0.2.0/24 [20/0] via 192.168.23.3, 00:15:57
B       150.0.3.0/24 [20/0] via 192.168.23.3, 00:15:57
B       150.0.0.0/24 [20/0] via 192.168.23.3, 00:16:27
S*   0.0.0.0/0 [1/0] via 192.168.12.1

Well R1 pings 150.0.1.1, the Aggregate will be matched on R1’s routing table. It will be received on R2. The route for 150.0.1.0/24 is missing. Remember there is no Null0 route here, so what will R2 match? The default gateway! So it will send it back to R1. R1 will then send to R2. Ladies and Gentleman we have a routing loop! This is one of the reasons we create a Null0 route on R2 when an aggregate is generated.

Let’s clean up and get back to our aggregate for 10.0.0.0/22 on R2 and take a look at the atomic-aggregate attribute.

R3(config)#no int lo10
R3(config)#no int lo11

R3(config)#no int lo12
R3(config)#no int lo13
R3(config)#router bgp 3
R3(config-router)#no network 150.0.0.0 mask 255.255.255.0
R3(config-router)#no network 150.0.1.0 mask 255.255.255.0
R3(config-router)#no network 150.0.2.0 mask 255.255.255.0
R3(config-router)#no network 150.0.3.0 mask 255.255.255.0

R2(config)#router bgp 2
R2(config-router)#no aggregate-address 150.0.0.0 255.255.252.0

Atomic-Aggregate

I gotta admit, Atomic-Aggregate sounds kinda cool. Like an Aggregate with superpowers or something :). But what the hell is it and what does it have to do with BGP aggregation? Take a look at the output below:

R2#sh ip bgp 10.0.0.0/22
BGP routing table entry for 10.0.0.0/22, version 6
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to update-groups:
     1
  Local, (aggregated by 2 2.2.2.2)
    0.0.0.0 from 0.0.0.0 (2.2.2.2)
      Origin IGP, localpref 100, weight 32768, valid, aggregated, local, atomic-aggregate, best

You can see above that R2 has now originated an entry in BGP for the 10.0.0.0/22 aggregate. You can see also that the aggregate has the atomic-aggregate attribute set. What this means is that the AS path information about the aggregate has been lost. What do I mean by that?

Lets take a look at the BGP tables on R1.

R1#sh ip bgp
BGP table version is 18, 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
*> 10.0.0.0/24      0.0.0.0                  0         32768 i
*> 10.0.0.0/22      192.168.12.2             0             0 2 i
*> 10.0.1.0/24      0.0.0.0                  0         32768 i
*> 10.0.2.0/24      192.168.12.2                           0 2 3 i
*> 10.0.3.0/24      192.168.12.2                           0 2 3 i

Look at the output above we can see that the path information for the 10.0.0.0/22 prefix only contains AS 2!

R1#sh ip bgp 10.0.0.0/22
BGP routing table entry for 10.0.0.0/22, version 6
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  2, (aggregated by 2 2.2.2.2)
    192.168.12.2 from 192.168.12.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, external, atomic-aggregate, best

You can see that R1 thinks the 10.0.0.0/22 network originated in AS 2. The networks in that aggregate however originated in AS 1, and AS 3. By aggregating on R2 we have lost that information. So all an atomic-aggregate attribute on an aggregate route says is “I’ve lost all the as-path information for the routes that I am aggregating”.

Lets look a bit closer at the BGP table on R2:

R2#sh ip bgp
BGP table version is 6, local router ID is 2.2.2.2
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
*> 10.0.0.0/24      192.168.12.1             0             0 1 i
*> 10.0.0.0/22      0.0.0.0                            32768 i
*> 10.0.1.0/24      192.168.12.1             0             0 1 i
*> 10.0.2.0/24      192.168.23.3             0             0 3 i
*> 10.0.3.0/24      192.168.23.3             0             0 3 i

You can see there that the 10.0.0.0/22 route has lost the as-path information. The atomic-aggregate attribute has been set so we don’t see the complete as-path for the prefixes contained within that aggregate.

This situation can also be seen on R3 and R4:

R3#sh ip bgp
BGP table version is 6, local router ID is 3.3.3.3
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
*> 10.0.0.0/24      192.168.23.2                           0 2 1 i
*> 10.0.0.0/22      192.168.23.2             0             0 2 i
*> 10.0.1.0/24      192.168.23.2                           0 2 1 i
*> 10.0.2.0/24      0.0.0.0                  0         32768 i
*> 10.0.3.0/24      0.0.0.0                  0         32768 i

R4#sh ip bgp
BGP table version is 6, local router ID is 4.4.4.4
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
*> 10.0.0.0/24      192.168.24.2                           0 2 1 i
*> 10.0.0.0/22      192.168.24.2             0             0 2 i
*> 10.0.1.0/24      192.168.24.2                           0 2 1 i
*> 10.0.2.0/24      192.168.24.2                           0 2 3 i
*> 10.0.3.0/24      192.168.24.2                           0 2 3 i

How can we retain the as-path information?

Using the as-set keyword

The as-path paramter for the aggregate-address command allows us to create an BGP aggregate without setting the atomic-aggregate attribute. This allows us to see the as-path of the routes we are aggregating.

Let’s take a look at the configuration:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#router bgp 2
R2(config-router)#aggregate-address 10.0.0.0 255.255.252.0 as-set

Simple configuration huh? Just add the as-set keyword to the aggregate-address command. Let’s verify this and take a look at the effects this has on our BGP tables.

R2#sh ip bgp 10.0.0.0 255.255.252.0
BGP routing table entry for 10.0.0.0/22, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to update-groups:
     1
  {1,3}, (aggregated by 2 2.2.2.2)
    0.0.0.0 from 0.0.0.0 (2.2.2.2)
      Origin IGP, localpref 100, weight 32768, valid, aggregated, local, best

You can see above we have that the route is originated on R2 but it has a {1,3} in the as-path information. This means that 10.0.0.0/22 is an aggregate of prefixes that went through AS 1 and AS 3. Also notice, that the atomic-aggregate attribute is no longer set as no AS information for the aggregate has been lost.

What will this do to our BGP routing tables? Lets take a look at the routing table on R1:

R1#sh ip bgp
BGP table version is 7, 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
*> 10.0.0.0/24      0.0.0.0                  0         32768 i
*> 10.0.1.0/24      0.0.0.0                  0         32768 i
*> 10.0.2.0/24      192.168.12.2                           0 2 3 i
*> 10.0.3.0/24      192.168.12.2                           0 2 3 i

Take a look carefully at the output above. Hey wait a minute, we don’t have the aggregate anymore. Did we stuff up our configuration? Is R2 even advertising the prefixes?

R2#sh ip bgp neighbors 192.168.12.1 advertised-routes
BGP table version is 7, local router ID is 2.2.2.2
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
*> 10.0.0.0/24      192.168.12.1             0             0 1 i
*> 10.0.0.0/22      0.0.0.0                       100  32768 {1,3} i
*> 10.0.1.0/24      192.168.12.1             0             0 1 i
*> 10.0.2.0/24      192.168.23.3             0             0 3 i
*> 10.0.3.0/24      192.168.23.3             0             0 3 i

Total number of prefixes 5

R2#sh ip bgp neighbors 192.168.23.3 advertised-routes
BGP table version is 7, local router ID is 2.2.2.2
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
*> 10.0.0.0/24      192.168.12.1             0             0 1 i
*> 10.0.0.0/22      0.0.0.0                       100  32768 {1,3} i
*> 10.0.1.0/24      192.168.12.1             0             0 1 i
*> 10.0.2.0/24      192.168.23.3             0             0 3 i
*> 10.0.3.0/24      192.168.23.3             0             0 3 i

Total number of prefixes 5

R2 is advertising the prefixes but R1 and R3 are not accepting them! What gives? Actually, this is expected behaviour. What the rule with BGP when a router sees its own AS number in the AS-PATH? It doesn’t accept the route!

R2#sh ip bgp
BGP table version is 7, local router ID is 2.2.2.2
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
*> 10.0.0.0/24      192.168.12.1             0             0 1 i
*> 10.0.0.0/22      0.0.0.0                       100  32768 {1,3} i
*> 10.0.1.0/24      192.168.12.1             0             0 1 i
*> 10.0.2.0/24      192.168.23.3             0             0 3 i
*> 10.0.3.0/24      192.168.23.3             0             0 3 i

On R2, we can clearly see that the AS path of the aggregate now contains all the AS’s of the routes that it is summarizing.

R3#sh ip bgp
BGP table version is 7, local router ID is 3.3.3.3
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
*> 10.0.0.0/24      192.168.23.2                           0 2 1 i
*> 10.0.1.0/24      192.168.23.2                           0 2 1 i
*> 10.0.2.0/24      0.0.0.0                  0         32768 i
*> 10.0.3.0/24      0.0.0.0                  0         32768 i

R3 doesn’t accept the route because it sees its own AS 3 in the path for 10.0.0.0/22.

R4#sh ip bgp
BGP table version is 7, local router ID is 4.4.4.4
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
*> 10.0.0.0/24      192.168.24.2                           0 2 1 i
*> 10.0.0.0/22      192.168.24.2             0             0 2 {1,3} i
*> 10.0.1.0/24      192.168.24.2                           0 2 1 i
*> 10.0.2.0/24      192.168.24.2                           0 2 3 i
*> 10.0.3.0/24      192.168.24.2                           0 2 3 i

R4 however accepts the route as it does not see its own AS in the aggregate. Cool huh?

Controlling the BGP aggregrate using advertise-map

Using the advertise-map option on the aggregate-address command allows us to control which routes make up the summary address. We can use this to say which prefixes make up the aggregate address.

Lets take a look at an example:
R2

router bgp 2
 no synchronization
 bgp router-id 2.2.2.2
 aggregate-address 10.0.0.0 255.255.252.0 as-set advertise-map AS_3_PREFIXES
 neighbor 192.168.12.1 remote-as 1
 neighbor 192.168.23.3 remote-as 3
 neighbor 192.168.24.4 remote-as 4
 no auto-summary
!
access-list 1 permit 10.0.2.0 0.0.0.255
access-list 1 permit 10.0.3.0 0.0.0.255
!
route-map AS_3_PREFIXES permit 10
 match ip address 1

We have created an access list that matches the 10.0.2.0/24, and 10.0.3.0/24 prefixes. Both of these prefixes are originated in AS 3. This access list is then associated with the route-map AS_3_PREFIXES. We call this route-map in the aggregate-address advertise-map command.

Notice we also have the as-set command so the atomic-aggregate will be set.

Lets take a look at the summary address that this creates.

R2#sh ip bgp 10.0.0.0/22
BGP routing table entry for 10.0.0.0/22, version 8
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Advertised to update-groups:
     1
  3, (aggregated by 2 2.2.2.2)
    0.0.0.0 from 0.0.0.0 (2.2.2.2)
      Origin IGP, localpref 100, weight 32768, valid, aggregated, local, atomic-aggregate, best

Notice that the AS-PATH information only has AS 3 in the path list. This is because when we created the aggregate address we told the router that “this aggregate is a summary of 10.0.2.0/24 and 10.0.3.0/24″. These prefixes only originate in AS 3 so thats all that goes in the path list! Also notice that the atomic-aggregate attribute is set. This is because information for the aggregate has been lost (ie. we don’t include AS 1’s prefixes).

R1#sh ip bgp
BGP table version is 8, 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
*> 10.0.0.0/24      0.0.0.0                  0         32768 i
*> 10.0.0.0/22      192.168.12.2             0             0 2 3 i
*> 10.0.1.0/24      0.0.0.0                  0         32768 i
*> 10.0.2.0/24      192.168.12.2                           0 2 3 i
*> 10.0.3.0/24      192.168.12.2                           0 2 3 i

You can see above that R1 now accepts this aggregate as it no longer sees its own AS in the path.

R2#sh ip bgp
BGP table version is 8, local router ID is 2.2.2.2
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
*> 10.0.0.0/24      192.168.12.1             0             0 1 i
*> 10.0.0.0/22      0.0.0.0                       100  32768 3 i
*> 10.0.1.0/24      192.168.12.1             0             0 1 i
*> 10.0.2.0/24      192.168.23.3             0             0 3 i
*> 10.0.3.0/24      192.168.23.3             0             0 3 i

R3#sh ip bgp
BGP table version is 7, local router ID is 3.3.3.3
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
*> 10.0.0.0/24      192.168.23.2                           0 2 1 i
*> 10.0.1.0/24      192.168.23.2                           0 2 1 i
*> 10.0.2.0/24      0.0.0.0                  0         32768 i
*> 10.0.3.0/24      0.0.0.0                  0         32768 i

R3 does not accept the path. Why? Because it saw its own AS in the update.

R4#sh ip bgp
BGP table version is 17, local router ID is 4.4.4.4
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
*> 10.0.0.0/24      192.168.24.2                           0 2 1 i
*> 10.0.0.0/22      192.168.24.2             0             0 2 3 i
*> 10.0.1.0/24      192.168.24.2                           0 2 1 i
*> 10.0.2.0/24      192.168.24.2                           0 2 3 i
*> 10.0.3.0/24      192.168.24.2                           0 2 3 i

R4 happily accepts the update. Notice the AS path looks like it originated from AS 3.

Why might this stuff come in handy? Well imagine those evil CCIE proctors as you to filter BGP updates but you are not allowed to use the traditional means (filter-lists etc). This just gives you another tool that you can add to your belt!

In our next article we will be looking at suppress-maps and attribute-maps as well as few other cool little things with BGP aggregation. Stay tuned!

HTH. Now back to labs!

Summary:

BGP can summaries prefixes with the aggregate-address command
When an aggregate is created, a Null0 route is entered into the routing table to stop routing loops.
By default, the aggregate will be originated from the AS creating the aggregate. All AS-PATH information about prefixes contained within the aggregate is lost.
When AS-PATH information is lost, the atomic-aggregate attribute is set on the aggregate.
We can control what prefixes make up the aggregate using the advertise-map parameter on the aggregate-address command.

Resources:

Dynamips/Dynagen .net configuration file

Read this article and more like it on ardenpackeer.com
Follow me on twitter: http://twitter.com/ardenpackeer

Tutorial: BGP Route Aggregation Part 1 – Using an Advertise-Map to control aggregation

Tutorial: Filtering Routes in OSPF Part 2 » Filtering Between Areas Using area filter-list

Arden Packeer, CCIE #20716 — Sun, 10 Aug 2008 02:33:02 +0000

In our last article on Filtering Routes in OSPF we looked at filtering routes within an OSPF area. In this article we will be filtering routes between areas using the area filter-list command. OSPF route filtering is an important concept to be familiar with for any CCIE candidate. We will be looking at the area filter-list command first. Part 3 will then look at some of the more obtuse ways of filtering using the area range and summary-address commands. Part of being a CCIE is knowing multiple ways of configuring the same task…just in case those evil proctors decide to restrict which of those methods you can and can’t do! :)

We will be using the following topology for this tutorial:

Dynagen .net Configuration File:

ghostios = True
sparsemem = True
model = 3640

[localhost]

    [[3640]]
        image = \Program Files\Dynamips\images\c3640-jk9o3s-mz.124-12.bin
        # On Linux / Unix use forward slashes:
        # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
        ram = 128

    [[ROUTER R1]]
        console = 2000
        e1/0 = LAN 13
        e1/1 = LAN 12
        autostart = False
        model = 3640

    [[ROUTER R2]]
        console = 2001
        e1/0 = LAN 23
        e1/1 = LAN 12
        autostart = False
        model = 3640

    [[ROUTER R3]]
        console = 2002
        e1/0 = LAN 13
        e1/1 = LAN 23
        e1/2 = LAN 34
        autostart = False
        model = 3640

    [[ROUTER R4]]
        console = 2003
        e1/0 = LAN 45
        e1/1 = LAN 46
        e1/2 = LAN 34
        autostart = False
        model = 3640

    [[ROUTER R5]]
        console = 2004
        e1/0 = LAN 45
        e1/1 = LAN 56
        autostart = False
        model = 3640

    [[ROUTER R6]]
        console = 2005
        e1/0 = LAN 46
        e1/1 = LAN 56
        autostart = False
        model = 3640

You can download the pre-configured .net dynagen configuration file for this tutorial here.

Basic Configuration

First things first lets set up our basic topology. In this topology R1 and R2 will be internal area 2 routers with R3 the Area Border Router (ABR) between area 2 and area 0. R5 and R6 will be internal area 1 routers with R4 the ABR between area 1 and area 0.

Lets take at this configuration:

R1:

hostname R1
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface Ethernet1/0
 ip address 10.2.13.1 255.255.255.0
!
interface Ethernet1/1
 ip address 10.2.12.1 255.255.255.0
!
router ospf 1
 router-id 1.1.1.1
 log-adjacency-changes
 network 1.1.1.1 0.0.0.0 area 2
 network 10.2.12.1 0.0.0.0 area 2
 network 10.2.13.1 0.0.0.0 area 2

R2:

hostname R2
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface Ethernet1/0
 ip address 10.2.23.2 255.255.255.0
!
interface Ethernet1/1
 ip address 10.2.12.2 255.255.255.0
!
router ospf 1
 router-id 2.2.2.2
 log-adjacency-changes
 network 2.2.2.2 0.0.0.0 area 2
 network 10.2.12.2 0.0.0.0 area 2
 network 10.2.23.2 0.0.0.0 area 2

R3:

hostname R3
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface Ethernet1/0
 ip address 10.2.13.3 255.255.255.0
!
interface Ethernet1/1
 ip address 10.2.23.3 255.255.255.0
!
interface Ethernet1/2
 ip address 10.0.34.3 255.255.255.0
!
router ospf 1
 router-id 3.3.3.3
 log-adjacency-changes
 network 3.3.3.3 0.0.0.0 area 0
 network 10.0.34.3 0.0.0.0 area 0
 network 10.2.13.3 0.0.0.0 area 2
 network 10.2.23.3 0.0.0.0 area 2

R4:

hostname R4
!
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
!
interface Ethernet1/0
 ip address 10.1.45.4 255.255.255.0
!
interface Ethernet1/1
 ip address 10.1.46.4 255.255.255.0
!
interface Ethernet1/2
 ip address 10.0.34.4 255.255.255.0
!
router ospf 1
 router-id 4.4.4.4
 log-adjacency-changes
 network 4.4.4.4 0.0.0.0 area 0
 network 10.0.34.4 0.0.0.0 area 0
 network 10.1.45.4 0.0.0.0 area 1
 network 10.1.46.4 0.0.0.0 area 1

R5:

hostname R5
!
interface Loopback0
 ip address 5.5.5.5 255.255.255.255
!
interface Ethernet1/0
 ip address 10.1.45.5 255.255.255.0
!
interface Ethernet1/1
 ip address 10.1.56.5 255.255.255.0
!
router ospf 1
 router-id 5.5.5.5
 log-adjacency-changes
 network 5.5.5.5 0.0.0.0 area 1
 network 10.1.45.5 0.0.0.0 area 1
 network 10.1.56.5 0.0.0.0 area 1

R6:

hostname R6
!
interface Loopback0
 ip address 6.6.6.6 255.255.255.255
!
interface Ethernet1/0
 ip address 10.1.46.6 255.255.255.0
!
interface Ethernet1/1
 ip address 10.1.56.6 255.255.255.0
!
router ospf 1
 router-id 6.6.6.6
 log-adjacency-changes
 network 6.6.6.6 0.0.0.0 area 1
 network 10.1.46.6 0.0.0.0 area 1
 network 10.1.56.6 0.0.0.0 area 1

We have added a loopback interface on each device and advertised them into OSPF. R1 and R2’s Loopback0 interfaces have been added to area 2. R3 and R4’s Loopback0 interfaces have been added to Area 0. R5 and R6’s Loopback0 interfaces have been added to Area 1.

Let’s verify the routing table on R5 and test connectivity before we start filtering routes.

R5#sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/31] via 10.1.45.4, 00:05:51, Ethernet1/0
     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/31] via 10.1.45.4, 00:05:51, Ethernet1/0
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/21] via 10.1.45.4, 00:05:51, Ethernet1/0
     4.0.0.0/32 is subnetted, 1 subnets
O IA    4.4.4.4 [110/11] via 10.1.45.4, 00:05:51, Ethernet1/0
     5.0.0.0/32 is subnetted, 1 subnets
C       5.5.5.5 is directly connected, Loopback0
     6.0.0.0/32 is subnetted, 1 subnets
O       6.6.6.6 [110/11] via 10.1.56.6, 00:05:51, Ethernet1/1
     10.0.0.0/24 is subnetted, 7 subnets
O IA    10.2.12.0 [110/40] via 10.1.45.4, 00:05:51, Ethernet1/0
O IA    10.2.13.0 [110/30] via 10.1.45.4, 00:05:51, Ethernet1/0
O IA    10.2.23.0 [110/30] via 10.1.45.4, 00:05:51, Ethernet1/0
O       10.1.46.0 [110/20] via 10.1.56.6, 00:05:51, Ethernet1/1
                  [110/20] via 10.1.45.4, 00:05:51, Ethernet1/0
C       10.1.45.0 is directly connected, Ethernet1/0
O IA    10.0.34.0 [110/20] via 10.1.45.4, 00:05:51, Ethernet1/0
C       10.1.56.0 is directly connected, Ethernet1/1

The routing table looks correct. We have inter-area routes to R1, R2, R3 and R4’s loopback0 addresses as well as to the 10.2.12.0/24, 10.2.13.0/24, 10.2.23.0/24 and 10.0.34.0/24 networks. Exactly what we would expect.

Let’s verify connectivity:

R5#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 216/245/284 ms

Looks like we have full connectivity. Awesome!

OSPF – Distance Vector or Link State?

Remember back to when you were studying for your CCNA. If you took a course, the instructor probably blabbed on about the difference between Link State and Distance Vector routing protocols (I know I spend a large amount of time on this when I am teaching it!). In a nutshell, with Distance Vector routing protocols the routers cannot “see” past their neighbors. They rely on their neighbors to tell them everything. In turn they tell their neighbors everything they have learned so far.

With Link State routing protocols, the routers tell everyone (via a multicast exchange) information about itself, its links, and its neighbors (This is a massive simplification, but it will do for now). Link State Routers take this information and create a link state database. This database is identical for all routers. Based on this information each router use the Dijikstra’s shortest path algorithm to independantly calculate the shortest path.

Now if we had a large number of routers, this would make the size of that database massive. In “the old days” this was a problem because memory and cpu power was limited. So we break up that database into areas. This allows OSPF to scale to larger networks. The routers in an area maintain a linkstate database for their area. This database should be identical for all other routers in the same area. So there is a database for each area.

Each area is connected to another area via an ABR (Area Border Router). The ABR will have databases for two or more areas. This is where things get funky. The routers within an area inherently know how to get to other routers within the same area. The topology database will tell them. But how do they get to routers in another area. They cannot “see” past their own area. They rely on the ABR to tell them about routes to other areas. Hang on a sec doesn’t that sound a bit like Distance Vector?

In Distance Vector routing protocols, routers cannot “see” past their neighbors. They rely on there neighbors to tell them everything. This is the same as routers in different areas in OSPF. Internal area routers cannot “see” past their areas! They rely on the ABR to tell them everything about other areas. OSPF is a link state protocol within an area. OSPF can be considered a distance vector protocol between areas.

Think about this. Because we are relying on the ABR to tell our internal routers everything outside the area, we must ensure a loop free topology between areas. Hence the reason why all areas must attach to Area 0. By forcing all areas to touch Area 0 in a kind of floral petal arrangement, where area 0 is the center of the flower and the other areas are the petals, we can ensure that no loops will be formed between areas!

An ABR will summarize routes from other areas and create an LSA (Link State Advertisements) type 3 before sending it into the area.

You can see in the diagram above R3 will create a type 3 summary LSA’s for the networks in Area 1 and Area 0 and send it into area 2. R3 will also create a type 3 summary LSA for the the networks in area 2 and send it out of area 2. The direction there is important because it will come into play later when we filter these routes.

We can verify this on R1 by taking a look at the database:

R1#sh ip ospf database

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

                Router Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         444         0x80000004 0x0094F2 3
2.2.2.2         2.2.2.2         435         0x80000004 0x00CF95 3
3.3.3.3         3.3.3.3         401         0x80000003 0x00323F 2

                Net Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum
10.2.12.2       2.2.2.2         435         0x80000002 0x00A466
10.2.13.3       3.3.3.3         401         0x80000002 0x00936D
10.2.23.3       3.3.3.3         401         0x80000002 0x00579B

                Summary Net Link States (Area 2)

Link ID         ADV Router      Age         Seq#       Checksum
3.3.3.3         3.3.3.3         401         0x80000002 0x00AC76
4.4.4.4         3.3.3.3         401         0x80000002 0x00E232
5.5.5.5         3.3.3.3         401         0x80000002 0x0019ED
6.6.6.6         3.3.3.3         401         0x80000002 0x00EA18
10.0.34.0       3.3.3.3         402         0x80000002 0x009762
10.1.45.0       3.3.3.3         402         0x80000002 0x00766D
10.1.46.0       3.3.3.3         402         0x80000002 0x006B77
10.1.56.0       3.3.3.3         402         0x80000002 0x00616D

You can above that we have Router Link States (LSA Type 1) and Net Link States (LSA Type 2) in our database on R1. This describes the routers and networks in our area 2. R3 will take these routes and generate a LSA Type 3 and send it out into area 0. We can also see the Summary Net Link States (LSA Type 3). These have been generated by R3 and sent into area 2.

Enough theory, lets get into filtering some routes!

Recap: Filtering Routes Within An Area

In our previous tutorial, we looked at filtering routes within an OSPF area. We noted that when you use filtering tools within an area, you are only filtering from the routes entering the route table. You are not filtering the OSPF database. The database must be consistent within an area for OSPF to work correctly. This results in a discrepancy between the route table and OSPF database when filtering within an area.

An ABR will summarise routes as an LSA type 3 before sending it into the area. It is on the ABR that we will perform filtering between areas. How does filtering between areas affect the route tables and OSPF database? Let’s find out!

Filtering Routes Between Areas – Using and area filter-list

The first technique we are going to use to filter routes between areas is using the area filter-list command. Before we start lets take a look at the OSPF database on R5.

R5:

R5#sh ip ospf database

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

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
4.4.4.4         4.4.4.4         799         0x80000004 0x00D71F 2
5.5.5.5         5.5.5.5         792         0x80000004 0x00D7DC 3
6.6.6.6         6.6.6.6         810         0x80000004 0x007A29 3

                Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.1.45.5       5.5.5.5         792         0x80000002 0x00C8FA
10.1.46.6       6.6.6.6         810         0x80000002 0x00B702
10.1.56.6       6.6.6.6         810         0x80000002 0x007B30

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         4.4.4.4         799         0x80000002 0x00B35F
2.2.2.2         4.4.4.4         799         0x80000002 0x008589
3.3.3.3         4.4.4.4         799         0x80000002 0x00F222
4.4.4.4         4.4.4.4         799         0x80000002 0x0060BA
10.0.34.0       4.4.4.4         800         0x80000002 0x00797C
10.2.12.0       4.4.4.4         800         0x80000002 0x001DD8
10.2.13.0       4.4.4.4         800         0x80000002 0x00AD51
10.2.23.0       4.4.4.4         800         0x80000002 0x003FB5

You can see above that R5 has Router Link States (LSA Type 1) and Net Link States (LSA Type 2) that describe the networks and routers in area 1. We can also see the Summary Net Link States (LSA Type 3) that have been generated by R4 and sent into area 1.

R5#sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/31] via 10.1.45.4, 00:50:57, Ethernet1/0
     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/31] via 10.1.45.4, 00:50:57, Ethernet1/0
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/21] via 10.1.45.4, 00:50:57, Ethernet1/0
     4.0.0.0/32 is subnetted, 1 subnets
O IA    4.4.4.4 [110/11] via 10.1.45.4, 00:50:57, Ethernet1/0
     5.0.0.0/32 is subnetted, 1 subnets
C       5.5.5.5 is directly connected, Loopback0
     6.0.0.0/32 is subnetted, 1 subnets
O       6.6.6.6 [110/11] via 10.1.56.6, 00:50:57, Ethernet1/1
     10.0.0.0/24 is subnetted, 7 subnets
O IA    10.2.12.0 [110/40] via 10.1.45.4, 00:50:57, Ethernet1/0
O IA    10.2.13.0 [110/30] via 10.1.45.4, 00:50:57, Ethernet1/0
O IA    10.2.23.0 [110/30] via 10.1.45.4, 00:50:57, Ethernet1/0
O       10.1.46.0 [110/20] via 10.1.56.6, 00:50:57, Ethernet1/1
                  [110/20] via 10.1.45.4, 00:50:57, Ethernet1/0
C       10.1.45.0 is directly connected, Ethernet1/0
O IA    10.0.34.0 [110/20] via 10.1.45.4, 00:50:57, Ethernet1/0
C       10.1.56.0 is directly connected, Ethernet1/1

Looking at the route table we can see that we have inter-area routes to the Loopbacks for R1, R2, R3, and R4. We also have inter-area routes to the networks in Area 2, and the backbone area. It is these inter-area routes that we will look to filter from going into area 1.

Lets have a look at the database on R4 where we be performing the filtering.
R4:

R4#sh ip ospf database

            OSPF Router with ID (4.4.4.4) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
3.3.3.3         3.3.3.3         745         0x80000003 0x00236F 2
4.4.4.4         4.4.4.4         780         0x80000003 0x00374E 2

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.0.34.4       4.4.4.4         780         0x80000002 0x0022BA

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         3.3.3.3         745         0x80000002 0x006DB3
2.2.2.2         3.3.3.3         745         0x80000002 0x003FDD
5.5.5.5         4.4.4.4         780         0x80000002 0x009676
6.6.6.6         4.4.4.4         780         0x80000002 0x0068A0
10.1.45.0       4.4.4.4         780         0x80000002 0x00F3F5
10.1.46.0       4.4.4.4         780         0x80000002 0x00E8FF
10.1.56.0       4.4.4.4         780         0x80000002 0x00DEF5
10.2.12.0       3.3.3.3         745         0x80000002 0x00D62D
10.2.13.0       3.3.3.3         745         0x80000002 0x0067A5
10.2.23.0       3.3.3.3         745         0x80000002 0x00F80A

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
4.4.4.4         4.4.4.4         780         0x80000004 0x00D71F 2
5.5.5.5         5.5.5.5         775         0x80000004 0x00D7DC 3
6.6.6.6         6.6.6.6         792         0x80000004 0x007A29 3

                Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.1.45.5       5.5.5.5         775         0x80000002 0x00C8FA
10.1.46.6       6.6.6.6         792         0x80000002 0x00B702
10.1.56.6       6.6.6.6         792         0x80000002 0x007B30

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         4.4.4.4         780         0x80000002 0x00B35F
2.2.2.2         4.4.4.4         780         0x80000002 0x008589
3.3.3.3         4.4.4.4         781         0x80000002 0x00F222
4.4.4.4         4.4.4.4         781         0x80000002 0x0060BA
10.0.34.0       4.4.4.4         781         0x80000002 0x00797C
10.2.12.0       4.4.4.4         781         0x80000002 0x001DD8
10.2.13.0       4.4.4.4         781         0x80000002 0x00AD51
10.2.23.0       4.4.4.4         781         0x80000002 0x003FB5

You can see above that R4 has a consistent database with all the routers in Area 0 and Area 1. It has a complete view of both areas. R4 has sent the LSA Type 3 routes from area 2 into area 1.

Let’s set up R4 so that it only passes the 10.2.12.0/24 and 10.2.23.0/24 routes into area 1 using the area filter-list command:

R4:

router ospf 1
 router-id 4.4.4.4
 log-adjacency-changes
 area 1 filter-list prefix AREA_1_IN in
 network 4.4.4.4 0.0.0.0 area 0
 network 10.0.34.4 0.0.0.0 area 0
 network 10.1.45.4 0.0.0.0 area 1
 network 10.1.46.4 0.0.0.0 area 1
!
ip prefix-list AREA_1_IN seq 5 permit 10.2.12.0/24
ip prefix-list AREA_1_IN seq 10 permit 10.2.23.0/24

You can see above that we have created a prefix-list that matches the routes that we want to permit (ie allowed) to go into area 1. We have then applied this prefix-list to the area filter-list. Notice the direction. We are only allowing those routes matched by the prefix into area 1. Its from the perspective of the area not the router.

A lot of candidates make the mistake of saying “area 1 filter-list prefix AREA_1_IN out” thinking its filtering the routes from going out of the router. This is wrong. You have to think of it from the perspective of the areas. We are filtering routes from going into area 1.

Let’s verify the routing tables and OSPF database on R5:

R5:

R5#sh ip ospf database

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

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
4.4.4.4         4.4.4.4         1530        0x80000004 0x00D71F 2
5.5.5.5         5.5.5.5         1523        0x80000004 0x00D7DC 3
6.6.6.6         6.6.6.6         1541        0x80000004 0x007A29 3

                Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.1.45.5       5.5.5.5         1523        0x80000002 0x00C8FA
10.1.46.6       6.6.6.6         1541        0x80000002 0x00B702
10.1.56.6       6.6.6.6         1541        0x80000002 0x007B30

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.2.12.0       4.4.4.4         1530        0x80000002 0x001DD8
10.2.23.0       4.4.4.4         85          0x80000001 0x0041B4

Looks like the only LSA Type 3 (Summary Net Link States) routes that we received are the only ones we permitted on R4. Exactly what we expected! Now let’s check the route table:

R5#sh ip route | b Gateway
Gateway of last resort is not set

     5.0.0.0/32 is subnetted, 1 subnets
C       5.5.5.5 is directly connected, Loopback0
     6.0.0.0/32 is subnetted, 1 subnets
O       6.6.6.6 [110/11] via 10.1.56.6, 00:56:45, Ethernet1/1
     10.0.0.0/24 is subnetted, 5 subnets
O IA    10.2.12.0 [110/40] via 10.1.45.4, 00:56:45, Ethernet1/0
O IA    10.2.23.0 [110/30] via 10.1.45.4, 00:00:05, Ethernet1/0
O       10.1.46.0 [110/20] via 10.1.56.6, 00:56:45, Ethernet1/1
                  [110/20] via 10.1.45.4, 00:56:45, Ethernet1/0
C       10.1.45.0 is directly connected, Ethernet1/0
C       10.1.56.0 is directly connected, Ethernet1/1

Awesome! The only inter-area routes that we can see on R5 are those that we permitted on the ABR (R4).

Let’s have a look at example of filtering routes coming out of an area:

R3:

router ospf 1
 router-id 3.3.3.3
 log-adjacency-changes
 area 2 filter-list prefix AREA_2_OUT out
 network 3.3.3.3 0.0.0.0 area 0
 network 10.0.34.3 0.0.0.0 area 0
 network 10.2.13.3 0.0.0.0 area 2
 network 10.2.23.3 0.0.0.0 area 2
!
ip prefix-list AREA_2_OUT seq 5 permit 10.2.23.0/24

Recall that R3 will generate a Type 3 Summary LSA for all the routes in area 2 and then send it out of area 2. In the example above we area stopping R3 creating a Type 3 LSA and sending it into area 0. We are using a prefix list to specify that the only Type 3 LSA that R3 will generate is for the 10.2.23.0/24 route.

Let’s check the database on R4 now, I’ll just clear the OSPF process on R3 to speed to convergence along:

R3#clear ip ospf pro
Reset ALL OSPF processes? [no]: yes

R4:

R4#sh ip ospf data

            OSPF Router with ID (4.4.4.4) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
3.3.3.3         3.3.3.3         31          0x80000005 0x00157C 2
4.4.4.4         4.4.4.4         117         0x80000004 0x002B5A 2

                Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.0.34.3       3.3.3.3         127         0x80000001 0x005C86

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
5.5.5.5         4.4.4.4         112         0x80000002 0x009676
6.6.6.6         4.4.4.4         122         0x80000001 0x006A9F
10.1.45.0       4.4.4.4         112         0x80000001 0x00F5F4
10.1.46.0       4.4.4.4         122         0x80000001 0x00EAFE
10.1.56.0       4.4.4.4         122         0x80000001 0x00E0F4
10.2.23.0       3.3.3.3         31          0x80000003 0x00F60B

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
4.4.4.4         4.4.4.4         117         0x80000006 0x00D321 2
5.5.5.5         5.5.5.5         126         0x80000006 0x00D3DE 3
6.6.6.6         6.6.6.6         62          0x80000005 0x00782A 3

                Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.1.45.5       5.5.5.5         123         0x80000003 0x00C6FB
10.1.46.6       6.6.6.6         62          0x80000003 0x00B503
10.1.56.6       6.6.6.6         62          0x80000003 0x007931

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.2.23.0       4.4.4.4         117         0x80000002 0x003FB5

You can see that the only Type 3 LSA from area 2 that R4 can see is the 10.2.23.0/24 network. Exactly what we expected. Awesome!

R5:

R5#sh ip route | b Gateway
Gateway of last resort is not set

     5.0.0.0/32 is subnetted, 1 subnets
C       5.5.5.5 is directly connected, Loopback0
     6.0.0.0/32 is subnetted, 1 subnets
O       6.6.6.6 [110/11] via 10.1.56.6, 00:02:18, Ethernet1/1
     10.0.0.0/24 is subnetted, 4 subnets
O IA    10.2.23.0 [110/30] via 10.1.45.4, 00:02:18, Ethernet1/0
O       10.1.46.0 [110/20] via 10.1.56.6, 00:02:18, Ethernet1/1
                  [110/20] via 10.1.45.4, 00:02:18, Ethernet1/0
C       10.1.45.0 is directly connected, Ethernet1/0
C       10.1.56.0 is directly connected, Ethernet1/1

This in turn is the only inter-area route that we can see on R5 (remember that we are also filtering on R4).

R5#sh ip ospf database

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

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
5.5.5.5         5.5.5.5         6           0x80000006 0x00D3DE 3
6.6.6.6         6.6.6.6         1952        0x80000004 0x007A29 3

                Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.1.45.4       4.4.4.4         3609        0x80000001 0x0003C6
10.1.45.5       5.5.5.5         3           0x80000003 0x00C6FB
10.1.46.6       6.6.6.6         1952        0x80000002 0x00B702
10.1.56.6       6.6.6.6         1952        0x80000002 0x007B30

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.2.23.0       4.4.4.4         4           0x80000001 0x0041B4

So you can see that we can filter routes using the area filter-list command. The area filter-list command filter’s LSA Type 3’s from going in or out of an area. The routes in an area still maintain a consistent route table and OSPF database. Filtering between areas stops routes from entering the OSPF database and in turn stops them from going into the route tables.

In our next article in this series we will look at filtering between areas using a few of the more obtuse ways such as the area range command and summary-address commands.

Hope this helps. If anybody has any questions or suggestion, leave a comment below and I’ll be happy to help. Now get back to labs! :)

Summary:

OSPF can be considered Link-State within an area, and Distance Vector between areas
The area filter-list command filter’s routes going in or out from an area.

Resources:

Read this article and more like it on ardenpackeer.com
Follow me on twitter: http://twitter.com/ardenpackeer

Tutorial: Filtering Routes in OSPF Part 2 » Filtering Between Areas Using area filter-list

Tutorial: OSPF Network Types & Frame-Relay Series

Arden Packeer, CCIE #20716 — Thu, 24 Jul 2008 10:59:41 +0000

Knowing the OSPF Network Types and how they work with different frame relay topologies is one of those things that you should know inside out if you are attempting the CCIE lab. This five part series of tutorials are designed to take you through all the different OSPF network types and demonstrate how they interact with Frame-Relay over various partial-mesh topologies.

Read this article and more like it on ardenpackeer.com
Follow me on twitter: http://twitter.com/ardenpackeer

Tutorial: OSPF Network Types & Frame-Relay Series

Tutorial: OSPF Network Types and Frame Relay Part 5

Arden Packeer, CCIE #20716 — Thu, 24 Jul 2008 10:19:21 +0000

In my previous tutorials we looked at the different OSPF Network types (you can find Part 1 here, Part 2 here, Part 3 here, and Part 4 here) and also how they interact with each other. In this tutorial we will be looking at implementing OSPF over a partial mesh Frame-Relay network with multiple hubs and spokes. This is the last of the OSPF Network Types and Frame Relay series of articles….unless I find something cool! :)

We will be implementing the following topology for this tutorial:

Dynagen / Dynamips .net Configuration File:

ghostios = true
sparsemem = true
model = 3640

[localhost]

    [[3640]]
    image = \Program Files\Dynamips\images\c3640-jk9o3s-mz.124-12.bin
    # On Linux / Unix use forward slashes:
    # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
    ram = 128

    [[ROUTER R1]]
        f0/0 = LAN 1
        s1/0 = FRAME 1
        console = 2000
        model = 3640

    [[ROUTER R2]]
        f0/0 = LAN 2
        s1/0 = FRAME 2
        console = 2001
        model = 3640

    [[ROUTER R3]]
        f0/0 = LAN 3
        s1/0 = FRAME 3
        console = 2002
        model = 3640

    [[ROUTER R4]]
        f0/0 = LAN 4
        s1/0 = FRAME 4
        console = 2003
        model = 3640

    [[FRSW FRAME]]
        1:102 = 2:201
        2:203 = 3:302
        3:304 = 4:403

You can download the dynagen .net configuration file for this topology here.

Lets have a look at the basic configuration for this topology:

hostname R1
!
no service timestamps debug uptime
no service timestamps log uptime
!
interface FastEthernet0/0
 ip address 1.1.1.1 255.255.255.0
 duplex auto
 speed auto
!
interface Serial1/0
 ip address 192.168.1.1 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 192.168.1.2 102 broadcast
 frame-relay map ip 192.168.1.3 102
 frame-relay map ip 192.168.1.4 102
 no frame-relay inverse-arp

hostname R2
!
no service timestamps debug uptime
no service timestamps log uptime
!
interface FastEthernet0/0
 ip address 2.2.2.2 255.255.255.0
 duplex auto
 speed auto
!
interface Serial1/0
 ip address 192.168.1.2 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 192.168.1.1 201 broadcast
 frame-relay map ip 192.168.1.3 203 broadcast
 frame-relay map ip 192.168.1.4 203
 no frame-relay inverse-arp

hostname R3
!
no service timestamps debug uptime
no service timestamps log uptime
!
interface FastEthernet0/0
 ip address 3.3.3.3 255.255.255.0
 duplex auto
 speed auto
!
interface Serial1/0
 ip address 192.168.1.3 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 192.168.1.1 302
 frame-relay map ip 192.168.1.2 302 broadcast
 frame-relay map ip 192.168.1.4 304 broadcast
 no frame-relay inverse-arp

hostname R4
!
no service timestamps debug uptime
no service timestamps log uptime
!
interface FastEthernet0/0
 ip address 4.4.4.4 255.255.255.0
 duplex auto
 speed auto
!
interface Serial1/0
 ip address 192.168.1.4 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 192.168.1.1 403
 frame-relay map ip 192.168.1.2 403
 frame-relay map ip 192.168.1.3 403 broadcast
 no frame-relay inverse-arp

Let’s take a close look at this configuration. You can see above we have a partial mesh configuration and it could be argued that we actually have two hubs. R2 and R3 could both be considered hubs. R2 is the hub for R1 and R3 spokes, and R3 is the hub for R2 and R4 spokes. The broadcast statements reflect this. R2 has broadcast statements in its frame-relay map for its spokes, and only its spokes. This is the same on R3, we have broadcast statements for R2 and R4 (its spokes only). This is to stop redundant broadcasts.

If we apply a broadcast statement to each and every frame-relay map statement this will cause redundant broadcasts frames to be sent. For example lets say we configure R4 as follows:

interface Serial1/0
 ip address 192.168.1.4 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 192.168.1.1 403 broadcast
 frame-relay map ip 192.168.1.2 403 broadcast
 frame-relay map ip 192.168.1.3 403 broadcast
 no frame-relay inverse-arp

Notice we have applied a broadcast option to every frame-relay map statement. When a broadcast frame is sent, it will create three packets with a layer2 header (frame relay) specifying DLCI 403, and a layer3 header (IP) specifying a destination of 192.168.1.255. R3 will receive all three of these frames.

R3 will look at the layer2 header of those frames and say “Oh this for me at layer2! Great, lets look at the layer3 header”. R3 will then de-encapsulate the layer2 header (the frame) and then take a look at the layer3 header which has a destination of 192.168.1.255. “Oh its a broadcast great, thats for me as well”, R3 says. Will it forward those back out the interface to the rest of the Routers? No. Think about this. When you get a broadcast packet on an ethernet network does your computer process it and then send it back out again. If it did this would result in a hell of a lot of broadcast traffic on our networks!

R3 will get three packets that have the broadcast as a destination address and process them. It will not resend those broadcast packets backout again. That is what it means by redundant broadcasts.

Let’s verify this:
R2:

R2#debug ip packet
IP packet debugging is on

R3:

R3#debug ip packet
IP packet debugging is on

R4:

R4#debug ip packet
IP packet debugging is on

We have turned on ip packet debugging on all routers (don’t try this on a production router!). Let’s generate some packets on R4:

R4#ping 192.168.1.255

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.255, timeout is 2 seconds:

IP: s=192.168.1.4 (local), d=255.255.255.255 (Serial1/0), len 100, sending broad/multicast
IP: tableid=0, s=192.168.1.3 (Serial1/0), d=192.168.1.4 (Serial1/0), routed via RIB
IP: s=192.168.1.3 (Serial1/0), d=192.168.1.4 (Serial1/0), len 100, rcvd 3
IP: tableid=0, s=192.168.1.3 (Serial1/0), d=192.168.1.4 (Serial1/0), routed via RIB
IP: s=192.168.1.3 (Serial1/0), d=192.168.1.4 (Serial1/0), len 100, rcvd 3
IP: tableid=0, s=192.168.1.3 (Serial1/0), d=192.168.1.4 (Serial1/0), routed via RIB
IP: s=192.168.1.3 (Serial1/0), d=192.168.1.4 (Serial1/0), len 100, rcvd 3
Reply to request 0 from 192.168.1.3, 80 ms
Reply to request 0 from 192.168.1.3, 96 ms
Reply to request 0 from 192.168.1.3, 88 ms
-----Output Cut-----

R3#
IP: s=192.168.1.4 (Serial1/0), d=255.255.255.255, len 100, rcvd 2
IP: tableid=0, s=192.168.1.3 (local), d=192.168.1.4 (Serial1/0), routed via FIB
IP: s=192.168.1.3 (local), d=192.168.1.4 (Serial1/0), len 100, sending
IP: s=192.168.1.4 (Serial1/0), d=255.255.255.255, len 100, rcvd 2
IP: tableid=0, s=192.168.1.3 (local), d=192.168.1.4 (Serial1/0), routed via FIB
IP: s=192.168.1.3 (local), d=192.168.1.4 (Serial1/0), len 100, sending
IP: s=192.168.1.4 (Serial1/0), d=255.255.255.255, len 100, rcvd 2
IP: tableid=0, s=192.168.1.3 (local), d=192.168.1.4 (Serial1/0), routed via FIB
IP: s=192.168.1.3 (local), d=192.168.1.4 (Serial1/0), len 100, sending

You can see clearly in the output above that R3 got 3 ping packets for every one ping that was supposed to be sent. R3 then sent 3 unicast reply back to to R4 only. Be aware of this as I see a lot of people setting broadcast statement on every frame-relay map statement. I don’t know if you will loose marks on this in the CCIE Lab exam but it certainly helps to be aware of it.

On your hub, set a broadcast frame-relay map on all the DLCI’s leading to your spokes. On your spokes, set the broadcast frame-relay map on the DLCI leading to your hub.

This has implications for OSPF. It is why we usually want to make sure that the hub is the Designated Router (DR) in OSPF. The spokes send an update via a multicast (subset of broadcast) to 224.0.0.6 which the DR listens on. This is only applicable to network types that require a DR. The updates are then collated by the DR and sent out to the other spokes via the address 224.0.0.5. They are seperate broadcasts.

Let’s clean up before we move on to setting up OSPF across this network.

R2:

R2#un all
All possible debugging has been turned off

R3:

R3#un all
All possible debugging has been turned off

R4:

R4#un all
All possible debugging has been turned off
R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#default int s1/0
Building configuration...

Interface Serial1/0 set to default configuration
R4(config)#
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0, changed state to up
R4(config)#int s1/0
R4(config-if)# ip address 192.168.1.4 255.255.255.0
R4(config-if)# encapsulation frame-relay
R4(config-if)# frame-relay map ip 192.168.1.1 403
R4(config-if)# frame-relay map ip 192.168.1.2 403
R4(config-if)# frame-relay map ip 192.168.1.3 403 broadcast
R4(config-if)# no frame-relay inverse-arp
R4(config-if)#no shut
R4(config-if)#end

Setting Up An OSPF Network Across A Partial-Mesh Frame-Relay Network

One of the things that you should be asking yourself looking at that topology is what OSPF network type do we use? We’ve already stated that there are essentially two hubs in that topology. Both R2 and R3 could be considered hubs. Well, if there are two hubs which one do we make the DR? Can we even use a network type that requires a DR in this topology? Let’s explore this first.

OSPF DR Network Types:

R1:

interface Serial1/0
 ip ospf network broadcast
 ip ospf priority 0
!
router ospf 1
 router-id 1.1.1.1
 log-adjacency-changes
 network 1.1.1.1 0.0.0.0 area 0
 network 192.168.1.1 0.0.0.0 area 0

R2:

interface Serial1/0
 ip ospf network broadcast
!
router ospf 1
 router-id 2.2.2.2
 log-adjacency-changes
 network 2.2.2.2 0.0.0.0 area 0
 network 192.168.1.2 0.0.0.0 area 0

R3:

interface Serial1/0
 ip ospf network broadcast
!
router ospf 1
 router-id 3.3.3.3
 log-adjacency-changes
 network 3.3.3.3 0.0.0.0 area 0
 network 192.168.1.3 0.0.0.0 area 0

R4:

interface Serial1/0
 ip ospf network broadcast
 ip ospf priority 0
!
router ospf 1
 router-id 4.4.4.4
 log-adjacency-changes
 network 4.4.4.4 0.0.0.0 area 0
 network 192.168.1.4 0.0.0.0 area 0

So we have activated ospf on all the interfaces in our topology. For simplicity sake we have used a single OSPF area (area 0) for our entire topology.

Let’s verify that we are able to establish adjacency on our routers:

R1#sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   FULL/DR         00:00:30    192.168.1.2     Serial1/0

R2#sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           0   FULL/DROTHER    00:00:36    192.168.1.1     Serial1/0
3.3.3.3           1   FULL/DR         00:00:30    192.168.1.3     Serial1/0

R3#sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   FULL/BDR        00:00:32    192.168.1.2     Serial1/0
4.4.4.4           0   FULL/DROTHER    00:00:33    192.168.1.4     Serial1/0

R4#sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3           1   FULL/DR         00:00:38    192.168.1.3     Serial1/0

At first glance, that looks fine. They all came up as fully adjacent, but take a look at those DR/BDR relationships. They are not consistent at all!

R1#sh ip ospf int s1/0 | inc Designated|Backup
  Designated Router (ID) 2.2.2.2, Interface address 192.168.1.2
  Backup Designated router (ID) 2.2.2.2, Interface address 192.168.1.2
    Adjacent with neighbor 2.2.2.2  (Designated Router)

R2#sh ip ospf int s1/0 | inc Designated|Backup
  Designated Router (ID) 3.3.3.3, Interface address 192.168.1.3
  Backup Designated router (ID) 2.2.2.2, Interface address 192.168.1.2
    Adjacent with neighbor 3.3.3.3  (Designated Router)

R3#sh ip ospf int s1/0 | inc Designated|Backup
  Designated Router (ID) 3.3.3.3, Interface address 192.168.1.3
  Backup Designated router (ID) 2.2.2.2, Interface address 192.168.1.2
    Adjacent with neighbor 2.2.2.2  (Backup Designated Router)

R4#sh ip ospf int s1/0 | inc Designated|Backup
  Designated Router (ID) 3.3.3.3, Interface address 192.168.1.3
    Adjacent with neighbor 3.3.3.3  (Designated Router)

R1 believes that R2 is the DR. R2, R3, and R4 believe that R3 is the DR. How will this effect the routing tables?

R2#sh ip route | b Gateway
Gateway of last resort is not set

     2.0.0.0/24 is subnetted, 1 subnets
C       2.2.2.0 is directly connected, FastEthernet0/0
     3.0.0.0/24 is subnetted, 1 subnets
O       3.3.3.0 [110/65] via 192.168.1.3, 00:03:40, Serial1/0
     4.0.0.0/24 is subnetted, 1 subnets
O       4.4.4.0 [110/65] via 192.168.1.4, 00:03:40, Serial1/0
C    192.168.1.0/24 is directly connected, Serial1/0

R3#sh ip route | b Gateway
Gateway of last resort is not set

     2.0.0.0/24 is subnetted, 1 subnets
O       2.2.2.0 [110/65] via 192.168.1.2, 00:04:07, Serial1/0
     3.0.0.0/24 is subnetted, 1 subnets
C       3.3.3.0 is directly connected, FastEthernet0/0
     4.0.0.0/24 is subnetted, 1 subnets
O       4.4.4.0 [110/65] via 192.168.1.4, 00:04:07, Serial1/0
C    192.168.1.0/24 is directly connected, Serial1/0

R4#sh ip route | b Gateway
Gateway of last resort is not set

     2.0.0.0/24 is subnetted, 1 subnets
O       2.2.2.0 [110/65] via 192.168.1.2, 00:04:18, Serial1/0
     3.0.0.0/24 is subnetted, 1 subnets
O       3.3.3.0 [110/65] via 192.168.1.3, 00:04:18, Serial1/0
     4.0.0.0/24 is subnetted, 1 subnets
C       4.4.4.0 is directly connected, FastEthernet0/0
C    192.168.1.0/24 is directly connected, Serial1/0

It looks like R2, R3, and R4 can see each others Ethernet networks, but they have no visibility of R1’s Ethernet segment.

R1#sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/24 is subnetted, 1 subnets
C       1.1.1.0 is directly connected, FastEthernet0/0
C    192.168.1.0/24 is directly connected, Serial1/0

R1 has no visibility at all of the other networks even though we are fully adjacent with R2!

Let’s examine this a little closer. In the above topology, R2, R3, and R4 will be able to swap routes as they have a consitent DR. Updates will be sent to the DR, these will be collated by the DR and then resent out to the spokes. But R1 thinks R2 is the DR. R1 will send its updates to what it thinks is the DR (R2). R2 will not accept these routes because it believes R3 is the DR!

The biggest problem with this topology and OSPF network types that require a DR is “who do we make the DR?”. We usually make the hub in a hub and spoke topology the DR, but what happens when we effectively have 2 hubs? These types of topologies are simply not suited to OSPF network types that require a DR (broadcast, and non-broadcast). We can’t have 2 DR’s!

OSPF Non-DR Network Types:

Let’s try the same thing with a Non-DR OSPF Network type. In this example we will be using the point-to-multipoint OSPF network type, although we could also use any of the other types that don’t require a DR.

Let’s take a look at the configuration:
R1:

interface Serial1/0
 ip address 192.168.1.1 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-multipoint
 frame-relay map ip 192.168.1.2 102 broadcast
 frame-relay map ip 192.168.1.3 102
 frame-relay map ip 192.168.1.4 102
 no frame-relay inverse-arp
!
router ospf 1
 router-id 1.1.1.1
 log-adjacency-changes
 network 1.1.1.1 0.0.0.0 area 0
 network 192.168.1.1 0.0.0.0 area 0

R2:

interface Serial1/0
 ip address 192.168.1.2 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-multipoint
 frame-relay map ip 192.168.1.1 201 broadcast
 frame-relay map ip 192.168.1.3 203 broadcast
 frame-relay map ip 192.168.1.4 203
 no frame-relay inverse-arp
!
router ospf 1
 router-id 2.2.2.2
 log-adjacency-changes
 network 2.2.2.2 0.0.0.0 area 0
 network 192.168.1.2 0.0.0.0 area 0

R3:

interface Serial1/0
 ip address 192.168.1.3 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-multipoint
 frame-relay map ip 192.168.1.1 302
 frame-relay map ip 192.168.1.2 302 broadcast
 frame-relay map ip 192.168.1.4 304 broadcast
 no frame-relay inverse-arp
!
router ospf 1
 router-id 3.3.3.3
 log-adjacency-changes
 network 3.3.3.3 0.0.0.0 area 0
 network 192.168.1.3 0.0.0.0 area 0

R4:

interface Serial1/0
 ip address 192.168.1.4 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-multipoint
 frame-relay map ip 192.168.1.1 403
 frame-relay map ip 192.168.1.2 403
 frame-relay map ip 192.168.1.3 403 broadcast
 no frame-relay inverse-arp
!
router ospf 1
 router-id 4.4.4.4
 log-adjacency-changes
 network 4.4.4.4 0.0.0.0 area 0
 network 192.168.1.4 0.0.0.0 area 0

Once again we have setup all our interfaces so that they are in area 0. We have used the ip ospf network point-to-multipoint command on all our routers so we have a consistent network type. This network type does not require a DR as OSPF will inject /32 route to all our end points. You can check out my previous tutorial on the point-to-multipoint OSPF network type on why this is so cool!

Our two hubs, R2 and R3 have frame-relay maps with broadcast statements to their respective spokes. R2 has a broadcast statement for R1 and R3 in its frame-relay map statement. R3 has a broadcast statement for R2 and R4 in its frame-relay maps. Once again, we don’t apply broadcast statements to all our traffic as we would receive redundant broadcast messages.

Let’s verify the routing table:

R1#sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/24 is subnetted, 1 subnets
C       1.1.1.0 is directly connected, FastEthernet0/0
     2.0.0.0/24 is subnetted, 1 subnets
O       2.2.2.0 [110/65] via 192.168.1.2, 00:15:43, Serial1/0
     3.0.0.0/24 is subnetted, 1 subnets
O       3.3.3.0 [110/129] via 192.168.1.2, 00:15:43, Serial1/0
     4.0.0.0/24 is subnetted, 1 subnets
O       4.4.4.0 [110/193] via 192.168.1.2, 00:15:43, Serial1/0
     192.168.1.0/24 is variably subnetted, 4 subnets, 2 masks
C       192.168.1.0/24 is directly connected, Serial1/0
O       192.168.1.3/32 [110/128] via 192.168.1.2, 00:15:43, Serial1/0
O       192.168.1.2/32 [110/64] via 192.168.1.2, 00:15:43, Serial1/0
O       192.168.1.4/32 [110/192] via 192.168.1.2, 00:15:43, Serial1/0

You can see clearly above OSPF has inserted an extra hop via R2 for R1 for all our routers in the 192.168.1.0/24 segment. OSPF’s point-to-multipoint network type creates next hops to make the layer 3 topology mirror that of the layer 2 topology.

R1 looks great, let’s verify R4’s routing table and see if we can ping across the furthest spokes:

R4#sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/24 is subnetted, 1 subnets
O       1.1.1.0 [110/193] via 192.168.1.3, 00:24:11, Serial1/0
     2.0.0.0/24 is subnetted, 1 subnets
O       2.2.2.0 [110/129] via 192.168.1.3, 00:24:11, Serial1/0
     3.0.0.0/24 is subnetted, 1 subnets
O       3.3.3.0 [110/65] via 192.168.1.3, 00:24:11, Serial1/0
     4.0.0.0/24 is subnetted, 1 subnets
C       4.4.4.0 is directly connected, FastEthernet0/0
     192.168.1.0/24 is variably subnetted, 4 subnets, 2 masks
O       192.168.1.1/32 [110/192] via 192.168.1.3, 00:24:11, Serial1/0
C       192.168.1.0/24 is directly connected, Serial1/0
O       192.168.1.3/32 [110/64] via 192.168.1.3, 00:24:11, Serial1/0
O       192.168.1.2/32 [110/128] via 192.168.1.3, 00:24:11, Serial1/0

The routing table looks great! Let’s check reachability:

R4#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/47/136 ms

Looks like we have full reachability! Awesome!

So whats the moral of this story? On topologies that have one hub, make sure the hub becomes the DR by setting the ip ospf priority of the spokes to 0 (or use a network type that doesn’t require a DR!).

For a frame-relay topology that effectively has multiple hubs like our topology above we should use an OSPF network type that doesn’t require a DR.

If anybody has any other questions regarding OSPF networks and frame-relay, or has some weird topology that would make a great tutorial shoot me an email.

HTH. Now get back to labs!

Summary:

For topologies where you have one hub, ensure the hub is the DR or use a network type that doesn’t require a DR
For topologies that have more than one hub, use a network type that doesn’t require a DR
In partial mesh topologies, the hubs should use a broadcast frame-relay map on DLCI’s to all connected spokes. This is to stop redundant broadcasts
In partial mesh topologies, the spokes should use a broadcast frame-relay map on DLCI’s to the hub only. This is to stop redundant broadcasts

Resources:

Dynamips/Dynagen .net configuration file

Read this article and more like it on ardenpackeer.com
Follow me on twitter: http://twitter.com/ardenpackeer

Tutorial: OSPF Network Types and Frame Relay Part 5

Tutorial: Filtering Routes in OSPF Part 1 » Filtering Within An Area

Arden Packeer, CCIE #20716 — Sat, 21 Jun 2008 05:16:55 +0000

In addition to knowing all the different OSPF Network Types and how they relate to Frame-Relay, a CCIE candidate must be familiar with the different methods of filtering routes in OSPF. This two part series of tutorials will focus on filtering routes in OSPF, both within an area and between areas. This tutorial will focus on filtering routes within an area using distribute-lists, access-lists and using a route-map.

We will be using the following topology for this tutorial:

Dynagen .net Configuration File:

ghostios = True
sparsemem = True
model = 3640

[localhost]

    [[3640]]
        image = \Program Files\Dynamips\images\c3640-jk9o3s-mz.124-12.bin
        # On Linux / Unix use forward slashes:
        # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
        ram = 128

    [[ROUTER R1]]
        model = 3640
        console = 2000
        e1/0 = LAN 13
        e1/1 = LAN 12
        autostart = False       

    [[ROUTER R2]]
        model = 3640
        console = 2001
        e1/0 = LAN 23
        e1/1 = LAN 12
        autostart = False

    [[ROUTER R3]]
        model = 3640
        console = 2002
        e1/0 = LAN 13
        e1/1 = LAN 23
        e1/2 = LAN 34
        e1/3 = LAN 35
        autostart = False

    [[ROUTER R4]]
        model = 3640
        console = 2003
        e1/0 = LAN 34
        e1/1 = LAN 45
        autostart = False

    [[ROUTER R5]]
        model = 3640
        console = 2004
        e1/0 = LAN 35
        e1/1 = LAN 45
        autostart = False

You can download the .net dynagen configuration file here.

Basic Configuration

First things first lets set up our basic topology. You can see in the diagram above R3 will be our Area Border Router (ABR) between Area 0 and Area 1. R1 and R2 will be backbone routers in Area 0, and R4 and R5 will be internal Area 1 routers.

R1:

hostname R1
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface Ethernet1/0
 ip address 10.0.13.1 255.255.255.0
 full-duplex
!
interface Ethernet1/1
 ip address 10.0.12.1 255.255.255.0
 full-duplex
!
router ospf 1
 router-id 1.1.1.1
 log-adjacency-changes
 network 1.1.1.1 0.0.0.0 area 0
 network 10.0.12.1 0.0.0.0 area 0
 network 10.0.13.1 0.0.0.0 area 0

R2:

hostname R2
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
!
interface Ethernet1/0
 ip address 10.0.23.2 255.255.255.0
 full-duplex
!
interface Ethernet1/1
 ip address 10.0.12.2 255.255.255.0
 full-duplex
!
router ospf 1
 router-id 2.2.2.2
 log-adjacency-changes
 network 2.2.2.2 0.0.0.0 area 0
 network 10.0.12.2 0.0.0.0 area 0
 network 10.0.23.2 0.0.0.0 area 0

R3:

hostname R3
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface Ethernet1/0
 ip address 10.0.13.3 255.255.255.0
 full-duplex
!
interface Ethernet1/1
 ip address 10.0.23.3 255.255.255.0
 full-duplex
!
interface Ethernet1/2
 ip address 10.1.34.3 255.255.255.0
 full-duplex
!
interface Ethernet1/3
 ip address 10.1.35.3 255.255.255.0
 full-duplex
!
router ospf 1
 router-id 3.3.3.3
 log-adjacency-changes
 network 3.3.3.3 0.0.0.0 area 0
 network 10.0.13.3 0.0.0.0 area 0
 network 10.0.23.3 0.0.0.0 area 0
 network 10.1.34.3 0.0.0.0 area 1
 network 10.1.35.3 0.0.0.0 area 1

R4:

hostname R4
!
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
!
interface Ethernet1/0
 ip address 10.1.34.4 255.255.255.0
 full-duplex
!
interface Ethernet1/1
 ip address 10.1.45.4 255.255.255.0
 full-duplex
!
router ospf 1
 router-id 4.4.4.4
 log-adjacency-changes
 network 4.4.4.4 0.0.0.0 area 1
 network 10.1.34.4 0.0.0.0 area 1
 network 10.1.45.4 0.0.0.0 area 1

R5:

hostname R5
!
interface Loopback0
 ip address 5.5.5.5 255.255.255.255
!
interface Ethernet1/0
 ip address 10.1.35.5 255.255.255.0
 full-duplex
!
interface Ethernet1/1
 ip address 10.1.45.5 255.255.255.0
 full-duplex
!
router ospf 1
 router-id 5.5.5.5
 log-adjacency-changes
 network 5.5.5.5 0.0.0.0 area 1
 network 10.1.35.5 0.0.0.0 area 1
 network 10.1.45.5 0.0.0.0 area 1

You can see above, we have also added a loopback interface on each device and advertised them into OSPF. R1, R2, and R3’s Loopback0 interfaces have been added to Area 0. R4 and R5’s Loopback0 interfaces have been added to Area 1.

Let’s verify the routing table on R5 and test connectivity before we start filtering routes.

R5#sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/21] via 10.1.35.3, 00:47:50, Ethernet1/0
     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/21] via 10.1.35.3, 00:47:50, Ethernet1/0
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/11] via 10.1.35.3, 00:47:50, Ethernet1/0
     4.0.0.0/32 is subnetted, 1 subnets
O       4.4.4.4 [110/11] via 10.1.45.4, 00:47:50, Ethernet1/1
     5.0.0.0/32 is subnetted, 1 subnets
C       5.5.5.5 is directly connected, Loopback0
     10.0.0.0/24 is subnetted, 6 subnets
O IA    10.0.12.0 [110/30] via 10.1.35.3, 00:47:50, Ethernet1/0
O IA    10.0.13.0 [110/20] via 10.1.35.3, 00:47:50, Ethernet1/0
O IA    10.0.23.0 [110/20] via 10.1.35.3, 00:47:50, Ethernet1/0
C       10.1.45.0 is directly connected, Ethernet1/1
C       10.1.35.0 is directly connected, Ethernet1/0
O       10.1.34.0 [110/20] via 10.1.45.4, 00:47:50, Ethernet1/1
                  [110/20] via 10.1.35.3, 00:47:50, Ethernet1/0

The routing table looks correct. We have inter-area routes to R1, R2, and R3’s loopback0 addresses as well as to the 10.0.12.0/24, 10.0.13.0/24 and 10.0.23.0/24 networks.

R5#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 216/245/284 ms

Looks like we have full connectivity. Now time to filter some routes!

Filtering Routes Within An Area

OSPF is a link-state routing protocol. Routers running OSPF within an area swap state information and populate a topology database. Each router then independently calculates the best paths based on the information contained in their topology database. All routers within an area must have the same topology information so that they can accurately make routing decisions.

Let’s take a look at the current OSPF topology database on R5:

R5#sh ip ospf database 

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

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
3.3.3.3         3.3.3.3         473         0x80000004 0x00EC42 2
4.4.4.4         4.4.4.4         473         0x80000005 0x006887 3
5.5.5.5         5.5.5.5         454         0x80000005 0x000BD3 3

                Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.1.34.4       4.4.4.4         473         0x80000003 0x0014C6
10.1.35.5       5.5.5.5         454         0x80000003 0x0003CD
10.1.45.5       5.5.5.5         454         0x80000003 0x00C6FB

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         3.3.3.3         473         0x80000003 0x006BB4
2.2.2.2         3.3.3.3         473         0x80000003 0x003DDE
3.3.3.3         3.3.3.3         473         0x80000003 0x00AA77
10.0.12.0       3.3.3.3         473         0x80000003 0x00EC18
10.0.13.0       3.3.3.3         474         0x80000003 0x007D90
10.0.23.0       3.3.3.3         474         0x80000003 0x000FF4

We will be filtering routes on R5 so it will be interesting to see the effect that this will have on the topology database. If we lose any of the database entries, we will have an inconsistent database in our area with some routers missing pieces of the the topology database. An inconsistent topology database might cause the Dijkstra’s shortest-path-first algorithm that OSPF uses to calculate paths that contain routing loops or routing black holes.

Herein lies the challenge. If we filter routes on a particular router, does that mean that some routers in an area will have a different topology database than the others in the same area? How will this affect the routing process? It is these questions that I want you to keep in mind when we go through our examples.

Filtering within an area – Using distribute-list

The first tool we will be using to filter routes is a distribute-list. We will first use a distribute list to filter all routes except R3’s loopback address (3.3.3.3) from R5’s routing table.

Let’s take a look at the configuration:
R5:

router ospf 1
 distribute-list 1 in
!
access-list 1 permit 3.3.3.3

You can see we have created an inbound distribute-list on the OSPF process on R5. We have used an access-list to define that we only want to permit the 3.3.3.3 address (don’t forget there is an implicit deny at the end of that access list).

Let’s verify this:

R5#sh ip route | b Gateway
Gateway of last resort is not set

     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/11] via 10.1.35.3, 00:00:14, Ethernet1/0
     5.0.0.0/32 is subnetted, 1 subnets
C       5.5.5.5 is directly connected, Loopback0
     10.0.0.0/24 is subnetted, 2 subnets
C       10.1.45.0 is directly connected, Ethernet1/1
C       10.1.35.0 is directly connected, Ethernet1/0

Looks like our distribute-list worked as anticipated. The only non-connected route that we can see is the 3.3.3.3/32 network (ie R3’s loopback0).

Let’s check out the OSPF topology database:

R5#sh ip ospf data

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

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
3.3.3.3         3.3.3.3         1476        0x80000005 0x00D659 2
4.4.4.4         4.4.4.4         1415        0x80000006 0x006688 3
5.5.5.5         5.5.5.5         1362        0x80000006 0x00DC03 3

                Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.1.34.4       4.4.4.4         1415        0x80000002 0x0016C5
10.1.35.3       3.3.3.3         1476        0x80000002 0x007566
10.1.45.5       5.5.5.5         1362        0x80000002 0x00C8FA

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         3.3.3.3         1476        0x80000002 0x006DB3
2.2.2.2         3.3.3.3         1476        0x80000002 0x003FDD
3.3.3.3         3.3.3.3         1476        0x80000002 0x00AC76
10.0.12.0       3.3.3.3         1476        0x80000002 0x00EE17
10.0.13.0       3.3.3.3         1478        0x80000002 0x007F8F
10.0.23.0       3.3.3.3         1478        0x80000002 0x0011F3

Whoa! We have NO change to the OSPF topology database!

At first glance this might seem counter-intuitive but this is exactly what we want to happen. Remember OSPF is a link-state routing protocol where each router then calculates the best paths based on the information contained in their topology database. All routers within an area must have the same topology information so that they can accurately make routing decisions. If they don’t have the same topology database on the routers within an area we risk routing loops or routing black holes in that area.

So the distribute-list command doesn’t affect routes as they enter or leave the OSPF topology database. The distribute-list command affects routes as they go in and out of the routing table. It does not prevent link state packets from being propagated.

This is very important to remember. When Dijkstra’s shortest-path-first algorithm calculates the best path in OSPF it needs to have a complete view of the topology in an area. If it does not, it cannot calculate best paths that are guaranteed to be loop free.

This configuration could still result in a routing black hole if R4 decides to send packets for any other address (other than R3’s Loopback0) via R5.

Let’s check this:

R4:

R4#sh ip ospf data

            OSPF Router with ID (4.4.4.4) (Process ID 1)

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
3.3.3.3         3.3.3.3         41          0x80000003 0x00EE41 2
4.4.4.4         4.4.4.4         45          0x80000003 0x006C85 3
5.5.5.5         5.5.5.5         44          0x80000003 0x000FD1 3

                Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.1.34.4       4.4.4.4         45          0x80000001 0x0018C4
10.1.35.5       5.5.5.5         43          0x80000001 0x0007CB
10.1.45.5       5.5.5.5         54          0x80000001 0x00CAF9

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         3.3.3.3         32          0x80000001 0x006FB2
2.2.2.2         3.3.3.3         42          0x80000001 0x0041DC
3.3.3.3         3.3.3.3         82          0x80000001 0x00AE75
10.0.12.0       3.3.3.3         42          0x80000001 0x00F016
10.0.13.0       3.3.3.3         83          0x80000001 0x00818E
10.0.23.0       3.3.3.3         83          0x80000001 0x0013F2

You can see R4’s topology database above. It has the same entries as R5’s. This is needed by OSPF to make accurate routing decisions.

R4#sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/21] via 10.1.34.3, 00:00:02, Ethernet1/0
     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/21] via 10.1.34.3, 00:00:02, Ethernet1/0
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/11] via 10.1.34.3, 00:00:02, Ethernet1/0
     4.0.0.0/32 is subnetted, 1 subnets
C       4.4.4.4 is directly connected, Loopback0
     5.0.0.0/32 is subnetted, 1 subnets
O       5.5.5.5 [110/11] via 10.1.45.5, 00:00:02, Ethernet1/1
     10.0.0.0/24 is subnetted, 6 subnets
O IA    10.0.12.0 [110/30] via 10.1.34.3, 00:00:02, Ethernet1/0
O IA    10.0.13.0 [110/20] via 10.1.34.3, 00:00:02, Ethernet1/0
O IA    10.0.23.0 [110/20] via 10.1.34.3, 00:00:03, Ethernet1/0
C       10.1.45.0 is directly connected, Ethernet1/1
O       10.1.35.0 [110/20] via 10.1.45.5, 00:00:03, Ethernet1/1
                  [110/20] via 10.1.34.3, 00:00:03, Ethernet1/0
C       10.1.34.0 is directly connected, Ethernet1/0

R4#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/32/52 ms

At the moment R4 is routing everything correctly to R3. Let’s take a look what happens when we shut down R4’s e1/0 interface:

R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#int e1/0
R4(config-if)#shut
R4(config-if)#end

R4#sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/31] via 10.1.45.5, 00:00:03, Ethernet1/1
     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/31] via 10.1.45.5, 00:00:03, Ethernet1/1
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/21] via 10.1.45.5, 00:00:03, Ethernet1/1
     4.0.0.0/32 is subnetted, 1 subnets
C       4.4.4.4 is directly connected, Loopback0
     5.0.0.0/32 is subnetted, 1 subnets
O       5.5.5.5 [110/11] via 10.1.45.5, 00:00:03, Ethernet1/1
     10.0.0.0/24 is subnetted, 5 subnets
O IA    10.0.12.0 [110/40] via 10.1.45.5, 00:00:03, Ethernet1/1
O IA    10.0.13.0 [110/30] via 10.1.45.5, 00:00:03, Ethernet1/1
O IA    10.0.23.0 [110/30] via 10.1.45.5, 00:00:04, Ethernet1/1
C       10.1.45.0 is directly connected, Ethernet1/1
O       10.1.35.0 [110/20] via 10.1.45.5, 00:00:04, Ethernet1/1

Take a look at the routing table above. R4’s OSPF has noticed a topology change and Dijkstra’s shortest-path algorithm has recalculated that the new best path is via R5. Because we still have the same topology database as R5, R4 assumes that this is a valid decision. It doesn’t realise that we are filtering all routes except for 3.3.3.3 on R5.

R4#ping 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/35/72 ms

R4#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)

This results in a routing black hole, which is exactly what we would expect. The distribute-list command doesn’t affect the topology database, only the routing table.

Let’s reset the configuration on R4 and R5 before we proceed:

R4:

R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#int e1/0
R4(config-if)#no shut
R4(config-if)#end

R5:

R5#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R5(config)#no access-list 1
R5(config)#router ospf 1
R5(config-router)#no distribute-list 1 in
R5(config-router)#end

Filtering within an area – Using a distribute-list with a route-map

We can combine the distribute list command with a route-map to give us more flexibility in matching routing table entries. With a route-map on our distribute-list we can use the following options:

match interface
match ip address
match ip next-hop
match ip route-source
match metric
match route-type
match tag

Let’s use the match ip address in conjunction with a prefix-list so we can be more flexible with what gets permitted into our routing table.

Let’s verify the current routing table before we proceed:

R5#sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/21] via 10.1.35.3, 00:00:07, Ethernet1/0
     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/21] via 10.1.35.3, 00:00:07, Ethernet1/0
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/11] via 10.1.35.3, 00:00:07, Ethernet1/0
     4.0.0.0/32 is subnetted, 1 subnets
O       4.4.4.4 [110/11] via 10.1.45.4, 00:00:07, Ethernet1/1
     5.0.0.0/32 is subnetted, 1 subnets
C       5.5.5.5 is directly connected, Loopback0
     10.0.0.0/24 is subnetted, 6 subnets
O IA    10.0.12.0 [110/30] via 10.1.35.3, 00:00:07, Ethernet1/0
O IA    10.0.13.0 [110/20] via 10.1.35.3, 00:00:07, Ethernet1/0
O IA    10.0.23.0 [110/20] via 10.1.35.3, 00:00:08, Ethernet1/0
C       10.1.45.0 is directly connected, Ethernet1/1
C       10.1.35.0 is directly connected, Ethernet1/0
O       10.1.34.0 [110/20] via 10.1.45.4, 00:00:08, Ethernet1/1
                  [110/20] via 10.1.35.3, 00:00:08, Ethernet1/0

You can see in the routing table above we have complete connectivity in our little network. We will use a distribute-list, this time with a route-map to deny all the 10.0.0.0/16 networks (ie. 10.0.12.0/24, 10.0.13.0/24 and 10.0.23.0/24 networks).

R5:

router ospf 1
  distribute-list route-map NO_AREA0 in
!
ip prefix-list AREA0 seq 5 deny 10.0.0.0/16 le 32
ip prefix-list AREA0 seq 10 permit 0.0.0.0/0 le 32
!
route-map NO_AREA0 permit 10
 match ip address prefix-list AREA0

The distribute-list above uses a route-map to deny any networks in the 10.0.0.0/16 supernet. This will cover the 10.0.12.0, 10.0.13.0/24 and 10.0.23.0/24 networks that we want to filter. Everything else will be allowed into our routing table. Let’s verify this:

R5#sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/21] via 10.1.35.3, 00:00:02, Ethernet1/0
     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/21] via 10.1.35.3, 00:00:02, Ethernet1/0
     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/11] via 10.1.35.3, 00:00:02, Ethernet1/0
     4.0.0.0/32 is subnetted, 1 subnets
O       4.4.4.4 [110/11] via 10.1.45.4, 00:00:02, Ethernet1/1
     5.0.0.0/32 is subnetted, 1 subnets
C       5.5.5.5 is directly connected, Loopback0
     10.0.0.0/24 is subnetted, 3 subnets
C       10.1.45.0 is directly connected, Ethernet1/1
C       10.1.35.0 is directly connected, Ethernet1/0
O       10.1.34.0 [110/20] via 10.1.45.4, 00:00:03, Ethernet1/1
                  [110/20] via 10.1.35.3, 00:00:03, Ethernet1/0

The distribute list should not effect the topology database as it only filters routes coming into the route table.

R5#sh ip ospf data

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

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
3.3.3.3         3.3.3.3         1791        0x8000000D 0x00C462 2
4.4.4.4         4.4.4.4         1794        0x8000000E 0x0040A7 3
5.5.5.5         5.5.5.5         1780        0x8000000B 0x00FED9 3

                Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.1.34.3       3.3.3.3         1791        0x80000009 0x004099
10.1.35.5       5.5.5.5         1780        0x80000009 0x00F6D3
10.1.45.5       5.5.5.5         1780        0x80000009 0x00BA02

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         3.3.3.3         1791        0x80000009 0x005FBA
2.2.2.2         3.3.3.3         1791        0x80000009 0x0031E4
3.3.3.3         3.3.3.3         1791        0x80000009 0x009E7D
10.0.12.0       3.3.3.3         1791        0x80000009 0x00E01E
10.0.13.0       3.3.3.3         1792        0x80000009 0x007196
10.0.23.0       3.3.3.3         1792        0x80000009 0x0003FA

Awesome! It worked as anticipated. We still have a complete topology database, however we have successfully filtered the 10.0.12.0/24, 10.0.13.0/24 and 10.0.23.0/24 networks from the route table.

Let’s reset the configuration on R5 before we proceed:

R5#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R5(config)#no route-map NO_AREA0 permit 10
R5(config)#no ip prefix-list AREA0
R5(config)#router ospf 1
R5(config-router)#no  distribute-list route-map NO_AREA0 in
R5(config-router)#end

Using Administrative Distance

We can also filter routes within an OSPF area by changing the the administrative distance of routes to 255 (an invalid route). We can use the distance command to do this.

Let’s take a look at an example.
R5:

router ospf 1
 distance 255 0.0.0.0 255.255.255.255 1
!
access-list 1 permit 3.3.3.3

The example above shows the use of the distance command to filter routes in an OSPF area. The command states that any routes from any router that matches the access-list 1 (ie. the 3.3.3.3/32 network) will be given a administrative distance of 255 (invalid).

The result of this is that the 3.3.3.3/32 network will be filtered from entering the routing table. Let’s verify this:



R5#clear ip route *
R5#sh ip route | b Gateway
Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
O IA    1.1.1.1 [110/21] via 10.1.35.3, 00:00:01, Ethernet1/0
     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/21] via 10.1.35.3, 00:00:01, Ethernet1/0
     4.0.0.0/32 is subnetted, 1 subnets
O       4.4.4.4 [110/11] via 10.1.45.4, 00:00:01, Ethernet1/1
     5.0.0.0/32 is subnetted, 1 subnets
C       5.5.5.5 is directly connected, Loopback0
     10.0.0.0/24 is subnetted, 6 subnets
O IA    10.0.12.0 [110/30] via 10.1.35.3, 00:00:01, Ethernet1/0
O IA    10.0.13.0 [110/20] via 10.1.35.3, 00:00:01, Ethernet1/0
O IA    10.0.23.0 [110/20] via 10.1.35.3, 00:00:01, Ethernet1/0
C       10.1.45.0 is directly connected, Ethernet1/1
C       10.1.35.0 is directly connected, Ethernet1/0
O       10.1.34.0 [110/20] via 10.1.45.4, 00:00:01, Ethernet1/1
                      [110/20] via 10.1.35.3, 00:00:01, Ethernet1/0

Looks great! We have routes for everything except for the 3.3.3.3/32 network. This should have not affected the topology database. Lets verify this:

R5#sh ip ospf data

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

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
3.3.3.3         3.3.3.3         964         0x8000000E 0x00C263 2
4.4.4.4         4.4.4.4         978         0x8000000F 0x003EA8 3
5.5.5.5         5.5.5.5         985         0x8000000C 0x00FCDA 3

                Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.1.34.3       3.3.3.3         964         0x8000000A 0x003E9A
10.1.35.5       5.5.5.5         985         0x8000000A 0x00F4D4
10.1.45.5       5.5.5.5         985         0x8000000A 0x00B803

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         3.3.3.3         964         0x8000000A 0x005DBB
2.2.2.2         3.3.3.3         964         0x8000000A 0x002FE5
3.3.3.3         3.3.3.3         964         0x8000000A 0x009C7E
10.0.12.0       3.3.3.3         964         0x8000000A 0x00DE1F
10.0.13.0       3.3.3.3         965         0x8000000A 0x006F97
10.0.23.0       3.3.3.3         965         0x8000000A 0x0001FB

Nice! It worked as anticipated. We successfully filtered the route from entering the routing table but not the topology database.

When you perform route filtering within an OSPF area with the distribute-list and distance commands you are filtering routes as they enter the route-table, not the topology database. The topology database must be consistent within an area for the Dijkstra’s shortest path first algorithm to work correctly. It does not affect LSA propagation.

That’s it for filtering with an OSPF area. In the next article we will be looking at filtering between areas. Stay tuned. Now back to labs!

Summary:

You can use a distribute-list or distance command to filter routes within an area.
The distribute-list and distance commands filter routes as they enter the routing-table not the topology database.
The distribute-list and distance commands do not affect link state packet progagation

Resources:

Dynamips/Dynagen .net configuration file

Read this article and more like it on ardenpackeer.com
Follow me on twitter: http://twitter.com/ardenpackeer

Tutorial: Filtering Routes in OSPF Part 1 » Filtering Within An Area

Tutorial: IPv6 Tunnels Part 2 – Automatic 6to4 Tunnels

Arden Packeer, CCIE #20716 — Sat, 31 May 2008 10:10:53 +0000

In our previous article on IPv6 tunnels, we looked at manual GRE and IPv6IP Tunnels in order to provide connectivity for IPv6 networks segregated by an IPv4 network. By tunneling IPv6 over IP, we can migrate our internal networks to IPv6 and still have communication between these networks, even though we are seperated by an IPv4 network. In this article we will be using another method to provide connectivity for IPv6 networks segregated by an IPv4 network: The Automatic 6to4 Tunnel! Mastering IPv6 is not only an important part of a CCIE candidates journey, but will become increasingly important as the global pool of IPv4 addresses diminishes.

We will be using the following topology for this tutorial:

Dynagen .net configuration:

ghostios = True
sparsemem = True
model = 3640

[localhost]

    [[3640]]
        image = \Program Files\Dynamips\images\c3640-ik9o3s-mz.124-7.bin
        # On Linux / Unix use forward slashes:
        # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
        ram = 96

    [[ROUTER R1]]
        f0/0 = LAN 1
        s1/0 = FRAME 1
        console = 2000
        model = 3640

    [[ROUTER R2]]
        f0/0 = LAN 2
        s1/0 = FRAME 2
        console = 2001
        model = 3640

    [[ROUTER R3]]
        f0/0 = LAN 3
        s1/0 = FRAME 3
        console = 2002
        model = 3640

    [[FRSW FRAME]]
        1:102 = 2:201
        1:103 = 3:301

You can download the dynagen/dynamips .net configuration file for this topology here.

Lets have a look at the basic configuration for this topology:

hostname R1
!
ipv6 unicast-routing
!
interface Loopback0
 ip address 10.10.10.10 255.255.255.0
!
interface FastEthernet0/0
 no ip address
 ipv6 address 2001:1:1:1::1/64
!
interface Serial1/0
 ip address 10.1.123.1 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-multipoint
 frame-relay map ip 10.1.123.2 102 broadcast
 frame-relay map ip 10.1.123.3 103 broadcast
 no frame-relay inverse-arp
!
router ospf 1
 router-id 10.10.10.10
 log-adjacency-changes
 network 0.0.0.0 255.255.255.255 area 0

hostname R2
!
ipv6 unicast-routing
!
interface Loopback0
 ip address 10.20.20.20 255.255.255.0
!
interface FastEthernet0/0
 no ip address
 ipv6 address 2001:2:2:2::2/64
!
interface Serial1/0
 ip address 10.1.123.2 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-multipoint
 frame-relay map ip 10.1.123.1 201 broadcast
 frame-relay map ip 10.1.123.3 201
 no frame-relay inverse-arp
!
router ospf 1
 router-id 10.20.20.20
 log-adjacency-changes
 network 0.0.0.0 255.255.255.255 area 0

hostname R3
!
ipv6 unicast-routing
!
interface Loopback0
 ip address 10.30.30.30 255.255.255.0
!
interface FastEthernet0/0
 no ip address
 ipv6 address 2001:3:3:3::3/64
!
interface Serial1/0
 ip address 10.1.123.3 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-multipoint
 frame-relay map ip 10.1.123.1 301 broadcast
 frame-relay map ip 10.1.123.2 301
 no frame-relay inverse-arp
!
router ospf 1
 router-id 10.30.30.30
 log-adjacency-changes
 network 0.0.0.0 255.255.255.255 area 0

This is the same basic configuration we used in our previous article on IPv6 tunnels. We have a hub-and-spoke frame-relay topology with R1 acting as the hub. Looking at the route table, we should have full connectivity between all the hubs and spokes and their corresponding loopbacks over IPv4.

R3#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
O       10.10.10.10/32 [110/65] via 10.1.123.1, 00:15:53, Serial1/0
C       10.30.30.0/24 is directly connected, Loopback0
O       10.20.20.20/32 [110/129] via 10.1.123.1, 00:15:53, Serial1/0
C       10.1.123.0/24 is directly connected, Serial1/0
O       10.1.123.1/32 [110/64] via 10.1.123.1, 00:15:53, Serial1/0
O       10.1.123.2/32 [110/128] via 10.1.123.1, 00:15:53, Serial1/0

R1#ping 10.30.30.30 source lo0 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.30.30.30, timeout is 2 seconds:
Packet sent with a source address of 10.10.10.10
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/100/160 ms

Looks good we have complete IPv4 connectivity. Excellent! But what about IPv6?

R3#ping 2001:1:1:1::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:1:1:1::1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R3#sh ipv6 route
IPv6 Routing Table - 4 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       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
C   2001:3:3:3::/64 [0/0]
     via ::, FastEthernet0/0
L   2001:3:3:3::3/128 [0/0]
     via ::, FastEthernet0/0
L   FE80::/10 [0/0]
     via ::, Null0
L   FF00::/8 [0/0]
     via ::, Null0

The routers don’t have any connectivity between IPv6 because the IPv6 stack of the router doesn’t have any routes to the other IPv6 networks.

We had the exact same problem in our previous article on IPv6 Tunnels. We solved this using manual GRE and IPv6IP tunnels but wouldn’t it be cool if we could do something like this:

ipv6 route 2001:1:1:1::/64 10.10.10.10

The command above will not work but it demonstrates the basic premise of the need for 6to4 tunnels. We want to get to the 2001:1:1:1::/64 network via an IPv4 address. The ipv6 route command above won’t work because we must have an IPv6 destination. 6to4 tunnels get around this by representing the IPv4 address as an IPv6 address.

Representing an IPv4 Address as a IPv6 Address in 6to4 Tunnels

6to4 tunnel addresses have the format 2002:<32 bit IPv4 site address in Hex>. Following the embedded IPv4 site address are 16 bits that can be used to number networks within the site, so we end up with:

2002:<32 bit IPv4 site address in Hex>:<16 bit network number in Hex>::/64

The easiest way to demonstrate this is to look at an example:
R1

interface Loopback0
 ip address 10.10.10.10 255.255.255.0
 ipv6 address 2002:0A0A:0A0A:0000::1/64

Here we have converted the 10.10.10.10 address to a hexadecimal number of 0A0A:0A0A (IOS will truncate the leading zeros of all the hexadecimal fields, but I have included them here for clarity). We will call this our site address because we want everyone that wants to get to R1’s IPv6 network (2001:1:1:1::/64), our IPv6 site, to go via the IPv4 address of 10.10.10.10. We have also allocated the Loopback0 interface to be in the 0000 (ie. the first) network of the site.

interface Loopback0
 ip address 10.20.20.20 255.255.255.0
 ipv6 address 2002:0A14:1414:0000::2/64

interface Loopback0
 ip address 10.30.30.30 255.255.255.0
 ipv6 address 2002:0A1E:1E1E:0000::3/64

Here we have converted the 10.20.20.20 address on R2 to a hexadecimal number of 0A14:1414 (10.20.20.20 in hexadecimal). This will be R2’s site address. We want everyone that wants to get to R2’s IPv6 network to go via the IPv4 address of 10.20.20.20. R3’s loopback0 has been also been given an 6to4 address. Both R2 and R3’s Loopback0 interfaces have been put int he 0000 network of their corresponding IPv6 site address.

Cool so now we have our Loopback address allocated with IPv6 6to4 addresses. These addresses are the IPv6 representation of the IPv4 addresses. We will use them in our static routes to say that to get to the IPv6 networks use these IPv4 addresses represented as IPv6 addresses.

Time to get to the tunnel!

6to4 tunnels

6to4 tunnels are not point-to-point tunnels like manual GRE or manual IPv6IP tunnels. 6to4 tunnels are multi-point tunnels. The tunnel interfaces just need a source address and the destination address is derived from the destination of a packet. When I first started analyzing 6to4 tunnels, I kept thinking “what do you mean the tunnels don’t need a destination address?!!”. This was usually followed by various expletives about why this stuff didn’t work. It was only when it clicked that the 6to4 tunnels are multipoint tunnels that it made sense.

Let’s take a look at an example:

The diagram above shows what will be implementing in this tutorial. We will be creating a tunnel interface (tu0) on R1, R2, and R3. These tunnel interfaces will be given a 6to4 IPv6 address that matches there corresponding Loopback IPv4 address. Remember that the routers already have IPv4 connectivity between there loopback address because OSPF is advertising the loopback address into the OSPF area. We want to be able to get to the IPv6 networks via these addresses.

Let’s have a look at R1’s configuration for this:

interface Tunnel0
 no ip address
 no ip redirects
 ipv6 address 2002:A0A:A0A:FFFF::1/64
 tunnel source Loopback0
 tunnel mode ipv6ip 6to4
!
interface Loopback0
 ip address 10.10.10.10 255.255.255.0
 ipv6 address 2002:A0A:A0A::1/64
!
ipv6 route 2002::/16 Tunnel0

You can see above that the Tunnel0 interface of R1 has an IPv6 6to4 address. Both Loopback0 and Tunnel0 have been assigned addresses in 2002:0A0A:0A0A::/48. Loopback0 is in the 2002:0A0A:0A0A:0000::/64 network. Tunnel0 is in the 2002:0A0A:0A0A:FFFF::/64. We have added a route that says, anything with an IPv6 6to4 address (2002::/16) send it out tu0.

interface Tunnel0
 no ip address
 no ip redirects
 ipv6 address 2002:A14:1414:FFFF::2/64
 tunnel source Loopback0
 tunnel mode ipv6ip 6to4
!
interface Loopback0
 ip address 10.20.20.20 255.255.255.0
 ipv6 address 2002:A14:1414::2/64
!
ipv6 route 2002::/16 Tunnel0

interface Tunnel0
 no ip address
 no ip redirects
 ipv6 address 2002:A1E:1E1E:FFFF::3/64
 tunnel source Loopback0
 tunnel mode ipv6ip 6to4
!
interface Loopback0
 ip address 10.30.30.30 255.255.255.0
 ipv6 address 2002:A1E:1E1E::3/64
!
ipv6 route 2002::/16 Tunnel0

Why don’t we need a destination address for the tunnel? Let’s have a look at the basic packet flow. Lets say on R3 we issue a ping 2002:A0A:A0A::1 (trying to get to R1’s Lo0 IPv6 address). R3 looks up its route table and sees the output interface for the destination packet is tu0. This is because we have a static route that says anything that starts with 2002::/16 send it out tu0. This interface has 6to4 tunnel encapsulation turned on. R3 takes the IPv6 destination Address of the ping packet (2002:A0A:A0A::1) and converts it into an IPv4 address. This results in an IPv4 destination address of 10.10.10.10. The IPv6 ping packet is then encapsulated in an IPv4 header. and sent along to 10.10.10.10.

We end up with a packet that looks like this:

Let’s verify this:

R3#debug ip packet detail
IP packet debugging is on (detailed)
R3#ping 2002:A0A:A0A::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2002:A0A:A0A::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 100/146/224 ms
R3#
IP: tableid=0, s=10.30.30.30 (local), d=10.10.10.10 (Serial1/0), routed via FIB
IP: s=10.30.30.30 (local), d=10.10.10.10 (Serial1/0), len 120, sending, proto=41
IP: tableid=0, s=10.10.10.10 (Serial1/0), d=10.30.30.30 (Loopback0), routed via RIB
IP: s=10.10.10.10 (Serial1/0), d=10.30.30.30, len 120, rcvd 4, proto=41
IP: tableid=0, s=10.30.30.30 (local), d=10.10.10.10 (Serial1/0), routed via FIB
IP: s=10.30.30.30 (local), d=10.10.10.10 (Serial1/0), len 120, sending, proto=41
IP: tableid=0, s=10.10.10.10 (Serial1/0), d=10.30.30.30 (Loopback0), routed via RIB
IP: s=10.10.10.10 (Serial1/0), d=10.30.30.30, len 120, rcvd 4, proto=41
IP: tableid=0, s=10.30.30.30 (local), d=10.10.10.10 (Serial1/0), routed via FIB
IP: s=10.30.30.30 (local), d=10.10.10.10 (Serial1/0), len 120, sending, proto=41
IP: tableid=0, s=10.10.10.10 (Serial1/0), d=10.30.30.30 (Loopback0), routed via RIB
IP: s=10.10.10.10 (Serial1/0), d=10.30.30.30, len 120, rcvd 4, proto=41
IP: tableid=0, s=10.30.30.30 (local), d=10.10.10.10 (Serial1/0), routed via FIB
IP: s=10.30.30.30 (local), d=10.10.10.10 (Serial1/0), len 120, sending, proto=41
IP: tableid=0, s=10.10.10.10 (Serial1/0), d=10.30.30.30 (Loopback0), routed via RIB
IP: s=10.10.10.10 (Serial1/0), d=10.30.30.30, len 120, rcvd 4, proto=41
IP: tableid=0, s=10.30.30.30 (local), d=10.10.10.10 (Serial1/0), routed via FIB
IP: s=10.30.30.30 (local), d=10.10.10.10 (Serial1/0), len 120, sending, proto=41
IP: tableid=0, s=10.10.10.10 (Serial1/0), d=10.30.30.30 (Loopback0), routed via RIB
IP: s=10.10.10.10 (Serial1/0), d=10.30.30.30, len 120, rcvd 4, proto=41

Take a look at the source and destination addresses of that debug. Even though we pinged an IPv6 address, you can see that the IPv6 icmp packet is encapsulated into an IPv4 packet. We now have connectivity between our Loopback0 IPv6 addresses!

We still cannot ping the internal IPv6 addresses:

R3#ping 2001:1:1:1::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:1:1:1::1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R3#sh ipv6 route
IPv6 Routing Table - 9 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       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
C   2001:3:3:3::/64 [0/0]
     via ::, FastEthernet0/0
L   2001:3:3:3::3/128 [0/0]
     via ::, FastEthernet0/0
S   2002::/16 [1/0]
     via ::, Tunnel0
C   2002:A1E:1E1E::/64 [0/0]
     via ::, Loopback0
L   2002:A1E:1E1E::3/128 [0/0]
     via ::, Loopback0
C   2002:A1E:1E1E:FFFF::/64 [0/0]
     via ::, Tunnel0
L   2002:A1E:1E1E:FFFF::3/128 [0/0]
     via ::, Tunnel0
L   FE80::/10 [0/0]
     via ::, Null0
L   FF00::/8 [0/0]
     via ::, Null0

Why? Take a look at that route table. If I try to ping 2001:1:1:1::1 what will it match? Nothing. We need routes for those networks. Remember earlier in the tutorial when we said we needed something like:

ipv6 route 2001:1:1:1::/64 10.10.10.10

Well, after we create our tu0 interface on R1, we could rewrite this route on R2, and R3 as:

ipv6 route 2001:1:1:1::/64 2002:A0A:A0A::1

This effectively means, anything we get for the 2001:1:1:1::/64 network send it to 10.10.10.10. We know that we have connectivity to 2002:A0A:A0A::1. We proved that above. After we add the route above, when we try to ping 2001:1:1:1::1 from R3 the router looks at the route table and matches a destination address of 2002:A0A:A0A::1. We need to perform route recursion to an interface, so we then do a lookup of 2002:A0A:A0A::1 and we match the tu0 interface. This interface has 6to4 tunnel encapsulation turned on. R3 takes the IPv6 destination Address of the ping packet (2002:A0A:A0A::1) and converts it into an IPv4 address. This results in an IPv4 destination address of 10.10.10.10. The IPv6 ping packet is then encapsulated in an IPv4 header and sent along to 10.10.10.10.

Lets set up the routes for each of the IPv6 networks and test it:
R1

ipv6 route 2001:2:2:2::/64 2002:A14:1414::2
ipv6 route 2001:3:3:3::/64 2002:A1E:1E1E::3

ipv6 route 2001:1:1:1::/64 2002:A0A:A0A::1
ipv6 route 2001:3:3:3::/64 2002:A1E:1E1E::3

ipv6 route 2001:1:1:1::/64 2002:A0A:A0A::1
ipv6 route 2001:2:2:2::/64 2002:A14:1414::2

R3#ping 2001:2:2:2::2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:2:2:2::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 136/180/260 ms

Woohoo! Awesome! We have successfully implemented 6to4 automatic tunnels! This can be quite a difficult concept to grasp, so I recommend implementing the above in dynamips and playing around with the concepts. Once you understand how to convert IPv4 address to 6to4 address and that 6to4 tunnels are multipoint tunnels the rest is pretty easy.

I really hope this helps. Please leave a comment below if you have any questions or comments. Now back to labs!

Summary:

IPv6 6to4 Automatic tunnels allow you to join up IPv6 networks segregated by an IPv4 network.
IPv6 6to4 Automatic tunnels are a multipoint tunnel
IPv6 6to4 Automatic tunnels represent an IPv4 address endpoint as an IPv6 address to join segregated IPv6 networks

Resources:

Dynamips/Dynagen .net configuration file

Read this article and more like it on ardenpackeer.com
Follow me on twitter: http://twitter.com/ardenpackeer

Tutorial: IPv6 Tunnels Part 2 – Automatic 6to4 Tunnels

Tutorial: BGP Conditional Route Injection with inject-map

Arden Packeer, CCIE #20716 — Sat, 19 Apr 2008 00:07:59 +0000

One of the great new features that was introduced in IOS 12.0 is BGP conditional route injection. With conditional route injection we can insert more specific routes into a BGP table based on the existance of another route. Most of the routes in the current internet BGP table consists of aggregate routes. This is used to minimize the size and number of routes in global BGP routing table. The aggregation of routes can sometimes obscure more specific and accurate routing information. Wouldn’t it be cool if we could control and “un-aggregate” those routes on demand? Well that’s kinda what BGP conditional route injection does. It allows us to originate a more specific prefix into the BGP routing table based on an existing aggregated route.

We will be using the following topology for this tutorial:

The Dynagen .net file that respresents the above topology for this tutorial is shown below:

ghostios = True
sparsemem = True
model = 3640

[localhost]

    [[3640]]
        image = \Program Files\Dynamips\images\c3640-jk9o3s-mz.124-12.bin
        # On Linux / Unix use forward slashes:
        # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
        ram = 96

    [[ROUTER R1]]
        f0/0 = LAN 12
        console = 2000
        model = 3640

    [[ROUTER R2]]
        f0/0 = LAN 12
        f1/0 = LAN 23
        console = 2001
        model = 3640

    [[ROUTER R3]]
        f0/0 = LAN 23
        console = 2002
        model = 3640

You can download the dynagen .net file here.

Initial Setup

Let’s set up the basic topology above. We will advertise the 1.1.1.0/25 and 1.1.1.128/25 loopbacks on R1 as an aggregate address 1.1.1.0/24 into the bgp routing table. R2, and R3 will not be able to see the specific routes but only the aggregate route.

R1:

hostname R1
!
interface Loopback0
 ip address 1.1.1.1 255.255.255.128
!
interface Loopback1
 ip address 1.1.1.129 255.255.255.128
!
interface FastEthernet0/0
 ip address 192.168.12.1 255.255.255.0
!
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 network 1.1.1.0 mask 255.255.255.128
 network 1.1.1.128 mask 255.255.255.128
 aggregate-address 1.1.1.0 255.255.255.0 summary-only
 neighbor 192.168.12.2 remote-as 2
 no auto-summary

R2:

hostname R2
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.0
!
interface FastEthernet0/0
 ip address 192.168.12.2 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet1/0
 ip address 192.168.23.2 255.255.255.0
 duplex auto
 speed auto
!
router bgp 2
 no synchronization
 bgp log-neighbor-changes
 neighbor 192.168.12.1 remote-as 1
 neighbor 192.168.23.3 remote-as 3
 no auto-summary

R3:

hostname R3
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.0
!
interface FastEthernet0/0
 ip address 192.168.23.3 255.255.255.0
 duplex auto
 speed auto
!
router bgp 3
 no synchronization
 bgp log-neighbor-changes
 neighbor 192.168.23.2 remote-as 2
 no auto-summary

Pretty simple. R1, R2, and R3 are in BGP AS 1, 2, and 3 respectively. Let’s verify the BGP tables on R1 and R2.

R1#sh ip bgp
BGP table version is 6, local router ID is 1.1.1.129
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
s> 1.1.1.0/25       0.0.0.0                  0         32768 i
*> 1.1.1.0/24       0.0.0.0                            32768 i
s> 1.1.1.128/25     0.0.0.0                  0         32768 i

You can see above that R1 has the more specific routes and the aggregate in its BGP table. The more specific routes are being suppressed, so the only route that R2 and R3 should see is that aggregate route (1.1.1.0/24).

R2#sh ip bgp
BGP table version is 2, local router ID is 2.2.2.2
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
*> 1.1.1.0/24       192.168.12.1             0             0 1 i

R3#sh ip bgp
BGP table version is 4, local router ID is 3.3.3.3
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
*> 1.1.1.0/24       192.168.23.2                           0 2 1 i

Looks good. R2 and R3 have received the aggregate route.

BGP inject-map

We will be using the bgp inject-map command to originate some routes. We will set up R2, so that if the 1.1.1.0/24 aggregate routes exist in its BGP table it will “un-aggregate” those routes. R2 will test if it is receiving the aggregate address from R1, before it originates the more specific routes.

Let’s take a look at the configuration for this:

R2:

ip prefix-list ROUTE seq 5 permit 1.1.1.0/24
!
ip prefix-list ROUTE_SOURCE seq 5 permit 192.168.12.1/32
!
route-map LEARNED_ROUTE permit 10
 match ip address prefix-list ROUTE
 match ip route-source prefix-list ROUTE_SOURCE

Firstly we have defined the route that we want to match using a prefix list (ROUTE), and source of that prefix using another prefix list (ROUTE_SOURCE). The route prefix list must match prefix we are looking for in the BGP table exactly, and the route source prefix list MUST be a /32 source. We have tied the two together in a route-map. The route map is matching both the route and where we learned it from.

So that’s the first part. We will be using that route-map later on in the BGP inject-map to specify the condition that must exist.

Next we need to define what to originate if that condition exists:

R2:

ip prefix-list UNAGGREGATED_ROUTES seq 5 permit 1.1.1.0/25
ip prefix-list UNAGGREGATED_ROUTES seq 10 permit 1.1.1.128/25
!
route-map ORIGINATE permit 10
 set ip address prefix-list UNAGGREGATED_ROUTES

We have created a single prefix list called UNAGGREGATED_ROUTES that defines the more specific routes we want to originate. We can originate any route that is a subnet of the aggregate address (so I could have just as easily originated three routes 1.1.1.0/26, 1.1.1.64/26, 1.1.1.128/25), however they must be a subnet of the aggregate address.

We have tied this together with another route-map called ORIGINATE. This will set the ip prefixes we want to originate based on the UNAGGREGATED_ROUTES prefix list. ie ORIGINATE those UNAGGREGATED_ROUTES. :)

So we have two route-maps. ORIGINATE is the route-map containing prefixes we want to originate. LEARNED_ROUTE is the condition we want to match.

R2:

router bgp 2
 bgp inject-map ORIGINATE exist-map LEARNED_ROUTE

Finally we have our BGP inject-map statement. The inject-map command takes two arguments. The first is a route-map containing prefixes we want to originate. The second is a route-map that contains the conditions that must be met before we originate the prefixes defined in the first route-map. Cool huh?

Verification

The first thing we should do is check whether the unaggregated routes are in R2’s BGP table:

R2#sh ip bgp
BGP table version is 4, local router ID is 2.2.2.2
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
*> 1.1.1.0/25       192.168.12.1                           0 ?
*> 1.1.1.0/24       192.168.12.1             0             0 1 i
*> 1.1.1.128/25     192.168.12.1                           0 ?

Looks good. If they unaggregated routes don’t show up check whether you have defined a /32 route source and that you are matching a prefix correctly.

We can verifying what bgp paths are injected using the show ip bgp injected-paths command.

R2#sh ip bgp injected-paths
BGP table version is 4, local router ID is 2.2.2.2
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
*> 1.1.1.0/25       192.168.12.1                           0 ?
*> 1.1.1.128/25     192.168.12.1                           0 ?

Looks great. Finally, lets check if they show up on R3.

R3#sh ip bgp
BGP table version is 4, local router ID is 3.3.3.3
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
*> 1.1.1.0/25       192.168.23.2                           0 2 ?
*> 1.1.1.0/24       192.168.23.2                           0 2 1 i
*> 1.1.1.128/25     192.168.23.2                           0 2 ?

Awesome! This could really come in handy. Especially if you are doing route policies where you want more fine grain control on how they apply to individual subnets of an aggregate address. HTH. Now back to labs!

Summary:

BGP conditional route injection allows us to originate more specific prefixes based on an existing aggregate prefix.
We use the bgp inject-map command to perform conditional route injection
We can only originate more specific subnets of an existing aggregate prefix

Resources:

Dynamips/Dynagen .net configuration file

Read this article and more like it on ardenpackeer.com
Follow me on twitter: http://twitter.com/ardenpackeer

Tutorial: BGP Conditional Route Injection with inject-map

Mock Lab 6 Analysis – RIP Summary Address and Default Routes

Arden Packeer, CCIE #20716 — Mon, 14 Apr 2008 07:28:53 +0000

I ran into this strange problem while doing Mock Lab 6, and I thought it warranted an article because it highlights why the order of operations that IOS performs certain tasks is important.

Let’s say you have this scenario:

R4 is a border router between two routing domains, OSPF and RIPv2. We are doing mutual redistribution between OSPF and RIPv2. Simple enough.

R4:

router ospf 1
 version 2
 router-id 150.1.4.4
 log-adjacency-changes
 redistribute rip subnets
 network 150.1.4.4 0.0.0.0 area 0
 network 176.1.45.4 0.0.0.0 area 45
 network 176.1.145.4 0.0.0.0 area 0
!
router rip
 version 2
 redistribute ospf 1 metric 1
 passive-interface default
 no passive-interface Ethernet0/0.46
 network 176.1.0.0
 no auto-summary

Let’s have a look at the route table of both R4 and R6 to verify that we have connectivity

R4:

R4#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     54.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
R       54.1.7.0/24 [120/1] via 176.1.46.6, 00:00:01, Ethernet0/0.46
R       54.1.7.254/32 [120/1] via 176.1.46.6, 00:00:01, Ethernet0/0.46
R    212.18.1.0/24 [120/2] via 176.1.46.6, 00:00:01, Ethernet0/0.46
R    212.18.0.0/24 [120/2] via 176.1.46.6, 00:00:01, Ethernet0/0.46
R    212.18.3.0/24 [120/2] via 176.1.46.6, 00:00:01, Ethernet0/0.46
     176.1.0.0/16 is variably subnetted, 5 subnets, 2 masks
C       176.1.145.0/24 is directly connected, Serial1/0
C       176.1.45.5/32 is directly connected, Serial1/1
C       176.1.45.0/24 is directly connected, Serial1/1
C       176.1.46.0/24 is directly connected, Ethernet0/0.46
C       176.1.4.0/24 is directly connected, Ethernet0/0.4
R    212.18.2.0/24 [120/2] via 176.1.46.6, 00:00:03, Ethernet0/0.46
     150.1.0.0/16 is variably subnetted, 3 subnets, 2 masks
C       150.1.4.0/24 is directly connected, Loopback0
O       150.1.5.5/32 [110/782] via 176.1.145.5, 00:00:04, Serial1/0
O       150.1.1.1/32 [110/782] via 176.1.145.1, 00:00:04, Serial1/0

R6:

R6#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     54.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       54.1.7.0/24 is directly connected, Loopback1
C       54.1.7.254/32 is directly connected, Virtual-Access1
R    212.18.1.0/24 [120/1] via 54.1.7.254, 00:00:01, Virtual-Access1
R    212.18.0.0/24 [120/1] via 54.1.7.254, 00:00:01, Virtual-Access1
R    212.18.3.0/24 [120/1] via 54.1.7.254, 00:00:01, Virtual-Access1
     176.1.0.0/16 is variably subnetted, 5 subnets, 2 masks
R       176.1.145.0/24 [120/1] via 176.1.46.4, 00:00:05, Ethernet0/0
R       176.1.45.5/32 [120/1] via 176.1.46.4, 00:00:05, Ethernet0/0
R       176.1.45.0/24 [120/1] via 176.1.46.4, 00:00:05, Ethernet0/0
C       176.1.46.0/24 is directly connected, Ethernet0/0
R       176.1.4.0/24 [120/1] via 176.1.46.4, 00:00:05, Ethernet0/0
R    212.18.2.0/24 [120/1] via 54.1.7.254, 00:00:02, Virtual-Access1
     150.1.0.0/16 is variably subnetted, 4 subnets, 2 masks
C       150.1.6.0/24 is directly connected, Loopback0
R       150.1.4.0/24 [120/1] via 176.1.46.4, 00:00:06, Ethernet0/0
R       150.1.5.5/32 [120/1] via 176.1.46.4, 00:00:06, Ethernet0/0
R       150.1.1.1/32 [120/1] via 176.1.46.4, 00:00:06, Ethernet0/0

The routing table looks good, and it looks like all routes from OSPF on R4 are being passed into RIP and are seen by R6. We should now have connectivity from R4 to BB1 (54.1.7.254).

R4#ping 54.1.7.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 54.1.7.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/48/52 ms

Let’s do some summarization. We want to summarize at the 176.1.0.0/16 and 150.1.0.0/16 network boundaries on R4 before we send them to R6.

R4:

interface Ethernet0/0.46
 encapsulation dot1Q 46
 ip address 176.1.46.4 255.255.255.0
 ip summary-address rip 176.1.0.0 255.255.0.0
 ip summary-address rip 150.1.0.0 255.255.0.0

R6:

R6#clear ip route *
R6#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     54.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       54.1.7.0/24 is directly connected, Loopback1
C       54.1.7.254/32 is directly connected, Virtual-Access1
R    212.18.1.0/24 [120/1] via 54.1.7.254, 00:00:01, Virtual-Access1
R    212.18.0.0/24 [120/1] via 54.1.7.254, 00:00:01, Virtual-Access1
R    212.18.3.0/24 [120/1] via 54.1.7.254, 00:00:01, Virtual-Access1
     176.1.0.0/16 is variably subnetted, 2 subnets, 2 masks
C       176.1.46.0/24 is directly connected, Ethernet0/0
R       176.1.0.0/16 [120/1] via 176.1.46.4, 00:00:02, Ethernet0/0
R    212.18.2.0/24 [120/1] via 54.1.7.254, 00:00:00, Virtual-Access1
     150.1.0.0/16 is variably subnetted, 2 subnets, 2 masks
C       150.1.6.0/24 is directly connected, Loopback0
R       150.1.0.0/16 [120/2] via 176.1.46.4, 00:00:02, Ethernet0/0

You can see above that the routes have been summarized correctly on R6. This summarization will in turn be passed onto BB1 and connectivity from R4 will be maintained because of this.

So far so good. Okay now for the fun part. R6’s only connection to the rest of the network is via R4. Let’s send a default-route to R6 from R4. But this isn’t an ordinary default route. We want to make sure that R6 doesn’t pass on that default-route it learns from R4 onto BB1. BB1 should still get the 176.1.0.0/16 and 150.1.0.0/16 summaries though. Sounds simple. Oh and we can only do the configuration on R4 (Evil mock lab writers!).

Let’s try this:

R4:

router rip
 default-information originate route-map DEFAULT
!
route-map DEFAULT permit 10
 set metric 15
!

On R4, we are generating a default route with a route-map attached. The route-map forces a metric of 15 on the default route. This way when R6 gets it, it should have a metric of 15. RIP’s maximum metric is 16 so when BB1, gets this route it will be marked as invalid (ie not accept the route).

Let’s verify this on R6:

R6#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 176.1.46.4 to network 0.0.0.0

     54.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       54.1.7.0/24 is directly connected, Loopback1
C       54.1.7.254/32 is directly connected, Virtual-Access1
R    212.18.1.0/24 [120/1] via 54.1.7.254, 00:00:10, Virtual-Access1
R    212.18.0.0/24 [120/1] via 54.1.7.254, 00:00:10, Virtual-Access1
R    212.18.3.0/24 [120/1] via 54.1.7.254, 00:00:10, Virtual-Access1
     176.1.0.0/16 is variably subnetted, 2 subnets, 2 masks
C       176.1.46.0/24 is directly connected, Ethernet0/0
R       176.1.0.0/16 [120/15] via 176.1.46.4, 00:00:13, Ethernet0/0
R    212.18.2.0/24 [120/1] via 54.1.7.254, 00:00:11, Virtual-Access1
     150.1.0.0/16 is variably subnetted, 2 subnets, 2 masks
C       150.1.6.0/24 is directly connected, Loopback0
R       150.1.0.0/16 [120/15] via 176.1.46.4, 00:00:13, Ethernet0/0
R*   0.0.0.0/0 [120/15] via 176.1.46.4, 00:00:15, Ethernet0/0

R6#debug ip rip
RIP protocol debugging is on
R6#cle
5d20h: RIP: received v2 update from 176.1.46.4 on Ethernet0/0
5d20h:      0.0.0.0/0 via 0.0.0.0 in 15 hops
5d20h:      150.1.0.0/16 via 0.0.0.0 in 15 hops
5d20h:      176.1.0.0/16 via 0.0.0.0 in 15 hops
5d20h: RIP: sending v2 flash update to 224.0.0.9 via Virtual-Access1 (54.1.7.6)
5d20h: RIP: build flash update entries
5d20h:  0.0.0.0/0 via 0.0.0.0, metric 16, tag 0
5d20h:  54.1.7.0/24 via 0.0.0.0, metric 1, tag 0
5d20h:  150.1.0.0/16 via 0.0.0.0, metric 16, tag 0
5d20h:  176.1.0.0/16 via 0.0.0.0, metric 16, tag 0
5d20h:  176.1.46.0/24 via 0.0.0.0, metric 1, tag 0

Looks like we got the default route with a metric of 15, and we are sending it on the BB1 with a metric of 16. Looks great, but take a look closer.

The Mock Lab 6 solution guide, presents the answer above. Now, I don’t really like this solution because check out the metrics for the 176.1.0.0/16 and the 150.1.0.0/16 routes. They are 15 on R6 as well! Why? Well think about how rip chooses a metric when it summarizes a route. The Cisco documentation states “RIPv2 route summarization requires that the lowest metric of the “best route” of an aggregated entry, or the lowest metric of all current child routes, be advertised. The best metric for aggregated summarized routes is calculated at route initialization or when there are metric modifications of specific routes at advertisement time, and not at the time the aggregated routes are advertised.”

So when RIPv2 summarizes a route, it choses the lowest metric of all the routes that it is summarizing and then advertises that as the metric. So why do we have the 176.1.0.0/16 and 150.1.0.0/16 networks advertised as 15? Well, what I think is happening is for some crazy reason IOS considers the 0.0.0.0/0 route a child of these summaries, so they get its metric. Crazy! I don’t think that should happen, but okay. When I change the metric on the default route, these summaries will get that as well. The only reason I can think of for this is because the default route is generated first, then the summary-addresses are calculated.

So how do we fix this? Well let’s try this:

R4:

router rip
 default-information originate
 offset-list DEFAULT out 14 Ethernet0/0.46
!
ip access-list standard DEFAULT
 permit 0.0.0.0

We’ve changed the default-information originate to one with a route-map and then we’ve applied an offset-list to change the metric to 14 of that default route. “Hang on a sec Arden, didn’t you just say that whatever you change the default route metric it will change the summary route metric as well?”. Let’s take a look at R4:

R4#debug ip rip
RIP protocol debugging is on
R4#clear ip route *
5d20h: RIP: sending v2 flash update to 224.0.0.9 via Ethernet0/0.46 (176.1.46.4)
5d20h: RIP: build flash update entries
5d20h:  0.0.0.0/0 via 0.0.0.0, metric 15, tag 0
5d20h:  150.1.0.0/16 via 0.0.0.0, metric 2, tag 0
5d20h:  176.1.0.0/16 via 0.0.0.0, metric 1, tag 0

Well take a look at that! Only the 0.0.0.0/0 route (default) has the offset-list applied. Makes sense. We had our access list only choose the default. But if you think about this, this must also mean that the offset-list is applied AFTER the summaries are generated. There is very little difference in the logic of either solutions, only this one works! We are setting a metric on both of the solutions, but the offset-list sets the metric AFTER the summaries.

So, IOS will generate the default route, summarize the routes, then apply the offset list. I haven’t been able to find documentation that supports this theory (the closest I could find was Tassos’s post but it mentions nothing on order), but it is the only explanation I could come up with.

Brian Dennis from Internetwork highlighted some of the other order of operations that IOS takes when performing certain tasks (QoS Order of Operations, IOS Egress and Ingress Order of Operations, BGP Order of Preference), but I can’t find any references for order with regards to this problem. Anybody else experience something similar, or know of any good order of operations references with regards to this?

Update: This seems to be a bug in the 12.2 IOS. I am able to reproduce this on the home lab, but it does not appear in the 12.4 series of IOS. Thanks to Jared Scrivener for pointing that out!

Read this article and more like it on ardenpackeer.com
Follow me on twitter: http://twitter.com/ardenpackeer

Mock Lab 6 Analysis – RIP Summary Address and Default Routes

Tutorial: IPv6 Tunnels Part 1 – Manual GRE & IPv6IP Tunnels

Arden Packeer, CCIE #20716 — Thu, 10 Apr 2008 08:27:39 +0000

Lets face it, sooner or later we are going to move to IPv6. Probably closer to the sooner side than some of us are comfortable with. In this series of articles we will be introducing tunnels and taking a look at how they can be used as part of you migration towards IPv6. Working with IPv6 tunnels is also an important part of a CCIE candidate’s journey, so mastering them is important. In this article we will be looking at tunneling IPv6 over IPv4 using manual tunnels, specifically GRE and IPv6 in IPv4.

We will be using the following topology for this tutorial:

Dynagen .net configuration:

ghostios = True
sparsemem = True
model = 3640

[localhost]

    [[3640]]
        image = \Program Files\Dynamips\images\c3640-ik9o3s-mz.124-7.bin
        # On Linux / Unix use forward slashes:
        # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
        ram = 96

    [[ROUTER R1]]
        f0/0 = LAN 1
        s1/0 = FRAME 1
        console = 2000
        model = 3640

    [[ROUTER R2]]
        f0/0 = LAN 2
        s1/0 = FRAME 2
        console = 2001
        model = 3640

    [[ROUTER R3]]
        f0/0 = LAN 3
        s1/0 = FRAME 3
        console = 2002
        model = 3640

    [[FRSW FRAME]]
        1:102 = 2:201
        1:103 = 3:301

You can download the dynagen/dynamips .net configuration file for this topology here.

Lets have a look at the basic configuration for this topology:

hostname R1
!
ipv6 unicast-routing
!
interface Loopback0
 ip address 10.10.10.10 255.255.255.255
!
interface FastEthernet0/0
 no ip address
 ipv6 address 2001:1:1:1::1/64
!
interface Serial1/0
 ip address 10.1.123.1 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-multipoint
 frame-relay map ip 10.1.123.2 102 broadcast
 frame-relay map ip 10.1.123.3 103 broadcast
 no frame-relay inverse-arp
!
router ospf 1
 router-id 10.10.10.10
 log-adjacency-changes
 network 0.0.0.0 255.255.255.255 area 0

hostname R2
!
ipv6 unicast-routing
!
interface Loopback0
 ip address 10.20.20.20 255.255.255.255
!
interface FastEthernet0/0
 no ip address
 ipv6 address 2001:2:2:2::2/64
!
interface Serial1/0
 ip address 10.1.123.2 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-multipoint
 frame-relay map ip 10.1.123.1 201 broadcast
 frame-relay map ip 10.1.123.3 201
 no frame-relay inverse-arp
!
router ospf 1
 router-id 10.20.20.20
 log-adjacency-changes
 network 0.0.0.0 255.255.255.255 area 0

hostname R3
!
ipv6 unicast-routing
!
interface Loopback0
 ip address 10.30.30.30 255.255.255.255
!
interface FastEthernet0/0
 no ip address
 ipv6 address 2001:3:3:3::3/64
!
interface Serial1/0
 ip address 10.1.123.3 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-multipoint
 frame-relay map ip 10.1.123.1 301 broadcast
 frame-relay map ip 10.1.123.2 301
 no frame-relay inverse-arp
!
router ospf 1
 router-id 10.30.30.30
 log-adjacency-changes
 network 0.0.0.0 255.255.255.255 area 0

You can see above that R1, R2 and R3 are connected via a hub and spoke frame-relay cloud. We will call the networks behind R1, R2, and R3 our “internal” networks. For the purposes of this article we will assume that in our organisation we have successfully migrated fully to IPv6 internally (you wish). IPv4 is used over our frame-relay cloud and this will simulate our WAN.

We are running OSPF over the frame cloud, and have advertised the routers loopback addresses into OSPF. We should have complete IPv4 connectivity between each of the routers the their corresponding loopbacks. Lets verify this:

R3#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
O       10.10.10.10/32 [110/65] via 10.1.123.1, 00:15:53, Serial1/0
C       10.30.30.0/24 is directly connected, Loopback0
O       10.20.20.20/32 [110/129] via 10.1.123.1, 00:15:53, Serial1/0
C       10.1.123.0/24 is directly connected, Serial1/0
O       10.1.123.1/32 [110/64] via 10.1.123.1, 00:15:53, Serial1/0
O       10.1.123.2/32 [110/128] via 10.1.123.1, 00:15:53, Serial1/0

You can see above the R3 has routes to each of the three routers looback addresses. We are using a point-to-multipoint tunnel so we can see that each of the spokes has a corresponding /32 route (for a tutorial on OSPF point-to-multipoint network types over frame see this tutorial).

R1#ping 10.30.30.30 source lo0 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.30.30.30, timeout is 2 seconds:
Packet sent with a source address of 10.10.10.10
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/100/160 ms

So it looks like we have full connectivity between the hubs and spokes over IPv4, but what about our IPv6 networks? The routers will have no connectivity between the IPv6 networks yet because the IPv6 stack does not know how to reach the other networks.

It would be really cool if we could tell the router, to get to the ipv6 network behind R1 use the IPv4 address of R1. Something like:

ipv6 route 2001:1:1:1::/64 10.10.10.10

But that won’t work! To route IPv6 traffic for a particular IPv6 network we need an IPv6 destination. (We actually can do something like the above, but we’ll leave 6to4 tunnels for our next article!).

We need someone way of providing connectivity between the disconnected IPv6 networks. Enter the tunnel!

Manual GRE Tunnels

The first thing that we are going to configure is manual GRE tunnels to carry the IPv6 traffic over IPv4. Tunnels (along with static routes, and policy based routing) are the duct tape of networking :). They can be used to solve just about any tricky routing problem.

The way tunnels solve this, is by encapulating and carrying the IPv6 traffic inside an IPv4 header (or GRE in this case). Traffic between the tunnel end points just see standard IPv4 traffic. The tunnel itself can have an IPv6 address, so we can route IPv6 traffic over it.

Lets have a look at the basic GRE tunnel configuration:

hostname R1
!
ipv6 unicast-routing
!
interface Tunnel12
 no ip address
 ipv6 address 2001:12:12:12::1/64
 tunnel source Loopback0
 tunnel destination 10.20.20.20
 tunnel mode gre
!
interface Tunnel13
 no ip address
 ipv6 address 2001:13:13:13::1/64
 tunnel source Loopback0
 tunnel destination 10.30.30.30
 tunnel mode gre
!
interface Loopback0
 ip address 10.10.10.10 255.255.255.255
!
interface FastEthernet0/0
 no ip address
 duplex auto
 speed auto
 ipv6 address 2001:1:1:1::1/64
!
interface Serial1/0
 ip address 10.1.123.1 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-multipoint
 frame-relay map ip 10.1.123.2 102 broadcast
 frame-relay map ip 10.1.123.3 103 broadcast
 no frame-relay inverse-arp
!
router ospf 1
 router-id 10.10.10.10
 log-adjacency-changes
 network 0.0.0.0 255.255.255.255 area 0
!
ipv6 route 2001:2:2:2::/64 2001:12:12:12::2
ipv6 route 2001:3:3:3::/64 2001:13:13:13::3
!

You can see R1’s setup above. We have created two tunnel interfaces. Interface tunnel12 goes from R1’s loopback to R2’s loopback over IPv4. Interface tunnel13 will go from R1’s loopback to R3’s loopback. We have already verified that the routers have IPv4 connectivity between the loopbacks, now we are connecting the them via a tunnel. We are using GRE to encapulate anything we send down the tunnels. Anything we send down tunnel12 will end up on R2 and look like its coming from R1’s loopback.

You can see the ipv6 static routes at the end of that configuration. Here we are saying, to get to the ipv6 network behind R2, use the IPv6 address 2001:12:12:12::2. This is the address we will assign to the other end of the tunnel12 interface. R1’s tunnel12 interface has the address of 2001:12:12:12::1 which is in the same subnet. R1 will have connectivity to the other end of the tunnel because it is in the same subnet and is technically a directly connected interface.

Let’s configure R2, and R3:

hostname R2
!
ipv6 unicast-routing
!
interface Tunnel12
 no ip address
 ipv6 address 2001:12:12:12::2/64
 tunnel source Loopback0
 tunnel destination 10.10.10.10
 tunnel mode gre
!
interface Tunnel23
 no ip address
 ipv6 address 2001:23:23:23::2/64
 tunnel source Loopback0
 tunnel destination 10.30.30.30
 tunnel mode gre
!
interface Loopback0
 ip address 10.20.20.20 255.255.255.255
!
interface FastEthernet0/0
 no ip address
 ipv6 address 2001:2:2:2::2/64
!
interface Serial1/0
 ip address 10.1.123.2 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-multipoint
 frame-relay map ip 10.1.123.1 201 broadcast
 frame-relay map ip 10.1.123.3 201
 no frame-relay inverse-arp
!
router ospf 1
 router-id 10.20.20.20
 log-adjacency-changes
 network 0.0.0.0 255.255.255.255 area 0
!
ipv6 route 2001:1:1:1::/64 2001:12:12:12::1
ipv6 route 2001:3:3:3::/64 2001:23:23:23::3
!

hostname R3
!
ipv6 unicast-routing
!
interface Tunnel13
 no ip address
 ipv6 address 2001:13:13:13::3/64
 tunnel source Loopback0
 tunnel destination 10.10.10.10
 tunnel mode gre
!
interface Tunnel23
 no ip address
 ipv6 address 2001:23:23:23::3/64
 tunnel source Loopback0
 tunnel destination 10.20.20.20
 tunnel mode gre
!
interface Loopback0
 ip address 10.30.30.30 255.255.255.255
!
interface FastEthernet0/0
 no ip address
 duplex auto
 speed auto
 ipv6 address 2001:3:3:3::3/64
!
interface Serial1/0
 ip address 10.1.123.3 255.255.255.0
 encapsulation frame-relay
 ip ospf network point-to-multipoint
 frame-relay map ip 10.1.123.1 301 broadcast
 frame-relay map ip 10.1.123.2 301
 no frame-relay inverse-arp
!
router ospf 1
 router-id 10.30.30.30
 log-adjacency-changes
 network 0.0.0.0 255.255.255.255 area 0
!
ipv6 route 2001:1:1:1::/64 2001:13:13:13::1
ipv6 route 2001:2:2:2::/64 2001:23:23:23::2
!

You can see we have set up a full mesh of tunnels between the routers. We should now have complete connectivity between the IPv6 networks.

Lets test this. To test it, we will use ipv4 packet debugging:

R1#debug ip packet detail
IP packet debugging is on (detailed)
R1#ping 2001:3:3:3::3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:3:3:3::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/100/160 ms
R1#
IP: s=10.10.10.10 (Tunnel13), d=10.30.30.30 (Serial1/0), len 124, sending, proto=47
IP: s=10.10.10.10 (Tunnel13), d=10.30.30.30 (Serial1/0), len 124, sending, proto=47
IP: s=10.10.10.10 (Tunnel13), d=10.30.30.30 (Serial1/0), len 124, sending, proto=47
IP: s=10.10.10.10 (Tunnel13), d=10.30.30.30 (Serial1/0), len 124, sending, proto=47
IP: s=10.10.10.10 (Tunnel13), d=10.30.30.30 (Serial1/0), len 124, sending, proto=47

You can see above that when we send a ping to the IPv6 network behind R3, we are actually sending IPv4 packets over the frame-relay cloud. The packets have a source of 10.10.10.10 (R1’s loopback0) and a destination of 10.30.30.30 (R3’s loopback0). The IPv6 packets have been encapsulated in a GRE header (protocol type 47).

When the packets arrive at R3, they will be unencapsulated and passed to R3’s IPv6 stack, which will respond back to the ping. The return packets will once again be encapulated over GRE and sent to R1.

IPv6 Over IPv4

Now the problem with the scenario above, is that it introduces a lot of overhead. We are taking an IPv6 packet, wrapping a GRE header around it, then wrapping a IPv4 header around that! That’s one fat packet.

Surely there must be a better way to do this and reduce the overhead? Well there is.

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#int tu13
R3(config-if)#tunnel mode ?
  aurp    AURP TunnelTalk AppleTalk encapsulation
  cayman  Cayman TunnelTalk AppleTalk encapsulation
  dvmrp   DVMRP multicast tunnel
  eon     EON compatible CLNS tunnel
  gre     generic route encapsulation protocol
  ipip    IP over IP encapsulation
  ipsec   IPSec tunnel encapsulation
  iptalk  Apple IPTalk encapsulation
  ipv6    Generic packet tunneling in IPv6
  ipv6ip  IPv6 over IP encapsulation
  nos     IP over IP encapsulation (KA9Q/NOS compatible)
  rbscp   RBSCP in IP tunnel

R3(config-if)#tunnel mode ipv6ip

There are a few different types of tunnels, and the one we are interested in here is the ipv6ip tunnel. With this we are going to encapsulate IPv6 inside IP, without the GRE overhead.

interface Tunnel12
 no ip address
 ipv6 address 2001:12:12:12::1/64
 tunnel source Loopback0
 tunnel destination 10.20.20.20
 tunnel mode ipv6ip
!
interface Tunnel13
 no ip address
 ipv6 address 2001:13:13:13::1/64
 tunnel source Loopback0
 tunnel destination 10.30.30.30
 tunnel mode ipv6ip
!

interface Tunnel12
 no ip address
 ipv6 address 2001:12:12:12::2/64
 tunnel source Loopback0
 tunnel destination 10.10.10.10
 tunnel mode ipv6ip
!
interface Tunnel23
 no ip address
 ipv6 address 2001:23:23:23::2/64
 tunnel source Loopback0
 tunnel destination 10.30.30.30
 tunnel mode ipv6ip

interface Tunnel13
 no ip address
 ipv6 address 2001:13:13:13::3/64
 tunnel source Loopback0
 tunnel destination 10.10.10.10
 tunnel mode ipv6ip
!
interface Tunnel23
 no ip address
 ipv6 address 2001:23:23:23::3/64
 tunnel source Loopback0
 tunnel destination 10.20.20.20
 tunnel mode ipv6ip

You can see the configuration is simple. Just swap the tunnel mode on all the tunnel interfaces. IPv6IP tunnels use an IPv4 header with protocol type 41. The signifies that we are carrying IPv6. Let’s check it:

R1#debug ip packet detail
IP packet debugging is on (detailed)
R1#ping 2001:3:3:3::3    

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:3:3:3::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 108/159/256 ms
R1#
IP: s=10.10.10.10 (Tunnel13), d=10.30.30.30 (Serial1/0), len 120, sending, proto=41
IP: tableid=0, s=10.30.30.30 (Serial1/0), d=10.10.10.10 (Loopback0), routed via RIB
IP: s=10.30.30.30 (Serial1/0), d=10.10.10.10, len 120, rcvd 4, proto=41
IP: s=10.10.10.10 (Tunnel13), d=10.30.30.30 (Serial1/0), len 120, sending, proto=41
IP: tableid=0, s=10.30.30.30 (Serial1/0), d=10.10.10.10 (Loopback0), routed via RIB
IP: s=10.30.30.30 (Serial1/0), d=10.10.10.10, len 120, rcvd 4, proto=41
IP: s=10.10.10.10 (Tunnel13), d=10.30.30.30 (Serial1/0), len 120, sending, proto=41
R1#
IP: tableid=0, s=10.30.30.30 (Serial1/0), d=10.10.10.10 (Loopback0), routed via RIB
IP: s=10.30.30.30 (Serial1/0), d=10.10.10.10, len 120, rcvd 4, proto=41
IP: s=10.10.10.10 (Tunnel13), d=10.30.30.30 (Serial1/0), len 120, sending, proto=41
IP: tableid=0, s=10.30.30.30 (Serial1/0), d=10.10.10.10 (Loopback0), routed via RIB
IP: s=10.30.30.30 (Serial1/0), d=10.10.10.10, len 120, rcvd 4, proto=41
IP: s=10.10.10.10 (Tunnel13), d=10.30.30.30 (Serial1/0), len 120, sending, proto=41
IP: tableid=0, s=10.30.30.30 (Serial1/0), d=10.10.10.10 (Loopback0), routed via RIB
IP: s=10.30.30.30 (Serial1/0), d=10.10.10.10, len 120, rcvd 4, proto=41

You can see above that we have complete connectivity between the Router’s IPv6 networks. You can also see above that we are using protocol type 41 (IPv6IP). Cool huh?

In our next article in this series we will be using a special type of IPv6IP tunnel to do automatic 6to4 tunnels. HTH. Now back to labs!

Summary:

We can tunnel IPv6 over IPv4 to give us connectivity between IPv6 networks seperated by and IPv4 network.
We can tunnel using GRE (packet type 47), however that introduces significant overhead.
Tunnelling using IPv6IP tunnels (packet type 41) give us the same functionality of GRE, but with significantly less overhead.

Resources:

Dynamips/Dynagen .net configuration file

Read this article and more like it on ardenpackeer.com
Follow me on twitter: http://twitter.com/ardenpackeer

Tutorial: IPv6 Tunnels Part 1 – Manual GRE & IPv6IP Tunnels

Tutorial: OSPF Network Types and Frame Relay Part 4

Arden Packeer, CCIE #20716 — Fri, 29 Feb 2008 00:08:32 +0000

In our previous tutorials (you can find Part 1 here, Part 2 here and Part 3 here) we looked at the different OSPF network types and how they apply to a partial mesh Frame-Relay Hub and spoke topology. In normal situations that would be enough, but this is the CCIE we are preparing for! We have to understand how the different network types work together. This is incase the proctor decides to not allow you to use certain types of OSPF networks on one interface or does not allow you to use the ip ospf network commands on others. Evil Proctors :)

Once again we will be using the following topology:

We will be using the following dynagen .net file:

ghostios = True
sparsemem = True
model = 3640
reply
[localhost]

    [[3640]]
        image = \Program Files\Dynamips\images\c3640-jk9o3s-mz.124-12.bin
        # On Linux / Unix use forward slashes:
        # image = /opt/7200-images/c7200-jk9o3s-mz.124-7a.image
        ram = 96

    [[ROUTER R1]]
        f0/0 = LAN 1
        s1/0 = FRAME 1
        console = 2000
        model = 3640

    [[ROUTER R2]]
        f0/0 = LAN 2
        s1/0 = FRAME 2
        console = 2001
        model = 3640

    [[FRSW FRAME]]
        1:102 = 2:201

You can download this dynagen .net configuration file for this tutorial here.

Lets have a look at the initial configuration:

hostname R1
!
interface FastEthernet0/0
 ip address 1.1.1.1 255.255.255.0
!
interface Serial1/0
 ip address 192.168.1.1 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 192.168.1.2 102 broadcast
 no frame-relay inverse-arp
!
router ospf 1
 router-id 1.1.1.1
 log-adjacency-changes
 network 0.0.0.0 255.255.255.255 area 0

hostname R2
!
interface FastEthernet0/0
 ip address 2.2.2.2 255.255.255.0
!
interface Serial1/0
 ip address 192.168.1.2 255.255.255.0
 encapsulation frame-relay
 frame-relay map ip 192.168.1.1 201 broadcast
 no frame-relay inverse-arp
!
router ospf 1
 router-id 2.2.2.2
 log-adjacency-changes
 network 0.0.0.0 255.255.255.255 area 0

You can see with the configuration above we have set up both of the routers to be in area 0. We haven’t changed the default network types so the s1/0 on both routers should be set to ospf non-broadcast network types. Lets check this:

R1#sh ip ospf int s1/0
Serial1/0 is up, line protocol is up
  Internet Address 192.168.1.1/24, Area 0
  Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 64
  Transmit Delay is 1 sec, State WAITING, Priority 1
  No designated router on this network
  No backup designated router on this network
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
    oob-resync timeout 120
    Hello due in 00:00:07
    Wait time before Designated router selection 00:01:37
  Supports Link-local Signaling (LLS)
  Index 2/2, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 1, Adjacent neighbor count is 0
  Suppress hello for 0 neighbor(s)

This is the same on R2. What about the routing table? Well we haven’t had any neighbors come up, and this is because the network type is non-broadcast. With a non-broadcast network type we need to specify neighbors using the neighbor command under the ospf configuration.

Instead of setting up neighbors, lets play around with this. What would happen if we set one side to Broadcast networreplyk type and the other we left as non-broadcast? Lets see:

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int s1/0
R2(config-if)#ip ospf network broadcast

If we take a look at our neighbors we will notice that we haven’t formed an adjacency between the routers.

R1#sh ip ospf nei

R1#

What is the problem here? Well at first glance your probably thinking “well the network types don’t match Arden!”. That’s true, but matching network types is not one of the pre-requisites for forming an adjacency. What are the pre-requisites for forming an adjacency between two ospf neighbors?

Pre-Requisites for OSPF adjacencies:

Same Authentication type & Password
Stub Area flag
Same Area
Same Network Mask
Same Hello & Dead Timers

Looking at that list we have the same authentication type (we’re not using any!), same stub area flag (ie none!), same area (Area 0), and same mask. But what about the Hello & Dead timers? Lets compare the two routers:

R1#sh ip ospf int s1/0
Serial1/0 is up, line protocol is up
  Internet Address 192.168.1.1/24, Area 0
  Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 64
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 1.1.1.1, Interface address 192.168.1.1
  No backup designated router on this network
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
    oob-resync timeout 120
    Hello due in 00:00:15
  Supports Link-local Signaling (LLS)
  Index 2/2, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 0, maximum is 1
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 0, Adjacent neighbor count is 0
  Suppress hello for 0 neighbor(s)

R2#sh ip ospf int s1/0
Serial1/0 is up, line protocol is up
  Internet Address 192.168.1.2/24, Area 0
  Process ID 1, Router ID 2.2.2.2, Network Type BROADCAST, Cost: 64
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 2.2.2.2, Interface address 192.168.1.2
  No backup designated router on this network
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:00
  Supports Link-local Signaling (LLS)
  Index 2/2, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 0, maximum is 1
  Last flood scan time is 0 msec, maximum is 4 msec
  Neighbor Count is 0, Adjacent neighbor count is 0
  Suppress hello for 0 neighbor(s)

Looking at the output from the show ip ospf interface command you can clearly see that the Hello and Dead timers don’t match up. A broadcast network type has timers of 10 and 40 seconds for hello and dead timers respectively. A non-broadcast network type has timers of 30 and 120 seconds for hello and dead timers respectively.

Lets change the timers on R1 and see if this helps:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int s1/0
R1(config-if)#ip ospf hello-interval 10

R1#sh ip ospf int s1/0
Serial1/0 is up, line protocol is up
  Internet Address 192.168.1.1/24, Area 0
  Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 64
  Transmit Delay is 1 sec, State WAITING, Priority 1
  No designated router on this network
  No backup designated router on this network
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:04
    Wait time before Designated router selection 00:01:45
  Supports Link-local Signaling (LLS)
  Index 2/2, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 16 msec
  Neighbor Count is 0, Adjacent neighbor count is 0
  Suppress hello for 0 neighbor(s)

We used the ip ospf hello-interval command to change the hello timers. You can see above that we didn’t have to change the dead interval. By default the dead interval is set at 4x the hello interval. These timers now match R1 so we should see a neighbor adjacency form.

R1#
*Mar  1 05:42:18.118: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial1/0 from LOADING to FULL, Loading Done
R1#

R1#sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   FULL/DR         00:00:31    192.168.1.2     Serial1/0
R1#

Looks good. You can see there that R2 has become the DR for the frame relay segment. Remember that both Broadcast network types and Non-Broadcast network types require a DR.

R1’s s1/0 is an ospf non-broadcast network type. In this network type hello messages are sent unicast to neighbors. We don’t have neighbours defined here so we will never initiate sending hello messages. R1 will still reply to hello’s however. This is how an adjacency is formed. R2’s s1/0 is an ospf broadcast network type. We will multicast a hello to 224.0.0.5 on that segment. R1 is receives those hello’s and unicasts a reply back. Lets verify this:

R2#debug ip ospf hello
OSPF hello events debugging is on
R2#
OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 2.2.2.2
OSPF: Send hello to 224.0.0.5 area 0 on Serial1/0 from 192.168.1.2
R2#

R1#debug ip ospf hello
R1#
OSPF: Rcv hello from 2.2.2.2 area 0 from Serial1/0 192.168.1.2
OSPF: End of hello processing
R1#
OSPF: Send hello to 192.168.1.2 area 0 on Serial1/0 from 192.168.1.1
R1#

A neighbor relationship forms now because all the pre-requisites that we mentioned before are met. R2 is elected the DR for this segment and all updates from R1 are sent to R2 via unicast to 192.168.1.2. Updates from R2 are sent to R1 via 224.0.0.5. R1 still listens on this address even though it does not send out lsa updates on this address.

The key thing here is that both the ospf broadcast and non-broadcast network types use DR to handle propogation of updates through ospf. Because of this they are able to share routes. Looking at the routing tables of both you can see we have full connectivity:

R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     1.0.0.0/24 is subnetted, 1 subnets
O       1.1.1.0 [110/65] via 192.168.1.1, 00:00:23, Serial1/0
     2.0.0.0/24 is subnetted, 1 subnets
C       2.2.2.0 is directly connected, FastEthernet0/0
C    192.168.1.0/24 is directly connected, Serial1/0

Looks good, but what would happen if we change R1 to a network type that didn’t support a DR. Let’s try it and see :)

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int s1/0
R1(config-if)#ip ospf network point-to-multipoint
R1#
%OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial1/0 from FULL to DOWN, Neighbor Down: Interface down or detached
%SYS-5-CONFIG_I: Configured from console by console
R1#
 %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on Serial1/0 from LOADING to FULL, Loading Done

Looks like the adjacency worked! Why:

R1#sh ip ospf int s1/0
Serial1/0 is up, line protocol is up
  Internet Address 192.168.1.1/24, Area 0
  Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_MULTIPOINT, Cost: 64
  Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:05
  Supports Link-local Signaling (LLS)
  Index 2/2, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 16 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 2.2.2.2
  Suppress hello for 0 neighbor(s)

The point-to-multipoint network type has timers that match the broadcast network type set on R2. The adjacency pre-requisites are met so an adjacency is formed.

R1#sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/  -        00:00:36    192.168.1.2     Serial1/0

R2#sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
1.1.1.1           1   FULL/BDR        00:00:39    192.168.1.1     Serial1/0

Looking at the show ip ospf neighbor output of both neighbors we see a problem. R1 sees R2 as a neighbour but does not think a DR relationship is necessary on the Frame Segment. R2 thinks a DR is necessary on the frame segment. Herein lies the problem:

R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     2.0.0.0/24 is subnetted, 1 subnets
C       2.2.2.0 is directly connected, FastEthernet0/0
C    192.168.1.0/24 is directly connected, Serial1/0

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     1.0.0.0/24 is subnetted, 1 subnets
C       1.1.1.0 is directly connected, FastEthernet0/0
C    192.168.1.0/24 is directly connected, Serial1/0

R1 and R2 are not swapping routes!

Lets have a think about why this is. Even though all the pre-requisites for neighbor adjacencies have been met, R1 will be unicasting updates to R2 and R2 will be sending updates to the multicast address 224.0.0.6 (all DR and BDR’s). The link-state databases will not be kept synchronized properly.

The moral of the story: We can mix and match network types as long as the DR relationship is taken into account. This means we can mix and match the following network types:

Dont Need a DR:
Point-to-Point and Point-to-Multipoint (if you adjust timers)
Point-to-Point and Point-to-Multipoint non-broadcast (if you adjust timers)
Point-to-Multipoint and Point-to-Multipoint non-broadcast

Need a DR:
Broadcast and Non-Broadcast (if you adjust timers)

In our next article in the OSPF Network Types and Frame-Relay series we will be putting all of these together and taking a look at how the OSPF network types work in conjunction with a large partial mesh network. Now back to labs! HTH!

Summary:

An adjacency will be formed with routers running OSPF, as long as the authentication is the same, the stub flag is the same, the area is the same, and the timers are the same.
If we mix and match network types we might need to modify the timers so we can form an adjacency. This is done with the ip ospf hello-interval and ip ospf dead-interval commands.
You can mix and match network types as long as the network types involved have the same DR relationship. You can’t mix network types that require a DR with those that don’t require a DR.

Resources:

Dynamips/Dynagen .net configuration file

Read this article and more like it on ardenpackeer.com
Follow me on twitter: http://twitter.com/ardenpackeer

Tutorial: OSPF Network Types and Frame Relay Part 4