 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. 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 protocols they came from-90 for EIGRP, and SO on. Still another is to use autonomous system numbers. Whatever you choose, make sure it's obvious, 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 auto-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 permit 20 set tag 110 The route maps are the same on R2 because the same rules apply, and we need to test for any routes redistributed from other routers. Limiting Redistribution When a route is redistributed from OSPF into EIGRP, it will be assigned a tag of 110. Routes redistributed from EIGRP into OSPF will be assigned a tag of 90. When a route tagged with 90 is seen in OSPF, we'll know if was sourced from EIGRP because the tag value will have been set to 90. When this route then comes to be redistrib- uted into EIGRP from OSPF on the other router, the route map will deny it. Thus, a route cannot be 