RIP Trivia Question

NetworkVeteran

1. In this topology, when you shutdown loopback0 on R1, a routing loop is created between R1/R4/R5!

R1 sends IP Address: 10.0.0.0, Metric: 3
R4 sends IP Address: 10.0.0.0, Metric: 4
R1 sends IP Address: 10.0.0.0, Metric: 5
R4 sends IP Address: 10.0.0.0, Metric: 6
...

What configuration change(s) would prevent problems like this?

R1 Configuration
router rip
network 1.0.0.0
network 10.0.0.0
network 192.168.1.0
interface Loopback0
ip address 10.0.0.1 255.0.0.0
shutdown
interface Serial0/0
ip address 192.168.1.1 255.255.255.0
encapsulation frame-relay
clock rate 2000000

R5 Configuration
router rip
network 5.0.0.0
network 192.168.1.0
interface Loopback0
ip address 5.0.0.5 255.0.0.0
interface Serial0/0
ip address 192.168.1.5 255.255.255.0
encapsulation frame-relay
clock rate 2000000


R4 Configuration
router rip
network 4.0.0.0
network 192.168.1.0
interface Loopback0
ip address 4.0.0.4 255.0.0.0
interface Serial0/0
ip address 192.168.1.4 255.255.255.0
encapsulation frame-relay
clock rate 2000000

2. After fixing the above, you decide to enable authentication on the WAN. You add the following configuration to R1 only--

key chain REM
key 1
key-string GreatBeyond
interface s0/0
ip rip authentication key-chain REM

R1 continues to accept updates from R4 and R5, even though you have not configured matching authentication on them! What had you forgotten?

NotHackingYou

My guess - split horizon is not enabled for frame relay interfaces in RIP v1. Enabling split horizon and splitting r1 s0/0 to subinterfaces.

NetworkVeteran

My guess - split horizon is not enabled for frame relay interfaces in RIP v1

Correct! Split horizon is disabled by default on serial interfaces for RIPv1 and RIPv2.

Enabling split horizon and splitting r1 s0/0 to subinterfaces.

While that would indeed work, is there a solution that only involves tweaking the RIP configuration, and doesn't require modifying the existing topology or addressing scheme?

And what of the authentication dilemma?

NotHackingYou

no auto summary.

Authentication you would need to bounce the interfaces

NetworkVeteran

CarlSaiyed wrote: »

no auto summary.

"no auto-summary" has no effect on RIPv1. Besides, 10.0.0.0/8 "summarized" is 10.0.0.0/8.

Authentication you would need to bounce the interfaces

There's a fundamental misconfiguration, that bouncing the interface won't solve!

NotHackingYou

NetworkVeteran wrote: »

"no auto-summary" has no effect on RIPv1. Besides, 10.0.0.0/8 "summarized" is 10.0.0.0/8.


There's a fundamental misconfiguration, that bouncing the interface won't solve!

My mistake on the auto summary, RIP is classfull only, duh for me. For the authentication, I am stumped and will need to consult the great Google in the morning - I don't seem to remember authentication being support in RIP v1, so maybe that's it?

NotHackingYou

Looks like that is it, no authentication in RIP v1

NetworkVeteran

CarlSaiyed wrote: »

Looks like that is it, no authentication in RIP v1

Correct. This is a common "gotcha!" in RIP configurations. If you run RIPv1, enabling RIPv2 features has no effect. IOS doesn't issue any sort of warning.

NetworkVeteran

Answers

#1 - "ip split-horizon" is disabled by default on Frame Relay.

IOS Command Reference wrote:

If the interface configuration includes either the encapsulation frame-relay or encapsulation smds command, then the default is for split horizon to be disabled.

Many texts mention the need to disable split horizon on NBMA networks. Indeed, in this scenario, split horizon must be disabled on the hub site (R1) so it can send advertisements between the spokes (R4,R5). However, they fail to explain the danger of creating routing loops when you do so. This can be addressed by selectively enabling/disabling split-horizon on particular NBMA interfaces. In this case, there's absolutely no need for split horizon to be disabled on R4 and R5, and enabling it there prevent any possibility of routing loops for the 10.0.0.0 network.

---

#2 - IOS allows you to configure RIPv2 features--such as "no auto-summary" or "ip rip authentication"--even when RIPv1 is enabled. However, these commands have no effect on RIPv1.

Specifically, by default an interface sends RIPv1 messages and receives RIPv1/RIPv2 messages. The result of configuring authentication on R1 is:

1. Sent messages are NOT authenticated.
2. Received RIPv1 messages are NOT authenticated.
3. Received RIPv2 messages ARE authenticated.

This is unlikely to be a desireable security scheme. To correct the problem, by enforcing authentication on the WAN link, we can configure two commands on RIPv1's S0/0 interface:

ip rip send version 2
ip rip receive version 2

Now, only authenticated messages are sent and received by R1 over the WAN links.

inscom.brigade

Thank you Network Veteran,
I follow your trivia, it is great.