From: Geert Nijs (Geert.Nijs@simac.be)
Date: Fri Aug 22 2008 - 06:57:44 ART
Thanks Paul. That explains a lot !
So the LSA is not reflooded but only marked as "invalid", consequence: the route tag on the LSA is not updated also.
My problem is that on router 19.16.139.114, i am redistributing from BGP into OSPF with matching communities (ie. community 1:100 gets OSPF tag 100, 1:200 gets OSPF tag 200).
In BGP, i have changed my tags on some prefixes. However, the OSPF tags don't get updated !! On 19.16.139.114, i can see the BGP route with community 1:200, yet in OSPF
the damned route is still in the OSPF database with tag 100. Apparently, Cisco doesn't consider a "community change" as a "BGP route change" and doesn't re-redistribute or refresh into OSPF.
Additional problem is that i don't have "clear" permissions on this 19.16.139.114 router, so my only option was to bounce the OSPF interface on the other side. Yet, mysteriously, that didn't help also (the point of my posting). So now i am stuck: the only way to update my tags is to get "clear" access on the 19.16.139.114 router and clear the ospf process. I need the tags to update, because some downstream OSPF routers have matching route-maps on these tags.
Unless there is maybe another advanced option that i am overlooking.......
(i know, yes, i should not redistribute into OSPF and extend my BGP session to the downstream destination router. This way i transport the BGP routes (with up to date communities) to the downstream destination router. However - the destination router is also running BGP and i don't want to link both BGP domains (they are from different providers :-) so they can see each other's AS numbers.
Interesting stuff that i am stuck with, no ;-)
regards,
Geert
CCIE #13729
________________________________
From: Fahad Khan [fahad.khan@gmail.com]
Sent: 22 August 2008 08:44
To: Paul Cosgrove
Cc: Geert Nijs; ccielab@groupstudy.com
Subject: Re: OSPF neighbor down, yet OSPF database is not updated/refreshed ?
Thank you paul, Your got the scenario exactly.I got ur point. If I am not wrong this MAXAGE is 3600 sec. Because after this time interval, the LSA was no loger seen. can I modify this max age?can u elaborate the use of this command "timer lsa-group-pacing <sec>" (run in router mode)?
Thanks alot.
On 8/21/08, Paul Cosgrove <paul.cosgrove@heanet.ie<mailto:paul.cosgrove@heanet.ie>> wrote:
Hi Geert,
There is a difference in behaviour when a change in a transit link is
detected, from when a link is specifically invalidated by a
connected/advertising router.
A router can only MAXAGE its own LSAs, not those it has learned. If you
had instead left the neighbor relationship in place, and shutdown
another interface (e.g. loopback) on the 19.16.139.114<http://19.16.139.114> router, the
advertising router would have sent out a new LSA with MAXAGE set. In
that case that route would quicky be removed from the ospf databases of
other routers.
In your case I understand you have instead dropped the connections
between the two routers. They perform an spf recalculation and
determine that they can no longer reach each other. Lets say they
normally each learn 99 routes from each other.
You can see from your output that when the neighbor relationship times
out, rather than clearing all the affected routes from their ospf
databases, they simply mark them as invalid (by removing the routing
bit) and leave them there until they hit maxage. Only the LSA for the
affected link is reflooded, as that will have changed state.
If the neighbor relationship is re-established before the other 99
routes hit maxage, and before they need to be reflooded (next 30 min
interval), the two routers can just exchange database sequence numbers
to synchronise rather than performing a full databases exchange. Only
the recovered link changes state, so only that needs to be reflooded.
This flooded LSA will trigger other routers in the area to run an spf
recalculation, based on which they will determine that the 99 dependent
routes are also reachable again.
I'm not sure I completely understand your scenario regarding the tags.
Do you want the route from both 19.16.139.113<http://19.16.139.113> and 19.16.139.114<http://19.16.139.114> to be
tagged with 401? Perhaps clearing the process on 19.16.139.114<http://19.16.139.114> may help?
Paul.
Geert Nijs wrote:
> If neighbor goes down, i would presume all LSA of that router become invalid - instantly - and OSPF should remove them from the database and to a recalculation.
>
> regards,
> Geert
> ________________________________
> From: Fahad Khan [fahad.khan@gmail.com<mailto:fahad.khan@gmail.com>]
> Sent: 21 August 2008 13:30
> To: Geert Nijs
> Cc: ccielab@groupstudy.com<mailto:ccielab@groupstudy.com>
> Subject: Re: OSPF neighbor down, yet OSPF database is not updated/refreshed ?
>
> For how long you found this behaviour? I mean to say that, may be after a certain period of time,you saw them out of database table. Database table contains LSAs only, may be this has some thing to do with LSA aging time.
>
> On 8/21/08, Geert Nijs <Geert.Nijs@simac.be<mailto:Geert.Nijs@simac.be><mailto:Geert.Nijs@simac.be<mailto:Geert.Nijs@simac.be>>> wrote:
> Hi all,
>
> I have strange stuff going on in my network. Yesterday, i bounced an interface (shut/no shut) to reset an OSPF neighborship.
> However, when the neighbor was down, it seemed OSPF didn't update its database. The routes were still in the OSPF database. I don't understand:
> The routes concerned are external redistributed routes:
>
> show ip ospf database
>
> Type-5 AS External Link States
> Link ID ADV Router Age Seq# Checksum Tag
> 10.50.0.0<http://10.50.0.0><http://10.50.0.0> 19.16.139.113<http://19.16.139.113><http://19.16.139.113> 1421 0x800001EE 0x00E290 401 <<<------------ look at these routes
> 10.50.0.0<http://10.50.0.0><http://10.50.0.0> 19.16.139.114<http://19.16.139.114><http://19.16.139.114> 1040 0x8000004D 0x001B2D 400
> 10.50.32.0<http://10.50.32.0><http://10.50.32.0> 19.16.139.113<http://19.16.139.113><http://19.16.139.113> 1421 0x800001EE 0x0081D1 401 <<<------------ look at thse routes
> 10.50.32.0<http://10.50.32.0><http://10.50.32.0> 19.16.139.114<http://19.16.139.114><http://19.16.139.114> 1040 0x8000004D 0x00B96E 400
>
> sh ip ospf neighbor
> 19.16.139.113<http://19.16.139.113><http://19.16.139.113> 1 FULL/BDR 00:00:19 10.63.14.1<http://10.63.14.1><http://10.63.14.1> Vlan997
>
> Then i disable the interface:
> %OSPF-5-ADJCHG: Process 1, Nbr 19.16.139.113<http://19.16.139.113><http://19.16.139.113> on Vlan997 from FULL to DOWN, Neighbor Down: Dead timer expired
>
> sh ip ospf database
> 10.50.0.0<http://10.50.0.0><http://10.50.0.0> 19.16.139.113<http://19.16.139.113><http://19.16.139.113> 1725 0x800001EE 0x00E290 401 <<<-- STILL HERE ???
> 10.50.0.0<http://10.50.0.0><http://10.50.0.0> 19.16.139.114<http://19.16.139.114><http://19.16.139.114> 1344 0x8000004D 0x001B2D 400
> 10.50.32.0<http://10.50.32.0><http://10.50.32.0> 19.16.139.113<http://19.16.139.113><http://19.16.139.113> 1725 0x800001EE 0x0081D1 401 <<<-- STILL HERE ???
> 10.50.32.0<http://10.50.32.0><http://10.50.32.0> 19.16.139.114<http://19.16.139.114><http://19.16.139.114> 1344 0x8000004D 0x00B96E 400
>
> ping 19.16.139.113<http://19.16.139.113><http://19.16.139.113>
> ..... <<-- he is down for sure
>
> Why doesn't the database get updated ? I need the route to be removed and re-inserted/refreshed with an up-to-date tag.
>
> regards,
> Geert
> CCIE #13729
>
>
>
> Details when neighbor is UP:
>
>
> # sh ip ospf database external 10.50.0.0<http://10.50.0.0><http://10.50.0.0>
> OSPF Router with ID (192.168.1.1<http://192.168.1.1><http://192.168.1.1>) (Process ID 1)
>
> Type-5 AS External Link States
> LS age: 1897
> Options: (No TOS-capability, DC)
> LS Type: AS External Link
> Link State ID: 10.50.0.0<http://10.50.0.0><http://10.50.0.0> (External Network Number )
> Advertising Router: 19.16.139.113<http://19.16.139.113><http://19.16.139.113> <---- this is it
> LS Seq Number: 800001EE
> Checksum: 0xE290
> Length: 36
> Network Mask: /19
> Metric Type: 2 (Larger than any link state path)
> TOS: 0
> Metric: 60
> Forward Address: 0.0.0.0<http://0.0.0.0><http://0.0.0.0>
> External Route Tag: 401
>
> Routing Bit Set on this LSA <--- what does this mean ? this is the redundant path route and currently the preferred one. Is there no refresh when "routing bit" not set ?
> LS age: 1516
> Options: (No TOS-capability, DC)
> LS Type: AS External Link
> Link State ID: 10.50.0.0<http://10.50.0.0><http://10.50.0.0> (External Network Number )
> Advertising Router: 19.16.139.114<http://19.16.139.114><http://19.16.139.114> <---redundant path, currently selected (see cost)
> LS Seq Number: 8000004D
> Checksum: 0x1B2D
> Length: 36
> Network Mask: /19
> Metric Type: 2 (Larger than any link state path)
> TOS: 0
> Metric: 10
> Forward Address: 0.0.0.0<http://0.0.0.0><http://0.0.0.0>
> External Route Tag: 400 <<<--- i want this tag to update !!
>
>
> Details when neighbor is DOWN:
>
> # sh ip ospf database external 10.50.0.0<http://10.50.0.0><http://10.50.0.0>
> OSPF Router with ID (192.168.1.1<http://192.168.1.1><http://192.168.1.1>) (Process ID 1)
>
> Type-5 AS External Link States
> LS age: 1984
> Options: (No TOS-capability, DC)
> LS Type: AS External Link
> Link State ID: 10.50.0.0<http://10.50.0.0><http://10.50.0.0> (External Network Number )
> Advertising Router: 19.16.139.113<http://19.16.139.113><http://19.16.139.113> <-------- STILL HERE !
> LS Seq Number: 800001EE
> Checksum: 0xE290
> Length: 36
> Network Mask: /19
> Metric Type: 2 (Larger than any link state path)
> TOS: 0
> Metric: 60
> Forward Address: 0.0.0.0<http://0.0.0.0><http://0.0.0.0>
> External Route Tag: 401
>
> Routing Bit Set on this LSA
> LS age: 1603
> Options: (No TOS-capability, DC)
> LS Type: AS External Link
> Link State ID: 10.50.0.0<http://10.50.0.0><http://10.50.0.0> (External Network Number )
> Advertising Router: 19.16.139.114<http://19.16.139.114><http://19.16.139.114>
> LS Seq Number: 8000004D
> Checksum: 0x1B2D
> Length: 36
> Network Mask: /19
> Metric Type: 2 (Larger than any link state path)
> TOS: 0
> Metric: 10
> Forward Address: 0.0.0.0<http://0.0.0.0><http://0.0.0.0>
> External Route Tag: 400
>
>
>
> ________________________________
> disclaimer : http://webservices.simac.be/disclaimer.htm
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>
>
>
> --
> FAHAD KHAN
>
> BE Computer Systems NED,
>
> CCNA,CCDA,CCNP,FOUNDFE,CLSE,QOS,JNCIA,JNCIS,MCP,CCIE (Written)
>
> Systems Support Engineer, Premier Systems (Pvt) limited,
>
> Karachi, Pakistan
>
> 92-321-2370510.
>
> ________________________________
> disclaimer : http://webservices.simac.be/disclaimer.htm
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>
-- HEAnet Limited Ireland's Education & Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301Please consider the environment before printing this e-mail.
-- FAHAD KHAN
BE Computer Systems NED,
CCNA,CCDA,CCNP,FOUNDFE,CLSE,QOS,JNCIA,JNCIS,MCP,CCIE (Written)
Systems Support Engineer, Premier Systems (Pvt) limited,
Karachi, Pakistan
92-321-2370510.
________________________________ disclaimer : http://webservices.simac.be/disclaimer.htm
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Mon Sep 01 2008 - 08:15:31 ART