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=35701&t=35624 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
