interesting points, Andrew. makes sense. following are some of the lines
from the show ip protocol:
R8:
Routing for Networks:
132.31.0.0
161.52.0.0
201.0.0.0
and R7:
Routing for Networks:
132.31.0.0
173.4.0.0
181.48.0.0
200.0.0.0
and the config entry:
router rip
version 2
redistribute connected metric 5
network 132.31.0.0
network 161.52.0.0
network 201.0.0.0
no auto-summary
while the network statement in CIDR form is accepted, still something
doesn't work.
note the existence of the two CIDR blocks 200.0.0.0 /8 and 201.0.0.0/8 since
a show ip route yields the proper mask on the interface:
C 201.0.0.0/15 is directly connected, Loopback101
C 96.0.0.0/4 is directly connected, Loopback1003
C 203.0.0.0/8 is directly connected, Loopback1001
C 129.0.0.0/12 is directly connected, Loopback1002
then the "problem" has to occur within the RIP process itself, and the
manner in which the subnet mask is extracted. OSPF appears to take the
information from the interface configuration. BGP uses the manually
configured network/mask statement. I did not test this, but when I have used
EIGRP in the past, I used the new notation available in 12.1 that allows
network x.x.x.x y.y.y.y a la OSPF
So good call - looks like you nailed it.
Chuck
""Andrew Cook"" wrote in message
news:[EMAIL PROTECTED].;
> I duplicated this effect. It seems the whole problem lies with RIP
network
> statements. Although RIPv2 itself can carry classless info, the network
> statement to turn RIP on for an interface is classful. Until Cisco allows
> the inclusion of netmask info in the network statement as they do for
other
> routing protocols, I would guess that redistribution is the only way to
make
> this work - and I'd wager that they aren't really devoting a lot of
> development time to RIP anymore!
> Incidentally, I created a supernet on a loopback with a /22 and then tried
> putting all 4 class Cs into RIP as networks to see if that would magically
> fix it - it did not.
> Can anyone confirm RIPv2 operation on other vendor equipment? Does anyone
> allow a CIDR netblock as a native RIP interface without redistribution?
>
> PS - as to the need for RIPv2 on a modern network, I am still forced to
use
> it in many cases for MPLS/VPN. The only routing choices to a CE router
are
> static, RIPv2, BGP, and OSPF. OSPF is limited because each instance uses
up
> one protocol descriptor block (PDB), of which you can only have 32.
Static
> is easy for small customers, but larger ones will almost certainly require
> dynamic routing. That leaves us the choice of BGP or RIPv2. It all
depends
> on whether the end user is comfortable using BGP. Almost everyone has set
> up RIP before, so it seems to be the catchall.
>
> Andrew Cook
>
> ""Chuck"" wrote in message
> news:[EMAIL PROTECTED].;
> > well, to continue to beat this dead horse ( like anyone cares about
RIPv2
> > CIDR anyway )
> >
> > Gateway of last resort is not set
> >
> > 172.17.0.0/24 is subnetted, 1 subnets
> > C 172.17.1.0 is directly connected, TokenRing0
> > 173.4.0.0/24 is subnetted, 1 subnets
> > C 173.4.57.0 is directly connected, Loopback0
> > 161.52.0.0/24 is subnetted, 1 subnets
> > R 161.52.1.0 [120/1] via 132.31.99.8, 00:00:24, Virtual-Access1
> > 132.31.0.0/16 is variably subnetted, 2 subnets, 2 masks
> > C 132.31.99.8/32 is directly connected, Virtual-Access1
> > C 132.31.99.0/24 is directly connected, Virtual-Access1
> > C 192.168.0.0/24 is directly connected, Serial0
> > C 192.168.1.0/24 is directly connected, Serial1
> > C 200.0.0.0/8 is directly connected, Loopback101
> > R 201.0.0.0/15 [120/5] via 132.31.99.8, 00:00:11, Virtual-Access1
> > R 96.0.0.0/4 [120/5] via 132.31.99.8, 00:00:00, Virtual-Access1
> > R 203.0.0.0/8 [120/5] via 132.31.99.8, 00:00:00, Virtual-Access1
> > R 129.0.0.0/12 [120/5] via 132.31.99.8, 00:00:00, Virtual-Access1
> > C 181.48.0.0/13 is directly connected, Loopback201
> > R7#
> >
> > note all the CIDR routes in the routing table, all learned via RIP.
> >
> > How?
> >
> > interface Loopback101
> > ip address 201.0.0.1 255.254.0.0
> > !
> > interface Loopback1001
> > ip address 203.0.0.1 255.0.0.0
> > !
> > interface Loopback1002
> > ip address 129.1.1.1 255.240.0.0
> > !
> > interface Loopback1003
> > ip address 100.1.1.1 240.0.0.0
> > !
> > router rip
> > version 2
> > redistribute connected metric 5
> > network 132.31.0.0
> > network 161.52.0.0
> > network 201.0.0.0
> > no auto-summary
> >
> > you apparently do have to redistribute the CIDR routes into RIPv2. Silly
> me.
> > Why wouldn't that be obvious?
> >
> > Chuck
> >
> >
> >
> > ""Chuck"" wrote in message
> > news:[EMAIL PROTECTED].;
> > > kinda in answer to your private message:
> > >
> > >
> >
>
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_c
> > > /ipcprt2/1cdrip.htm
> > > watch the wrap
> > >
> > > according to this, Cisco's implementation of Ripv2 does indeed support
> > CIDR
> > >
> > > On the other hand, getting this to work appears to be problematic. A
> check
> > > of Doyle shows no CIDR example for Ripv2 A look though Large Scale IP
> > > Network Solutions yields this interesting sentence: "RIPV2 is able to
> > > support classless interdomain routes. It can propagate a classless
route
> > > through redistribution"
> > >
> > > I can't get a damn CIDR route to show up in the RIPv2 table no matter
> how
> > > many hokey pokies I do.
> > >
> > > At this point I'm going to assume you have tried RipV2 and have had
the
> > same
> > > frustration I just had - seeing no CIDR routes. This calls for a bit
> more
> > > research.
> > >
> > > Chuck
> > >
> > >
> > > ""Chuck"" wrote in message
> > > news:[EMAIL PROTECTED].;
> > > > I think you're trying to outsmart yourself. Can't be done!!! ;->
> > > >
> > > > I showed you in my private reply the result of the EIGRP test I set
> up.
> > > The
> > > > answer was "no problem"
> > > >
> > > > I also know from long lab rat experience that it is not a problem
with
> > > OSPF.
> > > >
> > > > I have not tried with either IS-IS or Ripv2, but again, why not?
> > > >
> > > > there may be issues with older IOS code. Some vendor older models
may
> > not
> > > > support it. But I have no reason based on my experience, to believe
> that
> > > it
> > > > is an issue with current IOS code.
> > > >
> > > > Chuck
> > > >
> > > >
> > > >
> > > > ""Pierre-Alex Guanel"" wrote in message
> > > > news:[EMAIL PROTECTED].;
> > > > > The statement that provoked my question is from RFC 1721. They say
> > > > >
> > > > > "Subnet masks are also necessary for implementation of "classless"
> > > > > addressing, as the CIDR work proposes"
> > > > >
> > > > > thus the question "if a routing protocol supports subnet mask does
> > that
> > > > > automatically mean that it can do CIDR?
> > > > >
> > > > > ( I think the answer is no because CIDR means that you could have
> > masks
> > > > > stilling bits from the newtork ID and the router may not like this
> > ....
> > > I
> > > > > also think that historically subnetting and Variable Length subnet
> > > masking
> > > > > came before CIDR. But those are just speculations. I don't have
> > examples
> > > /
> > > > > references to support my arguments and I would like to know if I
am
> > > > correct.)
> > > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Pierre-Alex
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=37072&t=37031
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
