Static routes redistributed by two routers doesn't appear in OSPF database

Answered Question
Dec 21st, 2009
User Badges:

Hello,


As show in the picture below.


OSPF - Problem.jpg


I redistribute the same static routes from my two ABR-ASBR routers (RTR1 & RTR2) inside OSPF area 0 and 1. The Next Hop for every static routes is FW1.


When I'm looking the Ospf database on every devices in Backbone Area or in Area 1, only the RTR2 LSA are present.


I should see also the same LSA from RTR1, isn't it ?


If anyone can help...


regards,


Julien



-------------------------------------------

Find below the Configurations:

-------------------------------------------


**** Same config For RTR1 and RTR2 ****

! Static Redistributed routes in Ospf

ip route xx.0.1.16 255.255.255.240 xx.18.225.1
ip route xx.0.2.16 255.255.255.240 xx.18.225.1


! Static-to-ospf matching

access-list 6 remark *** JUNIPER STATIC NETWORK
access-list 6 permit 55.0.0.0 0.0.255.255


! Static-to-ospf filtering

route-map STATIC-to-OSPF permit 10
match ip address 6


! Ospf config

router ospf 100
router-id xx.0.18.1
log-adjacency-changes
network xxxx area 0

network yyyy area 1
redistribute static metric 10 metric-type 1 subnets route-map STATIC-to-OSPF

-------------------------------------------

Find below the Ospf Database extract from RTR1:

-------------------------------------------

RTR1#sh ip ospf database external adv-router RTR1


            OSPF Router with ID ($RTR1) (Process ID 100)



RTR1#sh ip ospf database external adv-router RTR2


            OSPF Router with ID ($RTR1) (Process ID 100)


                Type-5 AS External Link States


  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 16
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: xx.0.1.16 (External Network Number )
  Advertising Router: $RTR2
  LS Seq Number: 800000B6
  Checksum: 0x4C0
  Length: 36
  Network Mask: /28
        Metric Type: 1 (Comparable directly to link state metric)
        MTID: 0
        Metric: 10
        Forward Address: $FW1
        External Route Tag: 0

Correct Answer by marikakis about 7 years 6 months ago

Hi all,


I think Giuseppe pointed to the correct direction. I think your case is described in RFC2328 (Section 12.4.4.1.  Examples of AS-external-LSAs):

"In figure 16, suppose instead that both RTA and RTB exchange BGP information with RTX.  In this case, RTA and RTB would originate the same set of AS-external-LSAs.  These LSAs, if they specify the same metric, would be functionally equivalent since they would specify the same destination and forwarding address (RTX).  This leads to a clear duplication of effort.  If only one of RTA or RTB originated the set of AS-external-LSAs, the routing would remain the same, and the size of the link state database would decrease.  However, it must be unambiguously defined as to which router originates the LSAs (otherwise neither may, or the identity of the originator may oscillate).  The following rule is thereby established: if two routers, both reachable from one another, originate functionally equivalent AS-external-LSAs (i.e., same destination, cost and non-zero forwarding address), then the LSA originated by the router having the highest OSPF Router ID is used.  The router having the lower OSPF Router ID can then flush its LSA. Flushing an LSA is discussed in Section 14.1."


Kind Regards,

Maria

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
Peter Paluch Mon, 12/21/2009 - 06:49
User Badges:
  • Cisco Employee,

Julien,


Excuse me if I'm asking a stupid question but are the static routes really present in the routing table of the RTR1 and recognized as static? Also, is it possible that you have somewhere made a trivial typo on the RTR1 such as big/smallcase letters or anything similar? Are there hit counters increasing on entries of the ACL 6?


Best regards,

Peter

ju.mahieu Mon, 12/21/2009 - 08:42
User Badges:

Thanks for your

answer.


Unfortunately, my static are valid and I can see the "matches" increased on the ACL 6.

RTR1#sh ip route static

S        xx.0.1.16/28 [1/0] via xx.18.225.1
S        xx.0.2.16/28 [1/0] via xx.18.225.1
S        xx.0.4.16/28 [1/0] via xx.18.225.1


RTR1#sh access-lists 6
Standard IP access list 6
    10 permit xx.0.0.0, wildcard bits 0.0.255.255 (15 matches)


Ju

paolo bevilacqua Mon, 12/21/2009 - 06:39
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

[can't really help, sorry ]


Message was edited by: p.bevilacqua

Giuseppe Larosa Mon, 12/21/2009 - 08:01
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Julien,

two other notes:


you say same configuration on RTR1 and RTR2, but have you configured two different OSPF router-ids ? You need to use different router-ids they have to be unique.


second note: what type of area is area 1.  If area 1 were an NSSA area this behaviour with LSA generated by only one ABR/ASBR would be correct.


see

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094a88.shtml


Peter's note about counters of ACL 6 are a good way to see if redistribution process is finding static routes to be injected in OSPF domain.


Hope to help

Giuseppe

ju.mahieu Mon, 12/21/2009 - 08:51
User Badges:

Hello,


My two RID are different on RTR1 and RTR2 and I don't have any nssa area on my network, as shown below:

RTR1#sh ip ospf
Routing Process "ospf 100" with ID xx.0.18.1

[...]

Number of areas in this router is 2. 2 normal 0 stub 0 nssa


RTR2#sh ip ospf
Routing Process "ospf 100" with ID xx.0.18.2

[...]

Number of areas in this router is 2. 2 normal 0 stub 0 nssa


Thanks again...


Regards,


Ju

Giuseppe Larosa Mon, 12/21/2009 - 09:15
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Julien,

is this a lab or a production environment?


if it is a lab I would try to remove redistribution in RTR2 to see what RTR1 does after this change.


From all the additional commands that you have provided RTR1 should advertise its own set of O E1 type 5 LSAs matching ACL 6.


Hope to help

Giuseppe

ju.mahieu Mon, 12/21/2009 - 09:23
User Badges:

Hi,


It is a production environment but I have already made the following test:


I have suppressed one of the static route on RTR2 and miracle !!!  in the routers Ospf database the RTR1 LSA for this routes is appeared.


Regards,


Ju

sherryliu2002 Mon, 12/21/2009 - 18:59
User Badges:

I just do a test, and receive the same result just like you

First, I try to delete the static routes on R2, when I look at R1, the adv-router is changed to R1.

Then I recovery the static routes on R2, the adv-router is switched.

I try to change DC/BDC states on both routers to resolve the mystery, but fail.

Now, I wonder too......

ju.mahieu Tue, 12/22/2009 - 01:05
User Badges:

Hi Liu,


Great, I m not alone in this curious world


I hope anyone will explain this behaviour ...


Thanks

Peter Paluch Tue, 12/22/2009 - 03:04
User Badges:
  • Cisco Employee,

Hello Julien,


You have a curious problem indeed. I have made a simple experiment myself - three 2691 routers connected in a row using Serial interfaces, R1, R2, and R3, all running OSPF in Area 0. The R1 and R3 had an identical static route in their routing tables and both of them have redistributed it into OSPF using the same metric type and metric as you are using. Unfortunately, for me, it worked flawlessly - both routers have originated their own LSA5 regarding this route and on all three routers, both LSA5 were present.


It might be that you have stumbled across a bug in the IOS XE on your ASR1000. It is a relatively new version of operating system for Cisco routers and I suspect there may be bugs like these present. Do you have a TAC contract with Cisco so you can have them have a closer look on what is happening?


Best regards,

Peter

ju.mahieu Tue, 12/22/2009 - 03:27
User Badges:

Hi Peter,


Thanks for your test and I took note of your advice to contact Cisco Tac.

I can't open directly a case to us but I am going to forward my problem to my Cisco supplier, which can contact the Tac.


Regards,

Peter Paluch Tue, 12/22/2009 - 03:42
User Badges:
  • Cisco Employee,

Hello Julien,


Very well. Please keep us informed if you learn anything new about your issue. Thank you!


Best regards,

Peter

Giuseppe Larosa Tue, 12/22/2009 - 04:14
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Peter,

in your test that gives a familiar / expected result, what is the forwarding address in the type 5 LSA, 0.0.0.0 or that of the ip next-hop of the static route being redistributed?


I wonder if a possible explanation could be this: seeing a non-zero Forwarding address that is advertised in area 1 by suppressing one LSA for recursion RTR3 could still be able to load balance towards external destination by routing to the Forwarding Address.


http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080124c7d.shtml


From Julien's tests we see that RTR1 is suppressing its own LSA until RTR2's LSA is not removed. This makes me to think that RTR1 may consider RTR2's LSAs better then the locally generated for example for RTR2's higher OSPF Router-id.


Of course, it may probably be a bug of IOS XE as you have noted.

Because it is contrary to normal experience.


Hope to help

Giuseppe

Peter Paluch Tue, 12/22/2009 - 06:16
User Badges:
  • Cisco Employee,

Hello Giuseppe,


In my experiment, I have redistributed a single static route that was created using a Null0 interface only - ip route 192.0.2.0 255.255.255.0 Null0. The output on the R2 (the router in the middle) is as follows:


R2#show ip ospf database external

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

          Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 946
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 192.0.2.0 (External Network Number )
  Advertising Router: 10.255.255.1
  LS Seq Number: 80000006
  Checksum: 0xB5A2
  Length: 36
  Network Mask: /24
     Metric Type: 1 (Comparable directly to link state metric)
     TOS: 0
     Metric: 10
     Forward Address: 0.0.0.0
     External Route Tag: 0

  Routing Bit Set on this LSA
  LS age: 1365
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 192.0.2.0 (External Network Number )
  Advertising Router: 10.255.255.3
  LS Seq Number: 80000006
  Checksum: 0xA9AC
  Length: 36
  Network Mask: /24
     Metric Type: 1 (Comparable directly to link state metric)
     TOS: 0
     Metric: 10
     Forward Address: 0.0.0.0
     External Route Tag: 0


You are correct, the Forward Address here is 0.0.0.0.


You have a good point and the article you have referenced is worth reading indeed. What is different in Julien's case is that one of his routers actually totally suppresses generating its own LSA. I think it is strange for a router to suppress generating its own LSA5 - I am not saying that it is not possible, it is just that I have not came across such situation yet.


Perhaps it would be helpful to see the output of the command debug ip ospf lsa-generation on Julien's routers when removing and replacing the static route in one of the router's routing tables.


Best regards,

Peter

ju.mahieu Tue, 12/22/2009 - 09:46
User Badges:

Thanks all for your replies,


I 'm currently in Christmas holidays and I can't access to my devices for five days.


I'll keep you posted when I come back to work.


Regards,


Ju

Correct Answer
marikakis Tue, 12/22/2009 - 10:29
User Badges:
  • Gold, 750 points or more

Hi all,


I think Giuseppe pointed to the correct direction. I think your case is described in RFC2328 (Section 12.4.4.1.  Examples of AS-external-LSAs):

"In figure 16, suppose instead that both RTA and RTB exchange BGP information with RTX.  In this case, RTA and RTB would originate the same set of AS-external-LSAs.  These LSAs, if they specify the same metric, would be functionally equivalent since they would specify the same destination and forwarding address (RTX).  This leads to a clear duplication of effort.  If only one of RTA or RTB originated the set of AS-external-LSAs, the routing would remain the same, and the size of the link state database would decrease.  However, it must be unambiguously defined as to which router originates the LSAs (otherwise neither may, or the identity of the originator may oscillate).  The following rule is thereby established: if two routers, both reachable from one another, originate functionally equivalent AS-external-LSAs (i.e., same destination, cost and non-zero forwarding address), then the LSA originated by the router having the highest OSPF Router ID is used.  The router having the lower OSPF Router ID can then flush its LSA. Flushing an LSA is discussed in Section 14.1."


Kind Regards,

Maria

Peter Paluch Tue, 12/22/2009 - 11:33
User Badges:
  • Cisco Employee,

Hello Maria,


Hats off! It seems that this could perfectly account for the behavior that Julien experienced. Thank you VERY much for highlighting it!


Best regards,

Peter

ju.mahieu Tue, 12/22/2009 - 11:58
User Badges:

Hi Maria,


Thank you so much for your post. It perfectly explain my issue


Regards,


Ju

Giuseppe Larosa Tue, 12/22/2009 - 12:11
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Maria; Julien, Peter,


a lesson for all: we need to go back to RFCs to find explanations for standard based protocols.

Maria is very good on this.

Actually, the duplicated set of external LSAs is not needed thanks to recursion on the forwarding address


I think that in most cases when we see two sets of LSAs is because if FA = 0.0.0.0 this suppression is not triggered.


Hope to help

Giuseppe

marikakis Tue, 12/22/2009 - 12:33
User Badges:
  • Gold, 750 points or more

Hi all,


Thank you for your kind remarks. Once upon a time I had to write code for specific IEEE 802.1q stuff. I don't know if you ever had the pleasure to read IEEE documents, but they look awful (I mean, what were those guys thinking when they wrote them? had they encrypted the documents, it would be easier to read, anyway). If anyone is interested in reading standards, but feels somewhat discouraged by their length, language or structure, I have a tip. A big problem with standards is that information about a specific feature is spread all over the document and you don't have the time to read it front to cover. So basically what I usually do is to search within the document for specific keywords. In this case, the keyword was 'forwarding'. In general, you may come across some irrelevant stuff or need to re-iterate with other keywords, but this works for me. And of course it is better to read some cisco documents first (if they exist) to familiarize with the basics, before going to standards. Cisco documents are good in this respect because they were written for humans and not some decryption engine.


Kind Regards,

Maria

sherryliu2002 Tue, 12/22/2009 - 19:44
User Badges:

RFC!!! It needs a long long time to read them.

Thanks for all replies!

Actions

This Discussion