From: Steven Weber (itweber@xxxxxxxxxxxxx)
Date: Mon Feb 11 2002 - 15:59:58 GMT-3
Guy,
I'm not exactly sure what you are asking but OSPF and RIP are both using
different masks. Doyle says that the way to fix this (739 #2) is by using a
static route of the interface with the RIP mask on the redistributing router
so that RIP thinks that these subnets are directly connected, but I can't
seem to get that working
Steve
----- Original Message -----
From: "Lupi, Guy" <Guy.Lupi@eurekaggn.com>
To: "'Steven Weber'" <itweber@earthlink.net>; <ccielab@groupstudy.com>
Sent: Monday, February 11, 2002 1:48 PM
Subject: RE: RIP and Loopbacks in OSPF.......
> They only need the mask native in RIP if they are in the same classful
> network as the interface over which they are to be broadcast, is that what
> you are seeing, that different masks in the same classful networks are
seen
> by RIP? If not this is the proper behavior, RIP can handle /32's.
>
> ~-----Original Message-----
> ~From: Steven Weber [mailto:itweber@earthlink.net]
> ~Sent: Monday, February 11, 2002 12:55 PM
> ~To: ccielab@groupstudy.com
> ~Subject: RIP and Loopbacks in OSPF.......
> ~
> ~
> ~I made an interesting observation, I wanted to know if other people are
> ~experiencing the same thing, and the logic behind it. When
> ~redistributing
> ~between OPSF and RIP I noticed that the loopbacks in OSPF
> ~don't need to be
> ~summarized in order for RIP to see them. OSPF advertises a
> ~loopback as a /32
> ~by default and RIP has no problem with this. However, once I
> ~add the ip ospf
> ~network point-to-point command on the loopbacks thereby
> ~changing them from a
> ~/32 to their true mask, once again RIP cannot see them unless
> ~there is some
> ~sort of summarization or default route in place. I don't
> ~understand why RIP
> ~sees these routes as a /32, shouldn't they need the mask
> ~native to RIP in
> ~order to be seen in RIP ?
> ~
> ~Does anyone have insight on this one?
> ~
> ~Regards,
> ~
> ~Steve
This archive was generated by hypermail 2.1.4 : Thu Jun 20 2002 - 13:46:19 GMT-3