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:

R1

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

R2

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

R3

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

R4

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

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

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

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

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

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

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

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

Some of you out there are probably thinking, why bother? Why bother creating a blog about your CCIE pursuit? Creating this blog is by far one of the best things I did in pursuing the CCIE!

One of the things that gets in the way of getting your CCIE is your own ego. It’s important not to fall into that trap. You will have weaknesses. You need to acknowledge them. Don’t be afraid of them. Turn them into your strength. I made it a point, for every weakness that I had I would write a tutorial on it in my blog. This forced me to learn that topic inside and out, and in the process hopefully help someone else out. Blogging has shown me how valuable this technique is, and I definitely recommend it. It has opened doors that I never even knew existed.

I think its great that IPexpert have decided to embrace the community this way. If you are pursuing your CCIE, I highly encourage you to start a blog! Share your trials and tribulations in your pursuit. Write down every little thing you learn. Not just for yourself, but for the community. Know that you are not alone. You’ll be amazed at how much it pays you back!

Resources:

• CCIE>Blog

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

Study Tip: CCIE>Blog – Blogging as a study tool!

NetworkWorld claimed third-party boot camps designed to prepare candidates for the exam are not always up to par. Fred Weiler, Cisco marketing director claimed “There was a very diverse level of quality” in the third-party exam preparation programs. He also goes on to say that “The third-party courses often trained Cisco pros well enough to pass the exam, but not well enough to become true experts”. “It’s not to train to the test. It’s training to become an expert,” Weiller said.

Like CCIEPursuit, I call bullshit. You cannot pass that exam unless you are an expert. I went through that whole process using third party training vendor material. So did a lot of existing CCIE’s. It has not only made me a better instructor, but a better engineer. Saying that the existing vendors only train you enough to pass the exam is marketing FUD.

Cisco delivers its official course material through its Learning Partner program. Cisco structures its Learning Partner program into three tiers. At the top we have CLSP’s (Cisco Learning Solution Partners). The middle tier is where the CLP’s (Cisco Learning Partners) sit, and the bottom is where SO’s (Sponsored Organisations) sit.

A CLSP is allowed to deliver only Cisco authorized materials using Certified Cisco System Instructors (CCSI). Having a certain number of certified staff members is a requirement. CLSP’s are allowed to customize courses but are required to report and pay royalties on all derivative works to Cisco.

There are only a handfull of CLSP’s in the world and each has a specific region (or theatre) they look after. Its like a giant pyramid scheme with CLSP’s sitting at the top. CLP’s and SO’s must purchase kits (training manuals etc) from CLSP’s and get any derivative works approved. Cisco gets a cut from these derivative works.

What does all this have to do with the Cisco 360 CCIE Learning Program? I suspect that only the high end CLSP’s will be allowed to deliver this training. The problem for Cisco at the moment is that there are these great CCIE training companies out there who provide training and create CCIE’s, but Cisco doesn’t get a cut from any of that.

Why didn’t Cisco partner with one of the top CCIE vendors? In short, I think its because of derivative works. If a CCIE vendor aligned themselves with a CLSP as a SO or CLP, the CCIE vendor would be able to accept Cisco learning credits. Cisco partners get Cisco Learning credits that they can redeem with a Cisco Learning Partner. If a CCIE vendor aligned themselves with a CLSP as a SO or CLP, I suspect Cisco would then demand a cut from the CCIE material. Cisco would want it to be considered a derivative work. But they didn’t have a CCIE training program for it to be “derived” from. They do now.

I think that IPexpert and Internetwork Expert at one stage accepted Cisco Learning Credits but I can’t find anything on their webpages on whether they still accept them. I’m thinking out loud here, but put yourselves in the shoes of IPexpert and Internetwork Expert etc. You align yourselves with a CLSP so you can take Cisco learning credits and then you have to pay Cisco royalty fees on something you created all on your own as a “derivative work”. I know I would hate that.

It will be interesting the see how this effects the CCIE vendors now. I think CCIEPursuit is correct in that you will have more candidates taking the Cisco courses because it has the Cisco logo attached.

Does that mean, that the existing CCIE vendors training material is suddenly substandard? Hell no! I have used both IPexpert, and Internetwork Expert’s training material for CCIE preparation. I have seen Narbiks training material. I honestly believe that you could use any of the CCIE training material from any of the top CCIE vendors and pass the exam. So in terms of the actual material, I think they become a commodity

What really matters? The Instructor.

At the moment, what I believe distinguishes the third-party vendors (or the so called grey training market) with the official Cisco courseware, is the person delivering the material. The instructor. The official courseware for CCNA, CCNP etc is great (I know, I deliver it every day as a CCSI working for a CLP). I have used both IPexpert, and Internetwork Expert’s training material for CCIE preparation. I have seen Narbiks training material. I honestly believe that you could use any of the CCIE training material from any of the top CCIE vendors and pass the exam. What differentiates them is the Instructors.

I always say people remember two things about a training course they attend: The Instructor and the food :). Im sure all of us at one time or another has been to one of those training courses. You know the ones. The instructor gets up and starts reading the slides word for word. Death by powerpoint. You ask him/her any questions and they retort with “I’ll get back to you”.

The mediocre teacher tells. The good teacher explains. The superior teacher demonstrates. The great teacher inspires.

I want to know: who will be teaching these Cisco 360 CCIE training courses? What instructors? Are they as good as Jared, Scott, Narbik, and the Brians? Are they as inspirational as these guys? If all the CLSP’s are getting the same material then what makes you choose one over the other? I’m sure the material will be great. What I care about is who will be guiding me through this material?

Unless Ivan (who works for NIL, one of the largest CLSP) or someone of his calibre at a CLSP teaches it, I think I’ll stick to the third party vendors for my CCIE material.

Resources:

• Check out the Cisco Learning Partner FAQ here
• CCIEPursuit’s comments on the new Cisco’s CCIE 360 Program here, and here.

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

Blog: Cisco Announces New CCIE Learning Program…Why didn’t they Partner?

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:

• Dynamips/Dynagen .net configuration file
• Jeff Doyle’s Favourite Interview Question – “Why does OSPF require all traffic between non-backbone areas to pass through a backbone area (area 0)?”

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

• Part 1: OSPF Broadcast & Non-Broadcast Network Types
• Part 2: OSPF Point-to-Multipoint & Point-to-Multipoint Non-Broadcast Network Types
• Part 3: OSPF Point-to-Point & Loopback Network Types
• Part 4: Mixing & Matching OSPF Network Types
• Part 5: OSPF Network Types in Multi-Hub Partial-Mesh Networks

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

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:

R1

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

R2

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

R3

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

R4

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:

R4

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

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

News: Antonie Henning Passed!

Summer 2008 Salary Survey

July 2008

Email: eman@bridgeresourcing.com
Web: www.bridgeresourcing.com
Blog: www.ccieagent.com

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

CCIE Salary Survey

Narbik’s popular “Advanced CCIE R&S – Technology Focused” workbook can also now be bundled with IPexpert’s CCIE R&S Blended Learning Solution. His workbooks will also be made compatible with Proctor Labs, matching the IPexpert topology. This will make it easier to get rack time for those working through his labs.

I’m a big believer in using multiple workbooks for CCIE preparation. You get different perspectives, as well as getting used to the different writing styles of questions. It also makes sure you don’t get comfortable with one vendor’s labs, layout etc. I’ve heard great things about Narbik’s workbooks both on groupstudy and everyone I’ve met that’s used them keeps raving about them.

The other big news is that the Blended Learning Solutions are now free! Anybody that books a bootcamp now gets the Blended Learning Solution for free! FREE?! I’m working through the Voice Blended Learning Solution (BLS) at the moment and the workbooks are fantastic. If its sounds like I am an IPexpert fanboy, its because I am. The level of detail in the explanations in the Voice BLS are great, and I can’t believe they would give it away for free! I am planning on attending the voice bootcamp when I am further along in the study, and I am glad you can apply the entire purchase price of your BLS toward a Boot Camp registration.

Looks like IPexpert are really trying to shake-up the CCIE training sphere. I wonder if some of the other vendors will now match IPexpert’s offer and follow suit?

Update: If you haven’t joined twitter, now is the time! I just got a tweet from IPexpert:

“Stay focused on your “tweets” this month… we will be giving out 2,000 HOURS worth of Proctor Labs rack time… only to Twitter followers!”

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

News: Narbik Kocharians joins forces with IPexpert and Free Stuff!

To be honest, I’m really disappointed.

I wish they didn’t get rid of the old ones (Greg I’m soooo jealous!). After all that hard work, this thing looks like its made out of plastic. What am I saying, it IS made out of plastic! Plastic with a bit of glass stuck on the front. Bring back the old medallions. That is something you can show with pride!

According to Tassos, the company that made the old ones, Brandvia, is still around. I’ll be sending them an email to see if can get one of those old school medallions….

Seriously, Cisco, the new CCIE Plaques suck!

We pay $1400 a pop for the Exam (not to mention countless hours of blood sweat and tears), surely Cisco can make the prize at the end a little better than this!

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

Blog: Cisco, the new CCIE Plaques suck!