From: Anthony Sequeira (terry.francona@gmail.com)
Date: Thu Jun 23 2005 - 17:02:25 GMT-3
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
This archive was generated by hypermail 2.1.4 : Wed Jul 06 2005 - 14:43:42 GMT-3