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