cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Community Helping Community

2495
Views
5
Helpful
5
Replies
Highlighted
VIP Advisor

OSPF reconvergence after fail over

I am implementing a solution for for a customer that has dual WAN links for redundancy. In order to achieve this (and for security purposes) I have implemented 2 OSPF processes (one of which is a on a VRF).

The subnet that I am testing for fail over is 10.233.20.0/24.  under normal circumstances that route is in the routing table in OSPF 1:

N_Primary#sh ip route 10.233.20.0

Routing entry for 10.233.20.0/24

  Known via "ospf 11", distance 110, metric 110

  Tag Complete, Path Length == 1, AS 65031, , type extern 1

  Last update from 10.133.1.250 on Ethernet0/3, 00:04:14 ago

  Routing Descriptor Blocks:

  * 10.133.1.250, from 10.133.1.250, 00:04:14 ago, via Ethernet0/3

      Route metric is 110, traffic share count is 1

      Route tag 3489725959

When I fail the primary link, the secondary link kicks in using OSPF11 to populate the routing table  (higher metric of 110)

NOC_Primary#sh ip route 10.233.20.0

Routing entry for 10.233.20.0/24

  Known via "ospf 11", distance 110, metric 4010

  Tag Complete, Path Length == 1, AS 65031, , type extern 1

  Last update from 10.133.1.250 on Ethernet0/3, 00:01:13 ago

  Routing Descriptor Blocks:

  * 10.133.1.250, from 10.133.1.250, 00:01:13 ago, via Ethernet0/3

      Route metric is 4010, traffic share count is 1

      Route tag 3489725959

As can be seen below, both processes have the 10.233.20.0 subnet in their DB, with different metrics as the only difference

N_Primary#sh ip ospf 11 database external 10.233.20.0   (FROM SECONDARY)

            OSPF Router with ID (10.133.1.254) (Process ID 11)

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 98
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.233.20.0 (External Network Number )
  Advertising Router: 10.133.1.250
  LS Seq Number: 80000001
  Checksum: 0x4DCD
  Length: 36
  Network Mask: /24
        Metric Type: 1 (Comparable directly to link state metric)
        TOS: 0
        Metric: 4000        <-------------------------HIGHER METRIC
        Forward Address: 0.0.0.0
        External Route Tag: 3489725959

N_Primary#sh ip ospf 1 database external 10.233.20.0     (FROM PRIMARY LINK)

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

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 1120
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 10.233.20.0 (External Network Number )
  Advertising Router: 10.133.0.2
  LS Seq Number: 80000001
  Checksum: 0x623D
  Length: 36
  Network Mask: /24
        Metric Type: 1 (Comparable directly to link state metric)
        TOS: 0
        Metric: 1   <--------LOWEST, MOST PREFERRED
        Forward Address: 0.0.0.0
        External Route Tag: 65530

The problem is that when bring the PRIMARY link back up, the routing table on my router, will not converge back to the original route with the cheaper metric.
Not even after the 30 minute periodic LSA recomputation interval. Any suggestions on how to force fall back to the more favourable route with the lower metric to the primary WAN?

Please remember to rate useful posts, by clicking on the stars below.

Everyone's tags (5)
1 ACCEPTED SOLUTION

Accepted Solutions
Engager

OSPF reconvergence after fail over

Please check the following link:

http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080531fd2.shtml#topic2

It explains about redistribution between two ospf processes.

Your problem is quite similar and has to with the administrative distance.

Perhaps it wil work when you reduce the AD on opsf process 1.

regards,

Leo

View solution in original post

5 REPLIES 5
Engager

OSPF reconvergence after fail over

Perhaps I understand you wrong but from the output provided it looks different:

The subnet that I am testing for fail over is 10.233.20.0/24.  under normal circumstances

that route is in the routing table in OSPF 1:

N_Primary#sh ip route 10.233.20.0

Routing entry for 10.233.20.0/24

  Known via "ospf 11", distance 110, metric 110

  ....

regards,

Leo

VIP Advisor

OSPF reconvergence after fail over

You are spot on, I pasted the wrong output in.

so in normal scenario when Primary WAN is up, the route should show the following:

N_Primary#sh ip route 10.233.20.0

Routing entry for 10.233.20.0/24

  Known via "ospf 1", distance 110, metric 21

  Tag 65530, type extern 1

  Last update from 10.133.2.125 on Ethernet0/0.102, 00:00:08 ago

  Routing Descriptor Blocks:

  * 10.133.2.125, from 10.133.0.2, 00:00:08 ago, via Ethernet0/0.102

      Route metric is 21, traffic share count is 1

      Route tag 65530

Please remember to rate useful posts, by clicking on the stars below.

Engager

OSPF reconvergence after fail over

Please check the following link:

http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080531fd2.shtml#topic2

It explains about redistribution between two ospf processes.

Your problem is quite similar and has to with the administrative distance.

Perhaps it wil work when you reduce the AD on opsf process 1.

regards,

Leo

View solution in original post

VIP Advisor

OSPF reconvergence after fail over

Thanks mate, I had it fixed, before i read your post but you are spot on again, I changed the AD of one of the processes to 120 and now fail over and fall back are working properly.

I guess with fall back, although the primary link re-populates OSPF 1 , it will keep the original route even though new LSA's occurr, the LSA's from one process are not taken into account into another process, tweaking the AD changes that behaviour.

Thanks again

Please remember to rate useful posts, by clicking on the stars below.

Hall of Fame Cisco Employee

OSPF reconvergence after fail over

Leo,

Exactly. I've just made a simple three router scenario where two routers advertised the same external network to the third one, having a different total metric. The routing table on the third router always contained the first advertised alternative, and was removed (and replaced) only if the original route became unreachable. The metric did not have any influence - modifying the administrative distance solved this.

Good point!

Best regards,

Peter

CreatePlease to create content
Content for Community-Ad
FusionCharts will render here