ooh ooh, I'm getting ready to have some fun with this one. got it mocked up in my lab. just want to clarify something prior to jumping through hoops and writing a report.
On R4 you have mutual redistribution between OSPF and EIGRP? ospf---> eigrp and eigrp -----ospf ?? On R2 you have the same - ospf to eigrp and eigrp to ospf and you have igrp into what and what into igrp? both going both ways? Scott, you have a mess from the get go. ;-> Chuck P.S. I'm considering opening up the pod to internet access after I have this up and working. there is a technical detail to work out. I'll let you know. ""Scott H."" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > This is actually something a co-worker has drawn up for me. One of my > weaker points has always been multiple redistribution between multiple > protocols. Goes something like this: > > R1---------R2--------R3 > | | > | | > -----R4---- > > R1 has IGRP connection to R2 > R2 has a OSPF connection to R4 > R2 also has EIGRP connection to R3 > R3 is EIGRP to R4 > > R4 and R3 have a bunch of loopbacks to generate routes. > > My thought here was to only allow routes originating from their respective > domain into IGRP. That would solve the loop and AD issue here. The > redundancy is gone, but whoever draws up a network like this in real life > should be shot. > > On R4: > > route-map filtereigrp deny 10 > match tag 1 > > route-map filtereigrp permit 20 > set tag 2 > > route-map filterospf deny 10 > match tag 2 > > route-map filterospf permit 20 > set tag 1 > > router ospf 1 > redistribute eigrp 1 subnets route-map filtereigrp > > router eigrp 1 > redistribute ospf 1 route-map filterospf > default-metric x x x x > > On R2: > > Same as above between eigrp and ospf > > For OSPF2IGRP: > > route-map filtereigrproutes deny 10 > match tag 1 > > route-map filtereigrproutes permit 20 > > For EIGRP2IGRP: > > route-map filterospfroutes deny 10 > match tag 2 > > route-map filterospfroutes permit 20 > > > router igrp 1 > redistribute eigrp 1 route-map filterospfroutes > redistribute ospf 1 route-map filtereigrproutes > default-metric x x x x > > Will probably have a redistribute connected in EIGRP and OSPF to pick up the > IGRP connection to R1. Not sure what you meant by the route leak, please > explain. > > > ""Chuck"" wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > hmmm.... interesting discussion. the scenario reminds me of something I > saw > > from someplace called NT Labs, maybe? > > > > Let's see if I can sketch the scene: > > > > > > R1-----------------R2-----------------R3 > > IGRP bunch of stuff OSPF/EIGRP > > > > R2: > > > > router IGRP > > redistribute OSPF route-map filter-ospf-tag > > redistribute EIGRP route-map filter-eigrp-tag > > > > router eigrp > > redistribute OSPF tag 1 > > > > R3 > > > > router ospf > > redistribute eigrp tag 2 > > > > seems to me there is a trick in here somewhere. maybe on R2, where > > redistribution into IGRP contains the possibility of route leak? maybe not > > in this topology. maybe if the topology were a ring or a circle, and there > > are two points of mutual redistribution? Slattery's book has an > interesting > > exercise along that line, and I'm not sure I ever got the filters tweaked > > right in that one. > > > > Chuck > > > > ""Scott H."" wrote in message > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > On 1 router I am redistributing OSPF into IGRP, EIGRP into IGRP, and > OSPF > > > into EIGRP. Downstream, I am redistributing OSPF into EIGRP. The loop > in > > > this scenario is deadly so I need to find a way to let both EIGRP and > OSPF > > > redistribute only routes originating from their domains into IGRP. The > > plan > > > was to tag OSPF routes going into EIGRP w/ a tag of 1 and EIGRP routes > > going > > > into OSPF w/ a tag of 2 downstream. Therefore, when I redistribute > EIGRP > > > into IGRP I can deny all routes w/ a tag of 1 and permit anything else. > > > Also, when I redistribute OSPF into IGRP I can deny all routes w/a tag > of > > 2 > > > and permit everything else. This should ensure that IGRP receives only > > > routes from the OSPF domain that originated in OSPF and only EIGRP > routes > > > that originated in EIGRP. I still have not had a chance to test this, > but > > > in theory it should work perfectly. > > > > > > You see any potential problems here? > > > > > > ""Chuck"" wrote in message > > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > > I did a little bit of research on this, being curious as to the reason > > for > > > > your question. > > > > > > > > essentially, the logic illustrated below works just fine. the > questions > > > that > > > > came up are: > > > > > > > > 1) how to tag the eigrp routes in the first place and > > > > 2) why the routes may not appear in IGRP assuming the eigrp tags > exist. > > > > > > > > there may be a way to tag the routes natively, but I have not found > it. > > > tags > > > > can be set during redistribution into eigrp using route-maps. > > > > > > > > don't forget the metric commands when redistributing into igrp and > > eigrp. > > > > routes do not get redistributed without a metric assignment. I > > experienced > > > > difficulty when using a route-map to set the metric. I ended up using > a > > > > default metric under the eigrp process. > > > > > > > > the setup: > > > > > > > > OSPF----->EIGRP------->IGRP > > > > > > > > ospf routes have a tag of 200 > > > > > > > > O 192.168.23.0/24 [110/74] via 192.168.34.3, 00:19:09, Ethernet0 > > > > O 192.168.33.0/24 [110/11] via 192.168.34.3, 00:19:09, Ethernet0 > > > > R4# > > > > > > > > D 192.168.106.0/24 [90/2297856] via 192.168.47.4, 00:16:05, Serial0 > > > > C 192.168.47.0/24 is directly connected, Serial0 > > > > D 192.168.105.0/24 [90/2297856] via 192.168.47.4, 00:16:05, Serial0 > > > > I 192.168.8.0/24 [100/8976] via 192.168.78.8, 00:01:17, Serial1 > > > > 156.26.0.0/24 is subnetted, 1 subnets > > > > D EX 192.168.23.0/24 [170/2195456] via 192.168.47.4, 00:15:15, Serial0 > > > > D EX 192.168.34.0/24 [170/2195456] via 192.168.47.4, 00:15:15, Serial0 > > > > D EX 192.168.33.0/24 [170/2195456] via 192.168.47.4, 00:15:17, Serial0 > > > > R7# > > > > > > > > note the external routes in EIGRP - these originate in OSPF, and > should > > > have > > > > a tag of 200 > > > > the "D" routes ( native EIGRP ) will have no such tag > > > > > > > > I 192.168.23.0/24 [100/10576] via 192.168.78.7, 00:00:16, Serial1 > > > > I 192.168.34.0/24 [100/10576] via 192.168.78.7, 00:00:17, Serial1 > > > > I 192.168.33.0/24 [100/10576] via 192.168.78.7, 00:00:18, Serial1 > > > > R8# > > > > > > > > note that the only IGRP routes are those that appear as EIGRP external > > > > routes on R7 ( those redistributed from OSPF, and having the tag of > 200. > > > > note that the EIGRP native routes of 192.168.105.0 and 106.0 do not > > appear > > > > > > > > things to check: > > > > > > > > 1) proper construction of the route maps > > > > > > > > 2) setting of a default-metric within the eigrp and igrp processes so > > that > > > > routes are redistributed and/or accepted by those processes > > > > > > > > 3) that tags are actually being applied to routes as you believe they > > > should > > > > be. > > > > > > > > HTH > > > > > > > > Chuck > > > > > > > > > > > > ""Chuck"" wrote in message > > > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > > > Route maps are essentially built around an "if then else(if)" logic. > > the > > > > > point of their activation is the point of their inception. > > > > > > > > > > therefore if you were to have a route-map such as: > > > > > > > > > > route-map eigrp_tag_igrp permit 10 > > > > > match tag X > > > > > set metric 10000 100 255 1 1500 > > > > > > > > > > and the redistribute statement: > > > > > > > > > > router igrp 100 > > > > > redistribute eigrp 50 route-map eigrp_tag_igrp > > > > > > > > > > then the logic flow is: > > > > > > > > > > 1) take a route learned from eigrp 50 > > > > > 2)if the tag for that route is X then set the metric as stated and > > > > > redistribute it into IGRP 100 > > > > > 3) else don't redistribute > > > > > > > > > > in this case, only those routes with a tag of X learned from eigrp > 50 > > > will > > > > > be redistributed into igrp ( subject to the classfulness of the > > route ) > > > > > > > > > > sometimes it can be a little difficult to determine where exactly > > things > > > > > happen in the various processes on a router. for example, linear > > > > > redistribute seems not to occur at all, even if that does not seem > > > > logical. > > > > > ( can't redistribute from rip to igrp to ospf an the same router, > not > > > and > > > > > get anything coherent or predictable as a result ) however, in this > > > case, > > > > > the logic appears to be straightforward, so far as I can tell. > > > > > > > > > > HTH > > > > > > > > > > Chuck > > > > > > > > > > ""Scott H."" wrote in message > > > > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > > > > At what point during redistribution is a route-map processed? In > > > other > > > > > > words, if I want to redistribute from EIGRP (supports tags) to > IGRP > > > > > (doesn't > > > > > > support tags) can I match tags in the route map and then let those > > > > routes > > > > > go > > > > > > into IGRP? Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=36042&t=35624 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
