Take, for example, the following

 ! default route
 ip route 0.0.0.0 0.0.0.0 1.1.1.1
 ! pick your routing protocol
 router XXXXX
    redistribute static

Under what conditions will the default route make it into the routing protocol? The docs seem to indicate that the process is automatic in EIGRP, but requires intervention in IS-IS, OSPF, and BGP. Let's validate.

Take a simple network:

1.1.1.0/24 [R1] 2.2.2.0/24 [R2] 3.3.3.0/24 [R3]

(dynagen .net)

On R1, I have

router eigrp 1
 redistribute static
 network 1.0.0.0
 network 2.0.0.0
 no auto-summary
!
ip route 0.0.0.0 0.0.0.0 1.1.1.99

and over on R3

D*EX 0.0.0.0/0 [170/33280] via 3.3.3.1, 00:01:00, FastEthernet0/0

One thing to note is that the network statement specified 1.1.1.0 and 2.2.2.0, and not 0.0.0.0. This is because the network statement in the EIGRP config is used to match the interfaces that EIGRP will run on, which is where the network information comes from. network 0.0.0.0 would match both interfaces, but still would not add the default route. The redistribute static is what causes the route to get into EIGRP (which is why it shows up in R3's routing table as D*EX)

In OSPF, we have on R1

router ospf 1
 log-adjacency-changes
 redistribute static subnets
 network 0.0.0.0 255.255.255.255 area 0

This time I used network 0.0.0.0 to save some typing. However R3 does not see the default route. It does see another static route I put in to 9.9.9.0/24, so we know redistribution works properly.

The solution here is the default-information originate command. Adding "default-information originate" to the OSPF config solves this:

O*E2 0.0.0.0/0 [110/1] via 3.3.3.1, 00:00:02, FastEthernet0/0

For BGP, R1 is set up as follows:

R1#show run | section router bgp
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 network 1.1.1.0
 network 2.2.2.0
 neighbor 2.2.2.2 remote-as 2
 no auto-summary

If I redistribute static, the default route does not show up on R2:

R2#show ip route bgp
     9.0.0.0/24 is subnetted, 1 subnets
B       9.9.9.0 [20/0] via 2.2.2.1, 00:00:31

At least two options exist. 1 is to do the "default-information originate" which allows the static route to be redistributed into BGP. The other is to not redistribute, but use the network 0.0.0.0 command to advertise the default route. In BGP, the network statement specifies the routes to be advertised, and not the interfaces like OSPF and EIGRP.

The difference between the two options, though, is in the BGP attributes.

! redistribute static and default-information originate
R2#show ip bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 8
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  1
    2.2.2.1 from 2.2.2.1 (2.2.2.1)
      Origin incomplete, metric 0, localpref 100, valid, external, best
! network 0.0.0.0
R2# show ip bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 12
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Not advertised to any peer
  1
    2.2.2.1 from 2.2.2.1 (2.2.2.1)
     Origin IGP, metric 0, localpref 100, valid, external, best

The difference here is that advertising a local network marks the origin as IGP, but a redistribution marks it as incomplete. Look at step 5 of the BGP best path selection algorithm to see that IGP is preferred over incomplete (even though by the time origin is compared, weight, local preference, and AS_PATH length have already been compared)

So, the moral of the story is to watch how your default routes go into your routing protocol, because depending on the protocol, it's handled differently.

Content Copyright Sean Walberg

Default routes

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

“go active” means that the EIGRP router asks all its neighbours if they have a route to the destination. Each router that is queried either responds in the affirmative, or it in turn asks its neighbours if any exist. Only after a router hears back from all its neighbours does it pass a “I don’t have this route” message back up the chain. This is the Diffusing Update Algorithm, or DUAL.

When DUAL takes too long to resolve a query, such as if the network gets busy, you get the stuck-in-active error, which means the query took more than 3 minutes to complete.

The solution (besides “get a smaller network”) to SIA is to limit the scope of your queries. There are two methods to do this. The first is summarization. When an EIGRP router summarizes a network out an interface, any queries for a summarized network coming in that interface are answered and not passed along. The second way is to declare routers as stub routers, which means that you don’t want them to act as a transit anyway.

I’ve written about EIGRP stub routers before, but after taking the BSCI exam I realized my knowledge on that topic wasn’t enough.

The lab today is a simple triangle. R1/R2 are part of the main network, there are redundant connections to the branch network R3. If the R1/R2 link should fail we don’t want traffic to transit the WAN (imagine there is a larger network hanging off of R1/R2). R3 is therefore a stub.

Corresponding dynagen code:

autostart = false 

[localhost]

[[7200]]
image = ..\images\c7200-p-mz.124-12.unzipped
npe = npe-400
ram = 192

[[ROUTER R1]]
f0/0 = R2 f0/0

[[ROUTER R2]]

[[ROUTER R3]]
s1/0 = R1 s1/0
s1/1 = R2 s1/1
f0/0 = LAN 1

Each network is a /24 and all routers have been set up with EIGRP. R3 has various routes on it that I'll use to test.

interface Loopback0
 ip address 9.9.9.1 255.255.255.0
!
interface FastEthernet0/0
 ip address 3.3.3.3 255.255.255.0
 duplex half
router eigrp 1
 redistribute connected
 redistribute static
 network 3.3.3.3 0.0.0.0
 network 10.0.1.2 0.0.0.0
 network 10.0.2.2 0.0.0.0
 no auto-summary
!
ip route 2.2.2.0 255.255.255.0 9.9.9.2

The eigrp stub command turns a router into a stub. The router informs its peers that it is a stub, which cause them to scope the queries appropriately. There are several options to the stub command though:

R3(config-router)#eigrp stub ?
  connected      Do advertise connected routes
  leak-map       Allow dynamic prefixes based on the leak-map
  receive-only   Set IP-EIGRP as receive only neighbor
  redistributed  Do advertise redistributed routes
  static         Do advertise static routes
  summary        Do advertise summary routes
  

Before stubs, R2 sees:

R2#show ip route eigrp
     2.0.0.0/24 is subnetted, 1 subnets
D EX    2.2.2.0 [170/2297856] via 10.0.2.2, 00:09:33, Serial1/1
     3.0.0.0/24 is subnetted, 1 subnets
D       3.3.3.0 [90/2172416] via 10.0.2.2, 00:01:13, Serial1/1
     9.0.0.0/24 is subnetted, 1 subnets
D EX    9.9.9.0 [170/2297856] via 10.0.2.2, 00:09:36, Serial1/1
     10.0.0.0/24 is subnetted, 3 subnets
D       10.0.1.0 [90/2172416] via 10.0.0.1, 00:53:53, FastEthernet0/0

After configuring as a stub:

R2#show ip eigrp neighbors detail s1/1
IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   10.0.2.2                Se1/1             14 00:00:41  127   762  0  45
   Version 12.4/1.2, Retrans: 1, Retries: 0, Prefixes: 3
   Stub Peer Advertising ( CONNECTED SUMMARY ) Routes
   Suppressing queries
R2#show ip route eigrp
     3.0.0.0/24 is subnetted, 1 subnets
D       3.3.3.0 [90/2172416] via 10.0.2.2, 00:01:03, Serial1/1
     9.0.0.0/24 is subnetted, 1 subnets
D EX    9.9.9.0 [170/2297856] via 10.0.2.2, 00:01:03, Serial1/1
     10.0.0.0/24 is subnetted, 3 subnets
D       10.0.1.0 [90/2172416] via 10.0.0.1, 00:01:05, FastEthernet0/0

So by default the peer advertises connected and summary routes. Indeed, the redistributed static route was dropped, but the redistributed connected route wasn't. The other, directly advertised, connected route to F0/0 was also distributed.

Trying "eigrp stub static", I see

R2#show ip eigrp neighbors detail s1/1
IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   10.0.2.2                Se1/1             13 00:00:15  116   696  0  58
   Version 12.4/1.2, Retrans: 1, Retries: 0, Prefixes: 1
   Stub Peer Advertising ( STATIC ) Routes
   Suppressing queries
R2#show ip route eigrp
     2.0.0.0/24 is subnetted, 1 subnets
D EX    2.2.2.0 [170/2297856] via 10.0.2.2, 00:00:19, Serial1/1
     10.0.0.0/24 is subnetted, 3 subnets
D       10.0.1.0 [90/2172416] via 10.0.0.1, 00:04:43, FastEthernet0/0

This has removed the connected and redistributed connected routes, leaving only the redistributed static.

Curiously, trying "eigrp stub redistributed" ends up showing as "eigrp stub connected summary redistributed". The best I could do was "eigrp stub redistributed connected", I could not get redistributed by itself. The documentation seems to be quiet on the issue.

The final option is receive-only which causes the stub router to advertise no routes, but still receives routing updates:

R2#show ip eigrp neighbors detail s1/1
IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
1   10.0.2.2                Se1/1             11 00:00:13   76   684  0  85
   Version 12.4/1.2, Retrans: 1, Retries: 0
   Receive-Only Peer Advertising ( No ) Routes
   Suppressing queries
R2#show ip route eigr
R2#show ip route eigrp
     10.0.0.0/24 is subnetted, 3 subnets
D       10.0.1.0 [90/2172416] via 10.0.0.1, 00:05:14, FastEthernet0/0
R3#show ip route eigrp
     10.0.0.0/24 is subnetted, 3 subnets
D       10.0.0.0 [90/2172416] via 10.0.2.1, 00:00:54, Serial1/1
                 [90/2172416] via 10.0.1.1, 00:00:54, Serial1/0

Also of note from the show ip eigrp neighbors detail command is the "Suppressing queries" line. This goes back to the original purpose of stub routers, namely to tell the neighbours not to send any DUAL queries, which means the router will not be a transit network, nor will it hold up the rest of the network from converging.

Content Copyright Sean Walberg

EIGRP Stub Routers again

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Not so stubby areas get around this by allowing the ASBR to exist and propagate LSAs. The problem is that stub areas can’t have type 5 LSAs (external), so NSSAs use a type 7 LSA which is converted back to a type 5 on the ABR as the LSA is flooded to the backbone. Because of this functionality, all routers need to be configured as a NSSA.

R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#router ospf 1
R4(config-router)#area 2 nssa
OSPF: Area is configured as stub area already
R4(config-router)#no area 2 stub
R4(config-router)#area 2 nssa

And on the ABR:

r3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
r3(config)#router ospf 1
r3(config-router)#no area 2 stub
r3(config-router)#area 2 nssa

Like the stub area, we have lost our external route to 1.1.1.1:

R4#show 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

     4.0.0.0/24 is subnetted, 1 subnets
S       4.4.4.0 is directly connected, Null0
     10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C       10.0.2.0/24 is directly connected, FastEthernet0/0
O IA    10.0.0.0/24 [110/3] via 10.0.2.3, 00:00:27, FastEthernet0/0
O IA    10.0.1.0/24 [110/2] via 10.0.2.3, 00:00:27, FastEthernet0/0
O IA    10.0.33.1/32 [110/4] via 10.0.2.3, 00:00:27, FastEthernet0/0

Note there is no static route injected by the ABR! Another option is needed:

r3(config)#router ospf 1
r3(config-router)#area 2 nssa ?
default-information-originate Originate Type 7 default into NSSA area
no-redistribution No redistribution into this NSSA area
no-summary Do not send summary LSA into NSSA

r3(config-router)#area 2 nssa default-information-originate

Now, R4 has a default route:

O*N2 0.0.0.0/0 [110/1] via 10.0.2.3, 00:00:49, FastEthernet0/0

Note it is N2, meaning it is a type 7 (pseudo type 5) LSA.

R4#show ip ospf database nssa-external

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

                Type-7 AS External Link States (Area 2)

  Routing Bit Set on this LSA
  LS age: 102
  Options: (No TOS-capability, No Type 7/5 translation, DC)
  LS Type: AS External Link
  Link State ID: 0.0.0.0 (External Network Number )
  Advertising Router: 10.0.2.3
  LS Seq Number: 80000001
  Checksum: 0x454E
  Length: 36
  Network Mask: /0
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 1
        Forward Address: 10.0.2.3
        External Route Tag: 0

Remarkably similar to the default route we saw in the stub area!

Now, to make use of the nssa features.

R4(config)#router ospf 1
R4(config-router)#redistribute static subnets

With redistribute static subnets on, R4 generates type 7 LSAs for the 4.4.4.0 prefix:

R4#show ip ospf database nssa-external 4.4.4.0

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

                Type-7 AS External Link States (Area 2)

  LS age: 79
  Options: (No TOS-capability, Type 7/5 translation, DC)
  LS Type: AS External Link
  Link State ID: 4.4.4.0 (External Network Number )
  Advertising Router: 10.0.2.4
  LS Seq Number: 80000001
  Checksum: 0x367
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 10.0.2.4
        External Route Tag: 0

And R3 sees it as a N2 route:

r3#show 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

     1.0.0.0/24 is subnetted, 1 subnets
O E2    1.1.1.0 [110/10] via 10.0.1.2, 00:02:13, FastEthernet0/0
     4.0.0.0/24 is subnetted, 1 subnets
O N2    4.4.4.0 [110/20] via 10.0.2.4, 00:00:08, FastEthernet1/0
     9.0.0.0/24 is subnetted, 1 subnets
S       9.9.9.0 is directly connected, Null0
     10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C       10.0.2.0/24 is directly connected, FastEthernet1/0
O IA    10.0.0.0/24 [110/2] via 10.0.1.2, 00:02:13, FastEthernet0/0
C       10.0.1.0/24 is directly connected, FastEthernet0/0
O IA    10.0.33.1/32 [110/3] via 10.0.1.2, 00:02:13, FastEthernet0/0
r3#

And way over on R1, it looks like a regular old external route:

r1>show ip route 4.4.4.0
Routing entry for 4.4.4.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 3
  Last update from 10.0.0.2 on FastEthernet0/0, 00:01:11 ago
  Routing Descriptor Blocks:
  * 10.0.0.2, from 10.0.2.3, 00:01:11 ago, via FastEthernet0/0
      Route metric is 20, traffic share count is 1

r1>show ip ospf data
r1>show ip ospf database e
r1>show ip ospf database external 4.4.4.0

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 87
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 4.4.4.0 (External Network Number )
  Advertising Router: 10.0.2.3
  LS Seq Number: 80000001
  Checksum: 0x9DD7
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 10.0.2.4
        External Route Tag: 0

There is also a "no-summary" option to creating an NSSA, which does exactly the same thing as in stub areas.

How Does OSPF Generate Default Routes?
OSPF Not-So-Stubby Area (NSSA)

Content Copyright Sean Walberg

Not So Stubby Areas

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

I use dynagen to simulate my environment, it’s so good I ended up selling my routers! Here’s the config:

autostart = false 

[localhost]

    [[7200]]
   image = ..\images\c7200-jk9s-mz.122-40.bin
   npe = npe-400
    ram = 192

    [[ROUTER R1]]
    f0/0 = LAN 1

    [[ROUTER R2]]
    f0/0 = LAN 1
    f1/0 = LAN 2

    [[ROUTER R3]]
    f0/0 = LAN 2
    f1/0 = LAN 3

    [[ROUTER R4]]
    f0/0 = LAN 3

That sets up 4 7200 series routers, basically with crossover cables between them. (picture to come).

R1-R2 is area 1
R2-R3 is area 0
R3-R4 is area 2

R1 redistributes 1.1.1.0/24 into OSPF. R4 redistributes 4.4.4.0/24 into OSPF.

R4#show 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

     1.0.0.0/24 is subnetted, 1 subnets
O E2    1.1.1.0 [110/10] via 10.0.2.3, 00:00:27, FastEthernet0/0
     4.0.0.0/24 is subnetted, 1 subnets
S       4.4.4.0 is directly connected, Null0
     10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C       10.0.2.0/24 is directly connected, FastEthernet0/0
O IA    10.0.0.0/24 [110/3] via 10.0.2.3, 00:01:24, FastEthernet0/0
O IA    10.0.1.0/24 [110/2] via 10.0.2.3, 00:01:24, FastEthernet0/0
O IA    10.0.33.1/32 [110/4] via 10.0.2.3, 00:01:24, FastEthernet0/0
R4#

In the default OSPF config, the routes from both the backbone and area 1 are seen as O IA routes (interarea), and the redistributed route from R1 is E2 (note how the metric is always 10, no matter how far away it is, that's because it's E2 and not E1).

Area 2 is, topology wise, a stub (ditto R1). Everything has to leave by R3. By filtering the types of routes that make it into area 2 (on the ABR... remember we're in link state land here), the number of routes can be reduced allowing lower end routers to do the same job.

First order of business is to change area 2 into a stub with the "area 2 stub" command on R3 and R4. I had to remove the "redistribute static subnets" on R4 because an ASBR is not allowed within a stub area (more on this later)

r3(config)#router ospf 1
r3(config-router)#area 2 stub

R4(config)#router ospf 1
R4(config-router)#area 2 stub
OSPF: Stub command is invalid when it is ASBR

R4(config-router)#no redistribute static
R4(config-router)#area 2 stub

After OSPF reconverges, R4 has no more external routes. They have been replaced by a default route to an ABR:

R4#show 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 10.0.2.3 to network 0.0.0.0

     4.0.0.0/24 is subnetted, 1 subnets
S       4.4.4.0 is directly connected, Null0
     10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C       10.0.2.0/24 is directly connected, FastEthernet0/0
O IA    10.0.0.0/24 [110/3] via 10.0.2.3, 00:00:05, FastEthernet0/0
O IA    10.0.1.0/24 [110/2] via 10.0.2.3, 00:00:05, FastEthernet0/0
O IA    10.0.33.1/32 [110/4] via 10.0.2.3, 00:00:05, FastEthernet0/0
O*IA 0.0.0.0/0 [110/2] via 10.0.2.3, 00:00:05, FastEthernet0/0

And, of course, there are no type 5 LSAs on R4:

R4#show ip ospf database external

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

But there are on R3, because it's the one connected to the backbone:

r3#show ip ospf database external

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 544
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 1.1.1.0 (External Network Number )
  Advertising Router: 10.0.33.1
  LS Seq Number: 80000001
  Checksum: 0x1764
  Length: 36
  Network Mask: /24
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 10
        Forward Address: 0.0.0.0
        External Route Tag: 0

Looking back at the stub area, there are still a bunch of IntraArea routes (type 3 summary LSAs). At the ABR we can filter those out and rely on the default route.

r3(config)#router ospf 1
r3(config-router)#area 2 stub no-summary

Remember the no-summary means no type 3 summary LSAs, and has nothing to do with summarization of routes!

This has the effect of cleaning up R4's routing table nicely:

R4#show 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 10.0.2.3 to network 0.0.0.0

     4.0.0.0/24 is subnetted, 1 subnets
S       4.4.4.0 is directly connected, Null0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.0.2.0 is directly connected, FastEthernet0/0
O*IA 0.0.0.0/0 [110/2] via 10.0.2.3, 00:01:19, FastEthernet0/0

R4#show ip ospf database summary

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

                Summary Net Link States (Area 2)

  Routing Bit Set on this LSA
  LS age: 46
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 0.0.0.0 (summary Network Number)
  Advertising Router: 10.0.2.3
  LS Seq Number: 80000004
  Checksum: 0x31FA
  Length: 28
  Network Mask: /0
        TOS: 0  Metric: 1

The only summary route is the default route (0.0.0.0/0) advertised by R3.

This post has sat in draft long enough. I'll do a separate post about not-so-stubby areas, which fix the "no ASBR in stub zones" problem above.

Content Copyright Sean Walberg

OSPF Special Areas, with examples

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Stub areas exist to reduce the number of LSAs that are processed within an area. This is done by sacrificing some information. Practically, this means we filter out various routes that are coming into the area and replace it with a default route. Remember that as a link state protocol, all routers within the area have to have the same information, so most of the work is done on the ABR.

A stubby area ignores external routes (O E1, O E2), and permits both inter and intra area routes (O IA and O). The path to the external routes is replaced by a default route injected by the ABR.

Leaving a default route to the ABR to get to the external destinations leads you to say “If I can do that for external routes, why not do the same thing to the interarea routes?”. That would be a totally stubby area. Totally stubby areas have only intra area routes (O), with the ABRs injecting default routes. Because an ABR, by definition, is on the backbone, it knows all the routes.

From an LSA perspective, the area itself is flooding type 1 and 2 LSAs to represent the various router and link states. The ABR sorts through those and issues type 3 LSAs to the backbone, where it becomes an O IA route. External routes are type 5 LSAs.

So an ABR operating in stubby mode filters out type 5 LSAs. An ABR in totally stubby mode filters out both type 5 and 3. This is also why only the ABR needs the “no-summary” attribute (referring to the type 3 summary LSA, not a summary route), because only the ABR filters and injects a default route.

Anyone who’s been around a network for long knows that it’s hard to predict where you’re going to have a connection to another system where you might need to redistribute a route into your IGP. Any route redistributed into OSPF is automatically an external route, and makes the router an ASBR. However, ASBRs and external routes are not allowed in stubs, hence the NSSA. An NSSA behaves the same as a stubby area except that ASBRs are allowed, with some trickery happening to get around the rules.

In an NSSA, external routes are allowed if they originate inside. The ABRs still filter out the type 5 LSAs at the border. Any ASBR within an NSSA advertises external routes as type 7 routes instead of type 5. Thus, they show up in the routing table as O N1 instead of O E1. The ABR converts the type 7 LSA into a type 5 LSA before it advertises the LSA to the backbone.

Because of the restriction on the type 5 LSAs, and the need to understand type 7 LSAs, all routers in the area need to be configured as an NSSA.

The “no-summary” still exists, and is only needed on the ABR. So, in addition to the NSSA behaviour, you’re still allowed to filter out those interarea type 3 LSAs at the border.

NSSAs are goofy in that you need to originate a default route explicitly in the nssa command.

I have a labbed up example using dyna-gen that shows how it works using 3 routers. I’ll post all the configs and network descriptions if you want to follow along with real gear or simulated gear…. Stay tuned.

Content Copyright Sean Walberg

OSPF special areas: stubby, not so stubby, and totally stubby

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

The exam seems to only care about Protocol Independent Multicast (PIM), which uses the router’s routing table to determine whether or not a multicast packet is to be forwarded. When packet is received on an interface the router looks at the route back to the source. If the interface the packet was received on is the same as the one it would use to send a response, the reverse path forwarding test is sucessful and the packet is forwarded.

PIM operates in two modes, sparse and dense. In sparse mode it is assumed that most people don’t care about the stream and therefore the router must explicity add branches to the multicast tree. In dense mode it is assumed that there are a lot of listeners, and it is the obligation of the router to prune. This is handled through IGMP which is another article.

Consider the following network:

R5 has its E0 interface shut down so that the serial link is used.

I set up everything in PIM dense mode, meaning I needed only

ip pim dense-mode

on every interface.

From R0

r0#show ip pim neighbor
PIM Neighbor Table
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
2.2.2.1           Multilink1               1d02h/00:01:43    v2    1 / S
10.50.0.3         Ethernet0                1d02h/00:01:24    v2    1 / DR S

the output of that shows two PIM adjacencies, one out the multilink (R1) and one on the Ethernet (R3). Under the "Mode" column, S means "state refresh capable" and DR means that the router is the designated router for the segment.

To test multicast, I used Multicast Routing Monitor to generate traffic:

r1#show run int mu1
Building configuration...

Current configuration : 138 bytes
!
interface Multilink1
 ip address 2.2.2.1 255.255.255.252
 ip pim sparse-mode
 ip mrm test-sender
 ppp multilink
 multilink-group 1
end

R0:

ip mrm manager test1
 manager Ethernet0 group 239.1.1.1
 senders 1
 receivers 2 sender-list 1
access-list 1 permit 2.2.2.1
access-list 2 permit 5.5.5.5
access-list 2 permit 10.50.0.3
r3#show run int e0
Building configuration...

Current configuration : 111 bytes
!
interface Ethernet0
 ip address 10.50.0.3 255.255.255.0
 ip pim sparse-dense-mode
 ip mrm test-receiver
end

A similar receiver exists on R5's loop0.

The mrm tester on R0 sets up a multicast stream from 2.2.2.1 to 5.5.5.5 and 10.50.0.3 using multicast group 239.1.1.1:

r0#show ip mrm manager
Manager:test1/10.50.0.1 is not running
  Beacon interval/holdtime/ttl:60/86400/32
  Group:239.1.1.1, UDP port test-packet/status-report:16384/65535
  Test senders:
    2.2.2.1
  Test receivers:
    5.5.5.5                  10.50.0.3

Finally, the test can be started:

r0#mrm test1 start
r0#
1d03h: IP MRM test 'test1' starts ......
1d03h: IP MRM status report -- Test:test1  Receiver:10.50.0.3
1d03h:   Sender:2.2.2.1          Pkt Loss:1(4%)  Ehsr:8
1d03h: IP MRM status report -- Test:test1  Receiver:5.5.5.5
1d03h:   Sender:2.2.2.1          Pkt Loss:5(20%)  Ehsr:0
1d03h: IP MRM status report -- Test:test1  Receiver:10.50.0.3
1d03h:   Sender:2.2.2.1          Pkt Loss:1(4%)  Ehsr:8
1d03h: IP MRM status report -- Test:test1  Receiver:5.5.5.5
1d03h:   Sender:2.2.2.1          Pkt Loss:5(20%)  Ehsr:0
1d03h: IP MRM status report -- Test:test1  Receiver:5.5.5.5
1d03h:   Sender:2.2.2.1          Pkt Loss:15(60%)  Ehsr:0
1d03h: IP MRM status report -- Test:test1  Receiver:5.5.5.5
1d03h:   Sender:2.2.2.1          Pkt Loss:20(80%)  Ehsr:0
1d03h: IP MRM status report -- Test:test1  Receiver:5.5.5.5
1d03h:   Sender:2.2.2.1          Pkt Loss:25(100%)  Ehsr:0
1d03h: IP MRM status report -- Test:test1  Receiver:5.5.5.5
1d03h:   Sender:2.2.2.1          Pkt Loss:25(100%)  Ehsr:0

I see a bit of loss at the beginning, but after that it stops:

r0#show ip mrm manager
Manager:test1/10.50.0.1 is running, expire:23:56:53
  Beacon interval/holdtime/ttl:60/86400/32
  Group:239.1.1.1, UDP port test-packet/status-report:16384/65535
  Test senders:
    2.2.2.1          /Ack
  Test receivers:
    5.5.5.5          /Ack    10.50.0.3        /Ack

From R5, looking at the multicast route:

r5#show ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 00:06:43/stopped, RP 10.50.0.3, flags: SJPC
  Incoming interface: Ethernet0, RPF nbr 10.50.0.3
  Outgoing interface list: Null

(2.2.2.1, 239.1.1.1), 00:06:43/00:02:54, flags: PTX
  Incoming interface: Ethernet0, RPF nbr 10.50.0.1
  Outgoing interface list: Null
r0#show ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 01:27:52/stopped, RP 10.50.0.3, flags: SJCF
  Incoming interface: Ethernet0, RPF nbr 10.50.0.3
  Outgoing interface list:
    Multilink1, Forward/Dense, 01:27:52/00:00:00

(2.2.2.1, 239.1.1.1), 01:27:52/00:02:51, flags: FT
  Incoming interface: Multilink1, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet0, Forward/Dense, 00:05:32/00:00:00, A

r3#show ip mroute 239.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched, A - Assert winner
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.1.1.1), 01:28:24/00:03:25, RP 10.50.0.3, flags: SJCL
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Ethernet0, Forward/Sparse-Dense, 01:28:23/00:03:25

(2.2.2.1, 239.1.1.1), 01:28:24/00:02:59, flags: PLT
  Incoming interface: Ethernet0, RPF nbr 10.50.0.1
  Outgoing interface list: Null

Content Copyright Sean Walberg

Multicast – PIM implementation and testing with MRM

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

This comes at the expense a larger query scope for the DUAL algorithm, which results in more Stuck in Active (SIA) routes. In many cases you know if a particular router will never transit traffic (ie all traffic comes from, or to, networks attached to the router). These are called stub zones (or areas). OSPF has these concepts, and so does EIGRP, it’s just that it’s not widely known.

R0 and R1 are distribution routers connected to the corporate backbone. R2 is connected over the WAN, and is a remote office.

From R2’s perspective, any routes coming from R0 should not be advertised back to R1, and vice-versa. Likewise, when going active on a router, R0 and R1 shouldn’t ask R2. But, by default, all of this happens to poor R2.

By configuring R2 as a stub you can choose what type of routes to advertise: connected, static, summary, or a combination of the three. You can also choose to advertise no routes, and rely on the distribution layer to handle this for you.

r2(config)#router eigrp 1
r2(config-router)#eigrp stub ?
  connected     Do advertise connected routes
  receive-only  Set IP-EIGRP as receive only neighbor
  static        Do advertise static routes
  summary       Do advertise summary routes

r2(config-router)#eigrp stub

On R0, we can now see that the neighbour is known as a stub, and that since I didn’t specify what type of routes to advertise, the defaults are connected and summary routes (ie not redistributed static routes). R0 also knows not to make any queries to R2 in the event that it goes active on a route.

r0#show ip eigrp neighbors detail
IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   10.2.2.1                Se0.131           14 00:00:51  444  2664  0  39
   Version 12.1/1.2, Retrans: 0, Retries: 0
   Stub Peer Advertising ( CONNECTED SUMMARY ) Routes
   Suppressing queries
1   10.50.0.2               Et0               10 00:01:22   23   200  0  40
   Version 12.2/1.2, Retrans: 3, Retries: 0

Cisco has a document about EIGRP stub routing, and Optimal Routing Design has a section on it, which is where I originally learned about this feature.

Content Copyright Sean Walberg

EIGRP Stub Routers

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

A simple three-router network:

192.168.0.0/16 is in the EIGRP domain, and 10.0.0.0/8 is in IS-IS. Each router has a loopback or two just for fun. R1 will be doing redistribution.

R2:

router eigrp 1
 network 0.0.0.0
 no auto-summary
 no eigrp log-neighbor-changes

R1:

clns routing
interface Loopback5
 ip router isis
interface Ethernet0
 ip router isis
router eigrp 1
 network 192.168.0.0 0.0.255.255
 no auto-summary
!
router isis
 net 49.0001.0100.5000.0002.00

R3:

clns routing
interface Loopback5
 ip router isis
interface Ethernet0
 ip router isis
router isis
 net 49.0001.0100.5000.0003.00

Routing tables on R3:

     10.0.0.0/24 is subnetted, 3 subnets
i L1    10.1.1.0 [115/20] via 10.50.0.2, Ethernet0
C       10.3.3.0 is directly connected, Loopback5
C       10.50.0.0 is directly connected, Ethernet0

Routing tables on R2:

D    192.168.11.0/24 [90/40640000] via 192.168.5.1, 01:30:25, Serial0
C    192.168.5.0/24 is directly connected, Serial0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.2.2.0 is directly connected, Loopback5
C    11.0.0.0/8 is directly connected, Loopback6

On R1, redistribute mutually between IS-IS and EIGRP:

router eigrp 1
 redistribute isis level-2 metric 10000 100 255 1 1500
 network 192.168.0.0 0.0.255.255
 no auto-summary
!
router isis
 net 49.0001.0100.5000.0002.00
 redistribute eigrp 1 metric 5

Routing tables on R3:

i L2 192.168.11.0/24 [115/15] via 10.50.0.2, Ethernet0
i L2 192.168.5.0/24 [115/15] via 10.50.0.2, Ethernet0
     10.0.0.0/24 is subnetted, 4 subnets
i L2    10.2.2.0 [115/15] via 10.50.0.2, Ethernet0
i L1    10.1.1.0 [115/20] via 10.50.0.2, Ethernet0
C       10.3.3.0 is directly connected, Loopback5
C       10.50.0.0 is directly connected, Ethernet0
i L2 11.0.0.0/8 [115/15] via 10.50.0.2, Ethernet0

Hmm… Everything there seems to be in order.

Routing tables on R2:

D    192.168.11.0/24 [90/40640000] via 192.168.5.1, 01:33:23, Serial0
C    192.168.5.0/24 is directly connected, Serial0
     10.0.0.0/24 is subnetted, 2 subnets
D EX    10.3.3.0 [170/40537600] via 192.168.5.1, 00:01:50, Serial0
C       10.2.2.0 is directly connected, Loopback5
C    11.0.0.0/8 is directly connected, Loopback6

Here, we’re missing 10.1.1.0 and 10.50.0.0 which are connected routes inside IS-IS. According to this TAC case, IS-IS connected routes don’t get redistributed:

When Intermediate System-to-Intermediate System (IS-IS) is redistributed into Open Shortest Path First (OSPF), some IS-IS routes may not be redistributed successfully. Specifically, routes advertised using IS-IS on the redistributing router are not redistributed. This behavior is expected. If a directly connected network is also advertised by IS-IS, the route is entered into the local routing table as a connected route and not as an IS-IS route. While redistributing IS-IS into OSPF, these directly connected routes are not injected into OSPF.

As I’ve shown, this also happens for EIGRP. The solution is to redistribute connected into EIGRP:

r1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
r1(config)#router eigrp 1
r1(config-router)#redistribute connected 

r2#show ip route
...

D    192.168.11.0/24 [90/40640000] via 192.168.5.1, 01:43:24, Serial0
C    192.168.5.0/24 is directly connected, Serial0
     10.0.0.0/24 is subnetted, 4 subnets
D EX    10.1.1.0 [170/40640000] via 192.168.5.1, 00:00:13, Serial0
D EX    10.3.3.0 [170/40537600] via 192.168.5.1, 00:11:50, Serial0
C       10.2.2.0 is directly connected, Loopback5
D EX    10.50.0.0 [170/40537600] via 192.168.5.1, 00:00:13, Serial0
C    11.0.0.0/8 is directly connected, Loopback6

The alternative would have been to turn on EIGRP for all interfaces and mark the two 10/8 networks as passive-interfaces. This would put the routes into EIGRP as internal routes.

So there you have it. When redistributing out of IS-IS, any locally connected routes that aren’t already in the destination protocol of the redistributing router don’t get carried over.

Content Copyright Sean Walberg

Redistribution involving IS-IS

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

BGP peer groups simplify the configuration of BGP neighbors by moving the template into a configuration. For example, look at R3:

 router bgp 1
  no synchronization
  bgp log-neighbor-changes
  network 10.3.3.0 mask 255.255.255.0
  network 10.50.0.0 mask 255.255.0.0
  neighbor 10.50.0.1 remote-as 1
  neighbor 10.50.0.2 remote-as 1
  neighbor 10.50.0.2 route-reflector-client
  neighbor 10.50.0.4 remote-as 1
  neighbor 10.50.0.4 route-reflector-client

There are two route reflector clients here with similar configuration. There are only two lines per client, but it is entirely possible that there could be more in the future.

router bgp 1
 neighbor rrclient peer-group
 neighbor rrclient remote-as 1
 neighbor rrclient route-reflector-client
 neighbor 10.50.0.1 remote-as 1
 neighbor 10.50.0.2 peer-group rrclient
 neighbor 10.50.0.4 peer-group rrclient

Here, I’ve defined defined a peer group called rrclient that has a remote-as of 1 and defines the peer as being a route-reflector client. At the neighbor level, I simply define it as being part of the peer group.

Behavior at the peer group level can be overridden. Take for example a peer group for eBGP peers, every one will have a different remote-as. The peer-group wouldn’t define the remote-as, but we’d have something like

  neighbor x.x.x.x peer-group ebgpclients
  neighbor x.x.x.x remote-as XXXX

A neighbor’s configuration can also override the peer-group on a per neighbor basis.

 neighbor filterme peer-group
 neighbor filterme route-map filtercustomers out
 neighbor x.x.x.x peer-group filterme
 neighbor x.x.x.x remote-as XXXX
 neighbor x.x.x.x route-map filternone out

Here, the x.x.x.x neighbor would have the filternone filter applied, while any other configured neighbors would have filtercustomers.

Peer groups are used to scale the configuration of BGP peers. They also reduce the possibility of errors.

Content Copyright Sean Walberg

BGP Peer Groups

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

The specifics of the topology don’t matter too much. R0, R1, R3, and R6 are all in AS1 and happen to be sitting on the same LAN segment. R1 connects to R2 over a serial line, and R2 is in AS2. R3 is the route reflector, R1 and R6 are clients. R0 is outside the cluster.

Configs:

r0#sh run | begin router bgp
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.50.0.3 remote-as 1
 no auto-summary

r1#sh run | begin router bgp
router bgp 1
 bgp log-neighbor-changes
 neighbor 10.50.0.3 remote-as 1
 neighbor 192.168.3.10 remote-as 2

r2#sh run | begin router bgp
router bgp 2
 bgp log-neighbor-changes
 network 10.2.2.0 mask 255.255.255.0
 network 11.0.0.0
 neighbor 192.168.3.9 remote-as 1

r3#sh run | begin router bgp
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 network 10.3.3.0 mask 255.255.255.0
 network 10.50.0.0 mask 255.255.0.0
 neighbor 10.50.0.1 remote-as 1
 neighbor 10.50.0.2 remote-as 1
 neighbor 10.50.0.2 route-reflector-client
 neighbor 10.50.0.4 remote-as 1
 neighbor 10.50.0.4 route-reflector-client

r6#sh run | begin router bgp
router bgp 1
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.50.0.3 remote-as 1
 no auto-summary

Now, looking at the BGP entries for 11/8 which comes from R2.

From the route reflector itself:

r3#show ip bgp 11.0.0.0
BGP routing table entry for 11.0.0.0/8, version 6
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to non peer-group peers:
  10.50.0.1 10.50.0.4
  2, (Received from a RR-client)
    192.168.3.10 (metric 74) from 10.50.0.2 (10.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best

This says that we got the announcement from R1 (10.50.0.2), and are re-advertising it to 10.50.0.1 and 10.50.0.4. This is not normal iBGP behaviour, but since we’re a route-reflector, that’s ok. Look at the same prefix on r0, which is outside the cluster:

r0>show ip bgp 11.0.0.0
BGP routing table entry for 11.0.0.0/8, version 4
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  2
    192.168.3.10 (metric 74) from 10.50.0.3 (10.3.3.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 10.1.1.1, Cluster list: 10.3.3.1

We got it from 10.50.0.3, and see the Originator/Cluster List attributes have been added.

Looking from a client, the story is the same:

r6#show ip bgp 11.0.0.0
BGP routing table entry for 11.0.0.0/8, version 8
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  2
    192.168.3.10 (metric 74) from 10.50.0.3 (10.3.3.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 10.1.1.1, Cluster list: 10.3.3.1

So, we’ve reduced the number of iBGP sessions required by using route reflectors.

Content Copyright Sean Walberg

BGP Route Reflectors Example

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.