Billy (and Jeff), you guys are correct with regard to PBR. I had to get
the exact definition according to Cisco. Its a little more than post-RIB
manipulation as tagging with TOS and IPP qualify as PBR as well.
FYI Per Cisco "Policy-Based Routing (IP Routing)"..
http://www.cisco.com/en/US/products/ps6599/products_white_paper09186a00800a44
09.shtml
Set ClausesbDefining the Route
If the match clauses are satisfied, one of the following set clauses can be
used to specify the criteria for forwarding packets through the router;
they are evaluated in the order listed:
*1 *List of interfaces through which the packets can be routedbIf more than
one interface is specified, then the first interface that is found to be up
will be used for forwarding the packets.
*2 *List of specified IP addressesbThe IP address can specify the adjacent
next hop router in the path toward the destination to which the packets
should be forwarded. The first IP address associated with a currently "up"
connected interface will be used to route the packets.
*3 *List of default interfacesbIf there is no explicit route available to
the destination address of the packet being considered for policy routing,
then route it to the first up interface in the list of specified default
interfaces.
*4 *List of default next hop IP addressesbRoute to the interface or the
next hop specified by this set clause only if there is no explicit route
for the destination address of the packet in the routing table.
*5 *IP TOSbA value or keyword can be specified to set the type of service
in the IP packets.
*6 *IP precedencebA value or keyword can be specified to set the precedence
in the IP packets.
The set commands can be used in conjunction with each other.
The next hop router specified in the set clauses must be adjacent to the
policy router, sharing a subnetwork with the policy router.
If the packets do not meet any of the defined match criteria (that is, if
the packets fall off the end of a route map), then those packets are routed
through the normal destination-based routing process. If it is desired not
to revert to normal forwarding and to drop the packets that do not match
the specified criteria, then interface Null 0 should be specified as the
last interface in the list by using the set clause.
------------
That said, yes, RM applied to neighbor inbound will do it. I realized my
offset-list error as soon as I hit send...
Tim
On Sat, Jul 26, 2014 at 11:26 AM, Jeff Lodwick <jeff_at_tydesystems.com> wrote:
> One more thing. If you wanted to use a route map to affect the metric of a
> route you would apply it to the neighbor command inbound as you receive the
> route.
>
> Jeffrey Lodwick - CCIE 15671 R&S
> Senior Data Engineer / Owner
> Jeff_at_tydesystems.com
> Office: 303-346-9988
> Mobile: 303-919-1366
>
> *[image: wave-logo-2-color-small-11-25-13]*www.tydesystems.com
>
>
> -------- Original message --------
> From: Billy Singh
> Date:07/26/2014 8:46 AM (GMT-07:00)
> To: "Tim Cribbs Jr."
> Cc: ccielab_at_groupstudy.com
> Subject: Re: EIGRP distribute-lists with route-maps
>
> Bandwidth and delay. R4 is connecting to both upstream routers via the
> same outgoing interface, i.e. e0/0, so I'm not following...
>
> I disagree with the simple view that any time you use a route-map you're
> doing PBR. Route-maps may be a functional component of PBR, but by
> themselves I don't imagine they'd constitute PBR. The routing is still
> being done by R4 using the RIB. PBR would be if packets were routed
> before the RIB was consulted, no? If I'm manipulating the routes before
> they enter the EIGRP topology table, therefore changing how they enter
> the RIB that's not PBR.
>
> On 07/27/14 00:27, Tim Cribbs Jr. wrote:
> > Ask yourself what does EIGRP use (the defaults) to decide the best
> > route. 2 metrics should come to mind. Using route-maps is PBR, which
> > is prohibited. The answer is easier than you think.
> >
> >
> > On Sat, Jul 26, 2014 at 10:18 AM, Billy Singh <billysingh_at_ipanyany.com
> > <mailto:billysingh_at_ipanyany.com>> wrote:
> >
> > Good evening all,
> >
> > I was doing some practise labs tonight and playing around with EIGRP.
> > I'm trying to grasp a better understanding of the limits of
> route-maps
> > when used with distribute-lists in EIGRP.
> >
> > For the sake of simplicity, let's imagine a topology with three
> > routers
> > all connected over a shared, broadcast media (Ethernet).
> >
> > R2 & R3 are the upstream routers both advertising a network
> > 200.2.2.0/24 <http://200.2.2.0/24>
> >
> > R4 is the downstream router with EIGRP neighbour adjacencies to both
> > these upstream routers. As a result, R4 is doing equal cost
> > load-balancing between both upstream routers for 200.2.2.0/24
> > <http://200.2.2.0/24>.
> >
> > sh ip ro | s 200.2.2.0
> > D 200.2.2.0/24 <http://200.2.2.0/24> [90/1024640] via 10.1.1.3,
> > 00:00:16, Ethernet0/0
> > [90/1024640] via 10.1.1.2, 00:00:16, Ethernet0/0
> >
> > The requirement was to have R4 prefer the route via R2, unless R2 was
> > unavailable, in which case it would route through R3.
> >
> > - Configuration can only be done on R4.
> > - No PBR (Policy Based Routing).
> > - No manipulation of the Administrative Distance (AD) allowed
> > (This was
> > actually the easy answer, but I wanted to try and find an
> > alternate method).
> >
> > So we can use route-maps in conjunction with distribute lists and I
> > guess this is where my confusion currently is. Here's what I tried
> > to do:
> >
> > 1. Access list to match the route:
> >
> > access-l 44 permit 200.2.2.0 0.0.0.255
> >
> > 2. Access list to match one of the route-sources (R3):
> >
> > access-l 3 permit host 10.1.1.3
> >
> > 3. Route-map configuration. I'm trying to bump up the metric of a
> > route
> > by 1000 so it's no longer the preferred route:
> >
> > route-map PREFER-R2 permit 10
> > match ip addr 44
> > match ip route-source 3
> > set metric +1000
> > route-map PREFER-R2 permit 20
> >
> > 4. Apply it to the EIGRP routing instance:
> >
> > router eigrp AS100
> > addr ipv4 uni auto 100
> > topo base
> > distrib route-map PREFER-R2 in
> >
> >
> > And it didn't end up working. So clearly my intended use of the
> > route-map in the above scenario is invalid. Probably fine for when
> > redistributing, but not when used in conjunction with distribute
> > lists.
> > If I add a different "set" parameter (one which seems to be commonly
> > referred to in the configuration guide; a route tag), then I see
> > that it
> > gets applied:
> >
> >
> > sh ip ro 200.2.2.0
> > Routing entry for 200.2.2.0/24 <http://200.2.2.0/24>
> > Known via "eigrp 100", distance 90, metric 1024640
> > Tag 200, type internal
> > Redistributing via eigrp 100
> > Last update from 10.1.1.3 on Ethernet0/0, 00:00:13 ago
> > Routing Descriptor Blocks:
> > * 10.1.1.3, from 10.1.1.3, 00:00:13 ago, via Ethernet0/0
> > Route metric is 1024640, traffic share count is 1
> > Total delay is 1002 microseconds, minimum bandwidth is
> > 10000 Kbit
> > Reliability 255/255, minimum MTU 1500 bytes
> > Loading 1/255, Hops 1
> > Route tag 200
> > 10.1.1.2, from 10.1.1.2, 00:00:13 ago, via Ethernet0/0
> > Route metric is 1024640, traffic share count is 1
> > Total delay is 1002 microseconds, minimum bandwidth is
> > 10000 Kbit
> > Reliability 255/255, minimum MTU 1500 bytes
> > Loading 1/255, Hops 1
> >
> > I'm looking through the configuration guide and the CLI reference
> > to try
> > and work out what match criteria and set commands are available when
> > route-maps are used under different contexts, but I'm not having much
> > luck finding anything thorough or concrete. When you think about
> > it, it
> > does kind of make sense, distribute-lists are for filtering not
> > routing
> > metric manipulation but since route-maps allow for so much
> > manipulation
> > of routes an understanding of what parameters you can use under what
> > scenarios would be great.
> >
> > Ideas or resources?
> >
> > Thanks.
> >
> > Billy
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> >
> _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
Received on Sat Jul 26 2014 - 12:18:21 ART
This archive was generated by hypermail 2.2.0 : Fri Aug 01 2014 - 07:53:01 ART