cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2031
Views
9
Helpful
10
Replies

default route not inject after reload - OSPF

Alberto Seg
Level 1
Level 1

                   Hi all,

We have 1 router connected to 1 switch running OSPF between them in the part of LAN. . When SW starts OSPF must be known a default route pointing to router, but the problem I'm having is after the switch is reloaded this is not happening.

Router is a 1841 and Sw is a 3750.

Correct situation must be show this sh ip route

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

Gateway of last resort is 10.17.102.61 to network 0.0.0.0

     10.0.0.0/8 is variably subnetted, 7 subnets, 4 masks
O       10.200.18.232/30
           [110/1001] via 10.17.102.61, 00:23:30, GigabitEthernet1/0/1
O E2    10.200.18.233/32
           [110/20] via 10.17.102.61, 00:23:30, GigabitEthernet1/0/1
C       10.17.102.60/30 is directly connected, GigabitEthernet1/0/1
S       10.17.102.40/29 [1/0] via 10.17.102.3
C       10.17.102.32/29 is directly connected, Vlan2001
C       10.17.102.0/27 is directly connected, Vlan2000
O       10.200.39.20/32
           [110/1001] via 10.17.102.61, 00:23:30, GigabitEthernet1/0/1
O*E2 0.0.0.0/0 [110/1] via 10.17.102.61, 00:23:30, GigabitEthernet1/0/1

But in fact, after the 3750 is reloaded routing table is the next:

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

Gateway of last resort is not set

     10.0.0.0/8 is variably subnetted, 7 subnets, 4 masks
O       10.200.18.232/30
           [110/50001] via 10.17.102.61, 00:20:25, GigabitEthernet1/0/1
O E2    10.200.18.233/32
           [110/20] via 10.17.102.61, 00:20:25, GigabitEthernet1/0/1
C       10.17.102.60/30 is directly connected, GigabitEthernet1/0/1
S       10.17.102.40/29 [1/0] via 10.17.102.3
C       10.17.102.32/29 is directly connected, Vlan2001
C       10.17.102.0/27 is directly connected, Vlan2000
O       10.200.39.20/32
           [110/2] via 10.17.102.61, 00:20:25, GigabitEthernet1/0/1

Any idea it may be happening? We have another's headquarters with similar topologies and there aren't problems...

Rgds

1 Accepted Solution

Accepted Solutions

Hello Alberto,

an LSA type 5 should have a forwarding address ( you can think of a sort of next-hop) that is reachable via an internal route.

That is an OSPF external route cannot have a next-hop that is another OSPF external route-

In your case the 0.0.0.0/0 has  a forwarding address that is represented as  /32 O E2 route

10.200.18.233/32 that is the result of redistribution of connected into OSPF (see the tag 104 in the LSA)

So you face a race condition: if the O E2 for 10.200.18.233 is installed before the 0.0.0.0/0 is taken in consideration the LSA relative to default network 0.0.0.0 may be ignored and no OSPF default route is installed in the switch routing table.

So the LSA for 0.0.0.0/0 is present but the routing bit is not set for this reason as noted by John.

The clear ip route * gives a chance for competition again and can fix. But it is not a good solution.

I would suggest on the router to remove the line that redistributes the connected routes, so that the forwarding address 10.200.18.233 is always resolved by an internal route, as you have the correct network area command under router ospf process on the C1841.

This should remove the race condition and should provide deterministic behaviour.

Hope to help

Giuseppe

View solution in original post

10 Replies 10

Peter Paluch
Cisco Employee
Cisco Employee

Hi Alberto,

Can you please issue the show ip ospf database external on the 3750 and post the entire results here? I am interested in seeing whether the LSA-5 that carries, among other external networks, the default route was received by your 3750.

Thank you!

Best regards,

Peter

Hi Peter,


When the default-route is correctly known:


D31SESSR01#sh ip ospf database external

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 1746 (DoNotAge)
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 0.0.0.0 (External Network Number )
  Advertising Router: 10.17.102.61
  LS Seq Number: 8000002B
  Checksum: 0x55A5
  Length: 36
  Network Mask: /0
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 1
        Forward Address: 10.200.18.233
        External Route Tag: 1

  LS age: 196
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.17.102.40 (External Network Number )
  Advertising Router: 10.17.102.1
  LS Seq Number: 8000002E
  Checksum: 0x7BCE
  Length: 36
  Network Mask: /29
        Metric Type: 1 (Comparable directly to link state metric)
        TOS: 0
        Metric: 20
        Forward Address: 10.17.102.3
        External Route Tag: 0

  Routing Bit Set on this LSA
  LS age: 1746 (DoNotAge)
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.200.18.233 (External Network Number )
  Advertising Router: 10.17.102.61
  LS Seq Number: 8000002A
  Checksum: 0xF789
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 0.0.0.0
        External Route Tag: 104


without default route in routing table after reloaded:


D31SESSR01#sh ip ospf database external

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

                Type-5 AS External Link States

  LS age: 302
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 0.0.0.0 (External Network Number )
  Advertising Router: 10.17.102.61
  LS Seq Number: 8000002C
  Checksum: 0x53A6
  Length: 36
  Network Mask: /0
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 1
        Forward Address: 10.200.18.233
        External Route Tag: 1

  LS age: 61
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.17.102.40 (External Network Number )
  Advertising Router: 10.17.102.1
  LS Seq Number: 8000002E
  Checksum: 0x7BCE
  Length: 36
  Network Mask: /29
        Metric Type: 1 (Comparable directly to link state metric)
        TOS: 0
        Metric: 20
        Forward Address: 10.17.102.3
        External Route Tag: 0

  Routing Bit Set on this LSA
  LS age: 303
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.200.18.233 (External Network Number )
  Advertising Router: 10.17.102.61
  LS Seq Number: 8000002B
  Checksum: 0xF58A
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 20
        Forward Address: 0.0.0.0
        External Route Tag: 104

Rgds

I noticed in this first copy of the ospf database (external records) the default route shows Routing Bit Set on this LSA.

Can you copy your ospf config when you see the default route successfully and when it doesn't show up? As far as I know, I believe this means it's a candidate to be installed in the routing table.

Ospf Config is the same when is shown the default route successfully and when it doesn't show up. attached config.

In fact, the problem is resolved with clear ip route * on the switch once sw has been reloaded. At this moment sw known correctly default-route

Config router:

router ospf 1
router-id 10.17.102.61
log-adjacency-changes
redistribute connected subnets tag 104
redistribute static subnets tag 104
redistribute bgp 65123 subnets tag 104
network 10.17.102.60 0.0.0.3 area 503
network 10.200.18.232 0.0.0.3 area 503
network 10.200.39.20 0.0.0.0 area 503
default-information originate

Config 3750

 

router ospf 1

router-id 10.17.102.1

log-adjacency-changes

auto-cost reference-bandwidth 100000

redistribute static metric-type 1 subnets

network 10.17.102.0 0.0.0.31 area 503

network 10.17.102.32 0.0.0.7 area 503

network 10.17.102.40 0.0.0.7 area 503

network 10.17.102.60 0.0.0.3 area 503

Rgds

What kind of link connects the two? Also, I'm assuming you have a static default route on your Router?

Hello Alberto,

an LSA type 5 should have a forwarding address ( you can think of a sort of next-hop) that is reachable via an internal route.

That is an OSPF external route cannot have a next-hop that is another OSPF external route-

In your case the 0.0.0.0/0 has  a forwarding address that is represented as  /32 O E2 route

10.200.18.233/32 that is the result of redistribution of connected into OSPF (see the tag 104 in the LSA)

So you face a race condition: if the O E2 for 10.200.18.233 is installed before the 0.0.0.0/0 is taken in consideration the LSA relative to default network 0.0.0.0 may be ignored and no OSPF default route is installed in the switch routing table.

So the LSA for 0.0.0.0/0 is present but the routing bit is not set for this reason as noted by John.

The clear ip route * gives a chance for competition again and can fix. But it is not a good solution.

I would suggest on the router to remove the line that redistributes the connected routes, so that the forwarding address 10.200.18.233 is always resolved by an internal route, as you have the correct network area command under router ospf process on the C1841.

This should remove the race condition and should provide deterministic behaviour.

Hope to help

Giuseppe

That was an excellent read Guiseppe, learned a lot!

Thanks Giuseppe, you are right, that was the problem.

I corrected network area command under OSPF in C1841 to solve.

Regards

Hi Alberto,

If your case was solved then please mark the thread as answered by clicking on the button "Correct Answer" on Giuseppe's answer. Others having the same issue will know that this thread includes a solution (and Giuseppe gets the proper credit he deserves).

Best regards,

Peter

Ok Peter, thanks for the info, I don't know.

marked response as correctly

regards

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card