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=37062&t=37031 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
