I'm running 6.19 on an RB/1200 at a tower (let's call it site Omega) several hops away from our main tower (let's call it site Alpha) where our internet connection comes in. Last week we had a new internet line installed at site Omega to provide redundancy for the network and to provide more speed, and a closer internet connection for other towers around site Omega so they wouldn't have to route all the way through the network to site Alpha's internet connection. After setting up the RB/1200 for the new internet connection I noticed something weird on the network. Clients all across the network (even one's close to site Alpha where they should be getting their internet connection) will route across the network to site Omega for any public IP starting with 50.X.X.X, but will route any other internet traffic to site Alpha. I checked the routes and all my towers have a RIP entry in them that shouldn't be there, 50.0.0.0/8. I traced this entry all the way to the RB/1200 at site Omega, but the entry isn't actually in the RB/1200 there. The next RB/1200 at the next tower has the 50.0.0.0/8 RIP entry and it said it got it from the RB/1200 at site Omega. Sooooo it has basically come out of thin air... The funny thing is that if I disable the public IPs or the ethernet interface that the internet connection comes in on at site Omega's RB/1200 then the RIP entry removes itself from the rest of the towers. The public IP addresses that we were given for our internet line actually do begin with 50. They are a block of 13 IP addresses and I have entered them in site Omega's RB/1200 as 50.X.X.X/28. I have searched all over my config for any reference to a class A block beginning with 50 and can't find anything. Does anyone have any idea how this RIP entry could be propagating across my network? Is the new cable modem somehow injecting a RIP entry into my RB/1200? I don't have it as a neighbor in my RIP config and have even tried blocking RIP (UDP 520) on the interface the cable modem is plugged in on.

I'm starting to think this is a bug, but would like some help confirming it before I report it.

Ok after some further testing this seems to be a bug. Mind you I've only tested this for about a half hour, so if someone could verify this I would appreciate it.

You can easily reproduce it on 6.19.

Try adding the folowing IP/netmask combinations and you get some weird (an potentially network breaking) results:

Add 1.2.3.4/26 and you'll get RIP entries for 1.2.3.0/26 (which is expected) and 1.0.0.0/8 (which is completely crazy).
Add 1.2.3.4/27 and you'll get RIP entries for 1.2.3.0/27 (which is expected) and 1.0.0.0/8 (which is also completely crazy).
Add 1.2.3.4/28 and you'll get RIP entries for 1.2.3.0/28 (again, expected) and 1.0.0.0/8 (again, crazy).
1.2.3.4/29 and 1.2.3.4/30 are the same story.
1.2.3.4/25 gives a RIP entry of only 1.2.3.0/25, which is great.

So anything lower than half a class C is essentially broken.

I tested with 192.168.1.X and got some different results.

192.168.1.1/24 works and gives a RIP entry of 192.168.1.0/24
192.168.1.0/25 also works and gives a RIP entry of 192.168.1.0/25
192.168.1.0/26 also works and gives a RIP entry of 192.168.1.0/26
The netmasks 27-30 give a RIP entry of 192.168.1.0/24 which sometimes disappears after a few seconds and sometimes stays.

I didn't experiment with 172.16.X.X or 10.X.X.X as my network is built on 10.X.X.X and didn't want to risk poisoning my network with a bad 10-net entry as it would potentially make certain parts of my network unroutable.

I did add 1.2.3.4/29 to an RB/1100AHx2 running 5.22 to see what would happen and the route 1.2.3.0/29 didn't propagate at all to some routers, but it did on others as well as the bad 1.0.0.0/8 route. I got both routes on a 5.26 router as well as on 3.30 routers. The 6.19 routers didn't get either route. A 5.5 router got the 1.2.3.0/29 route as well as a 5.25 router. A 3.30 router didn't get either route like the 6.19 routers didn't and that is probably because it is behind the 6.19 routers and is getting its RIP from them. Something interesting to note; every router (mixture of 3.30, 5.6, & 5.26) behind a 5.25 router got both routes even though the 5.25 router only had the good route (1.2.3.0/29), bit it gave out 1.2.3.0/29 and 1.0.0.0/8. So perhaps this is a bug that started in 5.26.

This is all pretty confusing at this point, and I can't predict exactly how it behaves yet, but something is definitely wrong.

I just added an address of 1.2.3.4/29 at a v3.30 router at the edge of my network and it propagated to another 3.30 router directly connected to it just fine, and from that went to a 5.6 router fine and went through that to a 5.26 router and ended up with RIP entries of 1.2.3.0/29 and 1.0.0.0/8 on the 5.26 router. It also went through that second 3.30 router to a 5.25 router fine (which only got 1.2.3.0/29) and from that 5.25 router to a 5.22 router which got 1.0.0.0/8 and 1.2.3.0/29. From there on all my routers have both the good and bad route no matter what version they are running. So I think this is either a bug starting in 5.6 and up or 5.25 and up.

Sounds almost like you've got some RIPv1 happening somewhere

Is that typical behavior for RIPv1? If so then I don't see how RIP ever even made it to v1 with behavior like that. That seems like behavior for RIPv0.1 alpha 1 haha.

I can try forcing all routers running RIP to v2, but as I said in a previous post, RIP works fine between ROS 3.30 routers that I have tested and breaks between ROS devices running some version of ROSv5 and up. RIP even behaved improperly between 2 routers running ROS v6.19. Try it yourself. Add an IP of 1.2.3.4/28 and watch it propagate through RIP as 2 different entries, 1.2.3.0/28 and 1.0.0.0/8. Mind you, depending on your setup and where you add the IP this may break Internet traffic for any connections bound for a destination IP starting with 1.

I'm surprised no one has noticed this before. I'd figure it would be a conmon issue for people using an ROS device as their internet gateway with static IPs and running RIP. Then again, most people might not have 2 internet connections built into different locations of their network for redundancy. It probably went unnoticed since that RIP entry wouldn't have a negative effect in those instances where a network has a single internet connection because then there would be really only one path for Internet-bound network traffic to take.

RIPv1 has been around since the late eighties and was a Classful routing protocol and didn't carry subnet information in the updates, so Class A addresses will be /8, Class B will be /16 and Class C will be /24

Not surprised it hasn't been noticed if it is a bug as RIP is an outdated and rarely used protocol these days.

Just realized I forgot to update my post after I solved my issue, so no reply is necessary.

For anyone with a similar problem of RIP adding rogue routes for an entire class A then the solution would be to manually set your RIP version to v2 for all routers running ROS v5 or later. I guess at some point in v5 the default RIP version that ROS advertises is v1 exclusively unless you specify it as only v2.

Thanks mrphreak for putting me on the right track!