What does the following commands mean?
access-list 111 permit ip host 10.10.10.10 host 10.100.100.100
route-map test permit 10
match ip address 111
set tag 122
ip route 10.100.100.100 255.255.255.255 null0 tag 122
Thanks in advance
The route-map only permits routes that match both the access-list and also have a tag of 122.
The access-list doesn't match the static route though. It should be
access-list 111 permit ip host 10.100.100.100 host 255.255.255.255
To allow the static route, as the first host statement is compared against the prefix and the second one against the mask.
It seems to me that your explanation would be right if the route map had two match statements (match the access list and match the tag) but the route map has one match and one set tag.
this kind of route map is usually used to control redistribution of routes between protocols. And in that context more often matches a standard access list than an extended access list. Though as Harold points out an extended access list can be used.
This is not related to source based routing at all, right?
which means packets from the host 10.10.10.10 will be dropped when communicate with host 10.100.100.100? and others source addresses will not be affected?
Thanks in advance
No that is not what it means. I apparently did not understand what you were trying to achieve (and my guess is that Harold did not understand either). With the static route as you have configured it any traffic to that destination address will be dropped. So if you want other source addresses to not be affected you do need to configure Policy Based Routing. The first thing to do is to remove the static route.
And then if you want traffic from that specific host to that specific destination to be dropped you would need to change the route map, remove the set tag statement and replace it by a set interface null0 statement. And since you would be implementing Policy Based Routing you would need to be sure that there is an ip policy route-map test statement on the interface where traffic from 10.10.10.10 comes into the router.
If this answer does not seem to be what you want then we need some clarification about what you are trying to achieve.
Absolutely Rick. I shouldn't answer any post before I have my first coffee ;-)
Thanks Ricky for your post. What i want to achieve is that the config is no related to source-based routing. I know that i need to implement PBR.
The policy will be:
Source addresses "A" to be route to next-hop "X", if X is not found in the routing table it will be routed to next-hop Y.
And source addresses "B" to be route to next-hop "Y", if Y is not found in the routing table, it will be route to next-hop X.
If both destinations X & Y are not found in the routing table, it will be routed to Z, if not found it will be routed to W.
Source: A , B
Next Hops: X, Y, Z, & W
The config will be as follows:
access-list 150 permit ip A D
access-list 160 permit ip B D
route-map Rick permit 10
match ip address 150
set ip next-hop X
route-map Rick permit 20
match ip address 160
set ip next-hop Y
ip route D X 10
ip route D Y 20
ip route D Z 30
ip route D W 40
My first question, does this config right? i mean the theory?
Second question, Rick route-map must be implemented at interface, if i have many VLAN interfaces and interfaces to WAN aggregation routers, is it possible and logic to apply this route map to all the interfaces or what?
Note: All these interfaces are at my two core switches. The next hops are reachable since they advertised in the EIGRP if they are UP.
Harold, i will invite you for a coffee don't worry to post your reply ;)
Thanks in advance
I am a bit confused whether this is related to the original question about 10.10.10.10 and 10.100.100.100 or whether this is really a new question.
As to this question if the next hops are reachable since they are advertised by EIGRP then I do not see a reason to have the static routes in the configuration.
Also the static routes in this post are configured as floating static routes. But there is some possible issue with floating static routes on LAN interfaces (such as switches) because the original route is not removed from the routing table unless the outbound interface goes protocol down and Ethernet interfaces usually do not go protocol down just because they lost connectivity to a next hop. You may need to look into object tracking with static routes to get the floating static routes to work - if you keep the static routes.
Since you seem to be dealing with a couple of specific source addresses I am not sure how many interfaces on the core switch may receive traffic from that source address. I do not know of any way to apply the ip policy command to all interfaces without going interface by interface.
Thanks Rick for this quick reply.
First of all, this is new question, i don't need to create a new conversation.
The next hops are WAN ip addresses, when they are down, they will be automatically from the routing table, i thing no need for object tracking.
The static routes are good when for example, the next-hop X is down and removed from the routing table, so the next hop is not found in the routing table for route-map Rick sequence 10, so it will be routed to default routing - as "set ip next-hop". When X is down it will route to Y.
You are right for the interfaces for this route-map to be applied, but let us say that we need to match voice traffic from any to destination D like:
access-list 160 permit udp any D range 16384 32767 ?
Thanks again & again