From: Popgeorgiev Nikolay (nikolay.popgeorgiev@siemens.com)
Date: Wed Feb 08 2006 - 07:33:18 GMT-3
Alex,
Yes you are right, cause I tried to shut the interface to SW1 and the forwarding address came in the routing table from the other way and it works, I saw that before,
But let's say the situation is like mine it is a circle of routers but I want to have it like a chain - meaning I don't want to enable ospf on the link between the last and the first. The solution is to receive the forwarding address from the same way from where you receive the LSAs but how to do this without shutting the interface I have no idea...
Best,
Nick
-----Original Message-----
From: alex [mailto:ecralar@hotmail.com]
Sent: Wednesday, February 08, 2006 12:18 PM
To: Popgeorgiev Nikolay; Chris Lewis
Cc: ccielab@groupstudy.com
Subject: Re: ospf again
I think Your problem relates to the fact that OSPF is not enabled on the
R3-SW1 subnet (if I remember correctly) therefore the forwarding address is
known to R3 via "connected" route.
This is not a valid situation, the forwarding address must be Type-1, Type-2
or Type-3 OSPF route. In case of directly connected forwarding address the
"network" statement should cover the whole subnet and not just interface
(e.g. "network 10.1.1.0 0.0.0.255" as opposed to "network 10.0.0.1
0.0.0.0"<===this will cause You problems just described).
HTH
Cheers
Alex
----- Original Message -----
From: "Popgeorgiev Nikolay" <nikolay.popgeorgiev@siemens.com>
To: "Chris Lewis" <chrlewiscsco@gmail.com>; "Popgeorgiev Nikolay"
<nikolay.popgeorgiev@siemens.com>
Cc: <ccielab@groupstudy.com>
Sent: Wednesday, February 08, 2006 7:38 AM
Subject: RE: ospf again
> Chris,
>
> Actually we are talking about N2 routes no inter or intra area routes. The
> case is simple and I don;t think there is something else. I think there is
> a special rule for my case but I cannot find it.
>
> If you have time and will try it.
>
>
>
> best,
>
> Nick
>
>
>
>
>
> _____
>
> From: Chris Lewis [mailto:chrlewiscsco@gmail.com]
> Sent: Tuesday, February 07, 2006 4:11 PM
> To: Popgeorgiev Nikolay
> Cc: ccielab@groupstudy.com
> Subject: Re: ospf again
>
>
> The state of forward address only relates to external routes, not inter
> area routes. For an external LSA to be inserted in to the routing table,
> the forward address needs to be 0.0.0.0 <http://0.0.0.0> or known via an
> inter or intra area route. As this is NSSA, the discussion of external
> routes is moot anyway.
>
> It reads like you have some other configuration problems.
>
> Try a look at http://www.cisco.com/warp/public/104/trouble_main.html
> <http://www.cisco.com/warp/public/104/trouble_main.html>
>
> Chris
>
> On 2/7/06, Popgeorgiev Nikolay <nikolay.popgeorgiev@siemens.com
> <mailto:nikolay.popgeorgiev@siemens.com> > wrote:
>
> Hello people,
>
> I asked a question about a problem with ospf and nssa but maybe I didn't
> explain it the best way so nobody respond.
>
> It is a question why no matter that a LSA is in the database of ospf it
> sometimes is not installed in the routiing table. I have a case where a
> router(B) in nssa is receiving a lsa about a network(loopback address)in
> area 0 but is not installing it in the routing table. The question is why.
>
> After some investigation I came to the conclusion that the reason for this
> is that the Forward address: of the lsa is directly connected to my router
> B.
>
> When I shut the interface of B to this Forwarding Address the LSA is
> installed in the routing table.
>
> So is there some rule saying something about how the receiving router is
> reaching the Forwarding address of the lsa ?
>
> thanks
>
> Nick
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
> <http://www.groupstudy.com/list/CCIELab.html>
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Wed Mar 01 2006 - 11:28:17 GMT-3