07-03-2012 04:42 AM - edited 03-07-2019 07:35 AM
Hi Dear.
Router(config)#route-map test permit 10
Router(config-route-map)#match ip address 10
Router(config-route-map)#match ip address 15
Router(config-route-map)#set local-pref 150
is this AND algoritm?
Router(config-route-map)#route-map test permit 20
Router(config-route-map)#match ip address 10 15
Router(config-route-map)#set local-pref 250
Router(config-route-map)#end
is this OR algorithm?
07-03-2012 04:50 AM
Hello Teymur,
Router(config)#route-map test permit 10
Router(config-route-map)#match ip address 10
Router(config-route-map)#match ip address 15
Router(config-route-map)#set local-pref 150
This configuration would translate simply to
Router(config)#route-map test permit 10
Router(config-route-map)#match ip address 10 15
Router(config-route-map)#set local-pref 150
The resulting configuration is a logical OR, basically identical to the second example you have posted.
In a route-map, Cisco IOS does not allow to perform an AND operation between the matches of the same type, i.e. it is not possible to configure a match for both ACL 10 AND 15.
Best regards,
Peter
07-03-2012 04:54 AM
Hi Peter,
I beg to differ,
As per Cisco Doc for Route-map operations:
A match or set command in each clause can be missed or repeated several times, if one of these conditions exist:
•If several match commands are present in a clause, all must succeed for a given route in order for that route to match the clause (in other words, the logical AND algorithm is applied for multiple match commands).
•If a match command refers to several objects in one command, either of them should match (the logical OR algorithm is applied). For example, in the match ip address 101 121 command, a route is permitted if it is permitted by access list 101 or access list 121.
•If a match command is not present, all routes match the clause. In the previous example, all routes that reach clause 30 match; therefore, the end of the route map is never reached.
•If a set command is not present in a route map permit clause then the route is redistributed without modification of its current attributes.
Regards,
Smitesh
07-03-2012 05:32 AM
Hello Smitesh,
I am glad you asked because frankly, I was mistaken in the same way earlier.
I know that if multiple match statements are located in a single route-map block, all of them must match, i.e. this is a logical AND. However, entering multiple match statements using the same match object (i.e. ACL) will result in all ACLs being placed into a single match statement, resulting in a logical OR.
In other words, you can not achieve a route-map to contain, for example, multiple match ip address commands because even if you enter them multiple times, each time referring to a different ACL, the IOS will silently "collapse" all these commands to a single match ip address command containing all ACL numbers.
Best regards,
Peter
07-03-2012 06:00 AM
Peter,
This is interesting and I've wondered this also. So, is what you're saying that the logical OR comes into play when you have multiple entries in a single acl and a logical AND is when you have multiple acls?
Thanks!
John
07-03-2012 06:23 AM
Hi Peter,
+5 for this very interesting info.
Regards.
Alain.
Don't forget to rate helpful posts.
07-03-2012 06:38 AM
+5 Peter. I tested this because I've always had a little confusion when the AND operator came into play. Thank you!
07-03-2012 07:54 AM
Hello John and Alain,
Thank you both very much for your kind ratings!
Just to remove any ambiguosity, I'll reiterate a little here: multiple standalone match statements in a single route-map block are possible only if they refer to different kinds of tests, e.g. ACLs and interfaces (think NAT using route-maps for two different ISPs matching both ACL for internal IP addresses and the egress interface). However, when trying to add a couple of match ip address statements, even though each of them refers to a unique ACL number or name, the IOS will nevertheless collapse all these statements into a single match ip address statement. That is why they become logically OR-ed - because the IOS puts them into a single match ip address line even though each ACL was originally input as a separate and standalone match statement.
I remember trying to respond to a thread some two months ago from now where the poster tried to use the continue clause in route-map for PBR purposes. This is not supported, sadly. I suggested at that point using multiple match ip address commands in a single route-map block to achieve the same result. However, as it turned out - and somebody corrected me back then - this was not possible. I asssumed I can make a logical AND between two ACLs by referring to them in different match statements. Sadly, IOS does not support this - it collapsed the configuration into a single match statement, spoiling my attempt at helping
Best regards,
Peter
07-03-2012 10:15 PM
+5 Peter...
Had to do it to understand what exactly you meant...
However, can you share what if one wants AND operation... Will he be using different sequence number to obtain the same ??
Regards,
Smitesh
07-04-2012 10:36 PM
+5 Peter for this awsome info
I tried to lab test and achieve AND by using two test conditions (ACL and community-list) in two match statements in a single route-map instance.
Works like a champion!!
I sent community 1000 from one BGP router and on neighbor added route-map on inbound
R2#sh ip community-list
Community standard list 10
permit 100
Community standard list 11
permit 1000
R2#sh route-map
route-map TEST-RM, permit, sequence 10
Match clauses:
ip address (access-lists): 11
community (community-list filter): 10
Set clauses:
metric +400
Policy routing matches: 0 packets, 0 bytes
route-map TEST-RM, permit, sequence 11
Match clauses:
ip address (access-lists): 11
community (community-list filter): 11
Set clauses:
metric +500
Policy routing matches: 0 packets, 0 bytes
route-map TEST-RM, deny, sequence 20
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes
R2#sh ip bgp
BGP table version is 7, local router ID is 192.168.0.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 172.16.0.1/32 192.168.0.1 500 0 10 i
*> 172.16.1.1/32 192.168.0.1 500 0 10 i
03-02-2015 01:40 PM
+5 Peter... really helpful information...
11-06-2012 01:02 AM
+5 very intresting and informative !
11-06-2012 10:18 AM
Cisco Docs are full of discrepancies; I would not believe or trust them;
Trust but Verify is my motto;
11-20-2012 01:45 AM
Hi Martin,
I agree but please, if you find discrepancies, report them. I do it often, and it helps. And please do care of sharing your experiences here - it is much appreciated!
Best regards,
Peter
05-19-2019 06:11 PM - edited 05-19-2019 06:31 PM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide