From: Nick Shah (nshah@connect.com.au)
Date: Wed Sep 04 2002 - 20:27:41 GMT-3
Chris
I couldnt devote more time yest. to get to the bottom of this. But the only
change that I made to your config was to make the 'loopback0' to belong to
the NSSA area.
Rest all remains the same, so all other interfaces are still 'redistribute
connected' into this area.
rgds
Nikc
----- Original Message -----
From: "Larson, Chris" <CLarson@usaid.gov>
To: "'Nigel Taylor'" <nigel_taylor@hotmail.com>; "Khalid Siddiq"
<khalid@sys.net.pk>; <ccielab@groupstudy.com>
Sent: Wednesday, September 04, 2002 10:08 PM
Subject: RE: NSSA and type 7 LSA's -same problem. Configs incl.
> I understand that Nick got the p-bit set by adding the interfaces into the
> NSSA area (area 3), but if I do that then there really isn't a need to be
> NSSA and I could simply go stub, right?? The requirements of the lab do
not
> allow me to put the interface into the area, only to redistribute it. I am
> going to lab it back up and play a little more to try and get to the
bottom
> of it. Any other insight would be great.
>
>
>
> I appreciate the help!!
>
>
>
>
>
> -----Original Message-----
> From: Nigel Taylor [mailto:nigel_taylor@hotmail.com]
> Sent: Wednesday, September 04, 2002 5:24 AM
> To: Khalid Siddiq; ccielab@groupstudy.com
> Subject: Re: NSSA and type 7 LSA's -same problem. Configs incl.
>
>
> Khalid,
> The ASBR in question is connected to a single area as noted
by
> the config paste by the original poster. As you pointed out the problem
is
> trying to determine why R1 is clearing the P-bit which is the original
> question, which was asked by Peter.
>
> Just after making my post, Nick Shah, posted the result of some quick
> testing in which case the redistribution of the connected interface into
the
> OSPF process did not provide/meet the necessary for the P-bit being set
and
> until he made the connected interface part of the NSSA the type 7's was
not
> translated into type 5's
>
> AS noted in my post Alex Zinin's rationale does seem to provide some
insight
> into the problem we're currently discussing and if anything gives us a
> reason for doing further reading on the topic.
>
> I simply love this list... :-)
>
> Nigel
>
> ----- Original Message -----
> From: "Khalid Siddiq" <khalid@sys.net.pk>
> To: "Nigel Taylor" <nigel_taylor@hotmail.com>; <ccielab@groupstudy.com>
> Sent: Wednesday, September 04, 2002 5:46 AM
> Subject: RE: NSSA and type 7 LSA's -same problem. Configs incl.
>
>
>
> There are two problems discussed; the previous problem is because of the
> fact that the ASBR is connected to two areas, i.e. 11 & 21. that's why it
is
> clearing the P bit.
>
> Second, problem where R1 is generation NSSA with p bit cleared is most
> likely be the case of a bug.
> regards,
> khalid
> -----Original Message-----
> From: Nigel Taylor [mailto:nigel_taylor@hotmail.com]
> Sent: Wednesday, September 04, 2002 9:19 AM
> To: ccielab@groupstudy.com
> Subject: Re: NSSA and type 7 LSA's -same problem. Configs incl.
>
>
> Chris,
> I think you're missing what Peter is trying to say. As you've
> noted(and Peter as well) in normal conditions the only time the P-bit is
> cleared is to eliminate the translation of type 7's from being translated
by
> other NSSA ABR's. However, as Peter point's out the problem here would be
> why is the ASBR clearing the P-bit. I looked around and came back to (as
> Howard pointed out) one of the best books on IP routing (next to Doyle's)
> Alex Zinin's - Cisco IP Routing.
>
> This is just a thought but if anyone cares to comment of the validity of
my
> understanding and or the possibility if these mechanisms applying across
the
> board with reference to NSSA LSA processing, please do so. Page 497,
> 9.2.5.3, Alex notes the use of the redistribute command on Cisco OSPF
router
> and the use of a special process called the OSPF scanner, which is
started.
> Reason for the scanner is to ensure synchronization of the routing table -
> specifically the redistributed routes - and self-originated
> AS-external-LSAs. I noted the redistribute command being used on R1 which
> caught my attention.
>
> He further notes that it's not enough that the ASBR to originate LSAs.
The
> remote router(s) must have corresponding entry in their RIBs to install
> external routes derived from AS-external-LSAs announced by a particular
> router. The most important thing her noted was as follows, "To ensure
that
> routers residing in the same area as the ASBR install such entries and
that
> ABR's properly announce the ASBR location in the ASBR-summary-LSAs, the
ASBR
> sets the E-bit in it's router LSA.
>
> Can you confirm the setting of the E-bit in the router LSAs? Also, the
> final paragraph provide some insight as to a number of thing we could look
> at in trying to identify the reasoning behind what you're observing.
>
> Thoughts...
> Nigel
>
> P.S. Folks add this books to your Intra-domain Routing Library. It
> provides an level of insight into so many other aspects of Cisco's
protocol
> implementation.
> (Disclaimer: I was not paid to make that comment... It's all Howard's
> fault. He mentioned the book in the list - I just was just crazy enough
to
> buy it :-) )
>
>
>
>
> ----- Original Message -----
> From: "Chris Larson" <clarson52@comcast.net>
> To: "Peter van Oene" <pvo@usermail.com>; "Khalid Siddiq"
> <khalid@sys.net.pk>; <ccielab@groupstudy.com>
> Sent: Tuesday, September 03, 2002 9:42 PM
> Subject: Re: NSSA and type 7 LSA's -same problem. Configs incl.
>
>
> > The only reason that I know that this would happen is if the router were
> > both ASBR and ABR and R2 is not. Also, an earlier post had mentioned
> > reacability. I have taken the config off for now, but I remeber that
> subnet
> > being an O route.
This archive was generated by hypermail 2.1.4 : Mon Oct 07 2002 - 07:43:44 GMT-3