From: Larry Roberts (groupstudy@american-hero.com)
Date: Thu Jun 23 2005 - 17:22:09 GMT-3
From what I read in that document, the statement below refers to a
situation when you redistributed connected routes, and also advertised
them via a network statement.
Doing so would generate both an LSA type (1) and a type 5.
after 12.1(3) they no longer advertise the duplicate type 5 LSA.
I'm going to re-read that document again however as my solution may
still be there.
If nothing else I'm learning a great deal more about OSPF which I guess
is the end goal.
Anthony Sequeira wrote:
>Here is a link that was provided during a COD by the geniuses at
>InternetworkExpert regarding this matter:
>
>http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009405a.shtml
>
>I read this far in the document "The problem explained in this
>document is only observable with Cisco IOS(r) Software releases earlier
>than 12.1(3)" and I immediately decided to put this one on the "back
>burner".
>
>No one has shown me compelling evidence yet to not use the all 0's
>mask when I am configuring OSPF in the lab.
>
>On 6/23/05, Larry Roberts <groupstudy@american-hero.com> wrote:
>
>
>>I have been trying to research this topic to observe the behavior, but
>>for the life of me I can't get the forwarding address to be zero's.
>>
>>I have tried 2 different IOS trains, and 2 different routing protocols
>>(RIP and ISIS).
>>My routes redistributed from OSPF into another protocol all show up with
>>the redis point being the next hop.
>>However I am completely unable to get my E2 routes to have a forwarding
>>address of zero's.
>>
>>I just finished reading the relevant parts of the OSPF v2 RFC and It
>>*should* work. But I just cant get it to work.
>>
>>There was another thread on this titled " /32 vs /24 for loopback and
>>OSPF" in which a link to a netmaster document titled "Forwarding
>>behavior of IGP Routing Protocols on a Broadcast Subnet Part one" was
>>given. I have even cut and paste the configuration and it doesn't work.
>>
>>Somebody tell me I'm not going crazy here..
>>
>>
>>
>>ccie2be wrote:
>>
>>
>>
>>>Hi guys,
>>>
>>>I learned the answer to this fairly obscure feature just a couple weeks ago.
>>>
>>>Here's the reason. Suppose this is your topology:
>>>
>>> r1
>>>|------------------|-----------------|
>>> | |
>>> r2 r3
>>> isis ospf
>>>
>>>
>>>
>>>r1 is redist between isis and ospf. If you want the next hop of routes that
>>>r3 learns from r2 indirectly via r1 to be r2, then don't use a wildcard mask
>>>of 0.0.0.0 on R1's interface to the common segment. If you do, then packets
>>>
>>>
>>>from r3 going to r2 or beyond will make a pit stop at r1. This is obviously
>>
>>
>>>inefficient, so in such a scenario, it's better and more efficient to use a
>>>wildcard mask on r1 that isn't 0.0.0.0
>>>
>>>If you have a chance, try to lab it up and see for yourself.
>>>
>>>HTH, Tim
>>>
>>>
>>>
>>>-----Original Message-----
>>>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>>>Anthony Sequeira
>>>Sent: Wednesday, May 18, 2005 11:13 AM
>>>To: Dennis J. Hartmann
>>>Cc: ccielab@groupstudy.com
>>>Subject: Re: OSPF 0.0.0.0 wildcard (inverse) mask
>>>
>>>I would love to hear the reasoning behind this - for the Practical Lab
>>>- I plan on using the 0.0.0.0 wildcasrd mask exclusively unless I am
>>>told to do otherwise!
>>>
>>>On 5/18/05, Dennis J. Hartmann <dennisjhartmann@hotmail.com> wrote:
>>>
>>>
>>>
>>>
>>>> Someone E-Mailed me a white paper on why you should never use 0.0.0.0
>>>>
>>>>
>>>>
>>>>
>>>as
>>>
>>>
>>>
>>>
>>>>a wildcard mask a while ago. I have misplaced it and I have a friend
>>>>interested in taking a look at it. If anyone has this .pdf or a link to
>>>>
>>>>
>>>>
>>>>
>>>the
>>>
>>>
>>>
>>>
>>>>explanation on cisco.com, can you please send it? Thanks.
>>>>
>>>>Sincerely,
>>>>
>>>>Dennis J. Hartmann
>>>>
>>>>White Pine Communications
>>>>
>>>>dh8@pobox.com
>>>>
>>>>CCSI#23402/CCIP/CCNP/CCDP/CCNA/CCDA
>>>>
>>>>Cisco IP Voice Support & Design Specialist
>>>>
>>>>Cisco Optical, VPN & IDS Specialist
>>>>
>>>>MCSE
>>>>
>>>>_______________________________________________________________________
>>>>Subscription information may be found at:
>>>>http://www.groupstudy.com/list/CCIELab.html
>>>>
>>>>
>>>>
>>>>
>>>_______________________________________________________________________
>>>Subscription information may be found at:
>>>http://www.groupstudy.com/list/CCIELab.html
>>>
>>>_______________________________________________________________________
>>>Subscription information may be found at:
>>>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 Jul 06 2005 - 14:43:42 GMT-3