From: Filyurin, Yan (yan.filyurin@eds.com)
Date: Mon Jun 18 2007 - 15:34:15 ART
Actually, at certain point and it was based on real life experience, I
had someone (I can't personally complete verify it) attempt to do it
using extended ACL wildcards and it didn't work. At that time the goal
was to permit specific 10.0.0.0/8 routes, but not 10/8 itself and what
worked was doing a regular standard ACL denying 10.0.0.0 0.0.0.0 and it
worked. I hate to say it, but I don't remember all the details, but
that seems in line with that is said here.
But to just to double check on my original question. Is it true that:
route maps in EIGRP are only used in redistribution and when it comes to
route filtering, one can use ACLs and prefix-lists only with prefix
lists having more granularity and easier to deal with.
Thank you, Ben and Tarun.
Yan
________________________________
From: Tarun Pahuja [mailto:pahujat@gmail.com]
Sent: Monday, June 18, 2007 2:07 PM
To: Ben
Cc: Filyurin, Yan; ccielab@groupstudy.com
Subject: Re: Using route maps in EIGRP
Ben,
My comments were based on the following document and I
was referring to standard ACLs.
http://www.cisco.com/warp/public/103/eigrpfaq.shtml
"The use of ACL and distribute-list under EIGRP does not work in
this case. This is because ACLs do not check the mask, they just check
the network portion. Since the network portion is the same, when you
allow 172.16.1.0/24, you also allow 172.16.1.0/28."
I usually use Prefix-list for route filtering as it gives me
more control. I have seen cases where extended ACLs are used to match
subnet mask, but the logic is slightly different as you suggested.
Destination portion becomes the subnet mask portion. You will find
prefix list must easier to implement specially when dealing with VLSM
addresses.
HTH,
Tarun
On 6/18/07, Ben <bmunyao@gmail.com> wrote:
Tarun
"remember ACLs will not match subnet mask."
Correct me if I'm off track but I was under the
impression an ACL can also match a subnet mask as follow:
access-list 100 permit ip host 150.4.5.0
<http://150.4.5.0/> host 255.255.255.0 <http://255.255.255.0/>
I haven't tested it in a lab yet, so I'm still unsure if
it works. I'd sure appreciate any input on this ACL usage.
Ben
On 6/18/07, Tarun Pahuja < pahujat@gmail.com
<mailto:pahujat@gmail.com> > wrote:
Yan,
You are right about the use to route-map
for advanced filtering. I
am not aware of any limitations of distributing
routes in and out of eigrp
in terms of routing protocols. Remember, to
specify the metric when
redistributing in eigrp as their is no default
metric, also use prefix-list
in place of ACLs for better control, remember
ACLs will not match subnet
mask.
For your second question, It is more useful in
many cases to configure the
route map that includes matching the route type
based on the source protocol
and AS using the distribute-list command for
EIGRP.
In the following example, the source protocol is
specified as Border Gateway
Protocol (BGP) and the AS number is 2, which
permits external EIGRP routes
of BGP:
match source-protocol bgp 2
HTH,
Tarun
On 6/17/07, Filyurin, Yan <yan.filyurin@eds.com>
wrote:
>
> Hello Groupstudy. Recently I've reading up
EIGRP support for route maps
> and the way they explain it is that it almost
works like a distribute
> list where you can do advanced matching on
incoming routes. However
> according to some playing around and
documentation, use of route-map in
> a distribute list is only supported with OSPF.
So here I was reading
> this URL:
>
>
http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_
> guide09186a0080220721.html
>
> And the part that confused me the most was
this
>
> "
> The EIGRP Route Map Support feature enables
Enhanced Interior Gateway
> Routing Protocol (EIGRP) to interoperate with
other protocols by
> filtering inbound and outbound traffic based
on complex route map
> options.
> "
>
> Am I just confused by the description and that
URL gives nothing more
> than ability to redistribute the routes better
by matching on some of
> the parameters of other protocols, or is
actual route filtering
> involved. And in case of the second, how
would it even know which
> source protocol it originally came from.
Sounds very logical, so just
> wanted to do a sanity check.
>
> Thank you
>
> Yan
>
>
This archive was generated by hypermail 2.1.4 : Sun Jul 01 2007 - 17:24:49 ART