From: Larry Roberts (groupstudy@american-hero.com)
Date: Fri Jun 24 2005 - 01:48:56 GMT-3
I will provide a follow-up for those following along at home.
I was able to get the forwarding behavior to be observed by changing the
Ethernet network type to point-to-multipoint.
The document listens the conditions required to have the forwarding
address set to a non-zero address.
OSPF is enabled on the ASBR's next hop interface AND
ASBR's next hop interface is non-passive under OSPF AND
ASBR's next hop interface is not point-to-point AND
ASBR's next hop interface is not point-to-multipoint AND
ASBR's next hop interface address falls under the network range
specified in the router ospf command.
I'm guessing that the behavior that was changed in 12.1(3) is the
removal of the final condition.
It was definitely an exercise worth doing though.
Larry Roberts wrote:
> 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
>
>
> _______________________________________________________________________
> 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:43 GMT-3