rneto/o A Real-World Example Today's networks are often designed with high availability as a primary driver. When you're designing networks with no single points of failure, a scenario like the one shown in Figure 11-7 is a real possibility. Redistribute connected OSPF 100 Area 0 EIGRP 100 Figure 11-7. Two routers performing mutual redistribution Here, we have two routers doing mutual redistribution (both are redistributing EIGRP into OSPF, and OSPF into EIGRP). You've already seen what can happen when each one is only redistributing in one direction. The probability of router-induced mayhem is pretty strong here, but this kind of design is very common, for the reasons already discussed. To make this scenario work, we'll again use route tags, but this time we'll add some flair (you can never have too much flair). The idea behind this technique is simple: routes sent from one protocol into another will not be advertised back to the protocol from which they came. Limiting Redistribution I like to tag my routes with the number of the router I'm working on. That's not always possible, especially if you've named your router something clever, like Boston-PoP-Router or Michelle. Another option is to tag your routes with the administrative distance of the routing pro- tocols they came from-90 for EIGRP, and SO on. Still another is to use autonomous system numbers. Whatever you choose, make sure it's ob- vious, if possible. And always document what you've done SO others can understand your brilliance. Using the administrative distance as a tag, here is the configuration for R1: router eigrp 100 redistribute ospf 100 route-map OSPF-to-EIGRP network 20.20.20.0 0.0.0.255 default-metric 100000 100 255 1 1500 no uto-summary router ospf 100 log-adjacency-changes redistribute eigrp 100 subnets route-map EIGRP-to-OSPF network 10.10.10.0 0.0.0.255 area 0 default-metric 100 route-map EIGRP-to-OSPF deny 10 match tag 110 route-map EIGRP-to-OSPF permit 20 set tag 90 route-map OSPF-to-EIGRP deny 10 match tag 90 route-map OSPF-to-EIGRP 