redistributed into EIGRP if it originated in EIGRP. OSPF-sourced routes are similarly blocked from redistribution back into OSPF. While this design does prevent routing loops, it does not solve the problem of R3's 50.50.50.0/24 network being advertised through the wrong protocol. R2 is now pointing back to OSPF for this network: R2# sho ip route [text removed] Gateway of last resort is not set 50.0.0.0/24 is subnetted, 1 subnets 50.50.50.0 [110/100] via 10.10.10.1, 00:11:50, FastEtherneto/o 20.0.0.0/24 is subnetted, 1 subnets 20.20.20.0 is directly connected, FastEthernet0/1 10.0.0.0/24 is subnetted, 1 subnets 10.10.10.0 is directly connected, FastEtherneto/o Every network is different, and there will always be challenges to solve. In this case, we might have been better off with the first design, where each router was only redis- tributing in one direction, even though that design is not very resilient. The way to solve the problem, and provide multiple mutual redistribution points, is to combine the two scenarios. With route maps, we can match multiple tags, SO in addition to denying any routes already redistributed into EIGRP on R2, we can also match on the 3 tag we set on R3: route-map EIGRP-to-OSPF deny 10 match tag 110 3 route-map EIGRP-to-OSPF permit 20 set tag 90 The line match tag 110 3 means, "match on tag 110 or 3." Now R2 has the right routes: R2# sho ip route [text removed] Gateway of last resort is not set 50.0.0.0/24 is subnetted, 1 subnets 50.50.50.0 [170/156160] via 20.20.20.3, 00:00:01, FastEthernet0/1 20.0.0.0/24 is subnetted, 1 subnets 20.20.20.0 is directly connected, FastEthernet0/1 10.0.0.0/24 is subnetted, 1 subnets 10.10.10.0 is directly connected, FastEtherneto/o Chapter 11: Redistribution Another method Here's another method to use, which I like for its elegance: because redistributed routes are external, only allow internal routes to be redistributed. Once a route is redistributed and becomes external, it won't be redistributed again. When redistributing OSPF routes into another protoc