Ethernet1/0 10.20.20.0 is directly connected, Ethernet1/0 The route 50.50.50.0/24 is in the routing table and has a metric of 5. The route below it is a result of the network 10.0.0.0 statement on R2. This route is not a product of redistribution, and SO has a normal RIP metric. Another common issue is the need to advertise networks that are connected to a router but are not included in the routing process. Figure 11-3 shows a network with three routers, all of which are participating in RIPv2. R1 has a network that is not included in the RIP process. The configuration for R1's RIP process is as follows: router rip version 2 network 10.0.0.0 no auto-summary 50.50.50.0/24 RIPv2 10.10.10.0/24 10.20.20.0/24 Figure 11-3. Redistributing connected routes into RIP There are no routers on the 50.50.50.0/24 network, SO enabling RIP on that interface would add useless broadcasts on that network. Still, R3 needs to be able to get to the network. To add 50.50.50.0/24 to the advertisements sent out by R1, we must redis- tribute connected networks into RIP using the redistribute connected command on R1: router rip version 2 redisribute connected metric 1 network 10.0.0.0 no auto-summary Redistributing into RIP While sending useless broadcasts may seem trivial, remember that RIP sends broadcasts that include the entire routing table. Only 25 destina- tions can be included in a single RIP update packet. On a network with 200 routes, each update will be composed of eight large broadcast pack- ets, each of which will need to be processed by every device on the network. That's potentially 12k of data every 30 seconds. If that's not enough proof for you, consider this: RIP updates are clas- sified as control packets (IP precedence 6 or DSCP 48). That means that they have a higher precedence than voice RTP (Real-Time Protocol) packets, which are classified as express forwarding packets (IP prece- dence 5 or DSCP 40). Put simply, RIP updates can easily affect voice quality on VOIP-enabled networks. Now R3 can see the 50.50.50.0/24 net