How are route maps processed.

DevilWAH

OK So I mocked up the above network and have the following config.

Al networks apart from 10.1.1.1 are part of OSPF, and the route maps are complete, every device can ping every other IP address, and R4 is redistribution default route so all devices can also ping the 10.1.1.1 loopback.

Gateway of last resort is 172.20.1.2 to network 0.0.0.0

     172.20.0.0/24 is subnetted, 4 subnets
C       172.20.0.0 is directly connected, FastEthernet0/0
C       172.20.1.0 is directly connected, FastEthernet0/1
O       172.20.2.0 [110/20] via 172.20.0.2, 00:23:42, FastEthernet0/0
O       172.20.3.0 [110/20] via 172.20.1.2, 00:23:42, FastEthernet0/1
C    192.168.1.0/24 is directly connected, FastEthernet1/0.2
C    192.168.2.0/24 is directly connected, FastEthernet1/0.3
O*E2 0.0.0.0/0 [110/1] via 172.20.1.2, 00:23:42, FastEthernet0/1
               [110/1] via 172.20.0.2, 00:23:43, FastEthernet0/0

I then have the following config on R1

R1#sh ip access-listsStandard IP access list one
    10 permit 192.168.1.0, wildcard bits 0.0.0.255 (113 matches)
Standard IP access list two
    10 permit 192.168.2.0, wildcard bits 0.0.0.255 (14 matches)
Extended IP access list Internal-IP
    20 permit ip any 192.168.0.0 0.0.255.255 log
    30 permit ip any 172.20.0.0 0.0.255.255 log (33 matches)

Internal-IP captures all packets destined to any internal IP (assume 10.1.1.1 is external)

Access list "one" and "two" capture packets from the two PC's

Then I have the route map

R1#sh route-map
route-map Balance, permit, sequence 10
  Match clauses:
    ip address (access-lists): Internal-IP
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
route-map Balance, permit, sequence 20
  Match clauses:
    ip address (access-lists): one
  Set clauses:
    ip next-hop 172.20.0.2
  Policy routing matches: 77 packets, 8470 bytes
route-map Balance, permit, sequence 30
  Match clauses:
    ip address (access-lists): two
  Set clauses:
    ip next-hop 172.20.1.2
  Policy routing matches: 11 packets, 1210 bytes

This is applied to interfaces coming in from the PC's

So the idea is that if you try to reach an "internal" IP it will use what ever OSPF says, but if you try to reach the 10.1.1.1 address then depending if you are coming from the 192.168.1.0/24 or the 192.168.2.0/24 will depend what way round the loop it will go.

My issue is that while this does set the next-hop correct for reaching 10.1.1.1,

VPCS[1]> trace 10.1.1.1
trace to 10.1.1.1, 8 hops max, press Ctrl+C to stop
 1   192.168.1.1   25.000 ms  9.000 ms  9.000 ms
 2   172.20.0.2   28.000 ms  29.000 ms  29.000 ms
 3   *172.20.2.1   59.000 ms (ICMP type:3, code:3, D

but it also forces the next hop for any ip address.

VPCS[1]> trace 172.20.3.1
trace to 172.20.3.1, 8 hops max, press Ctrl+C to stop
 1   192.168.1.1   16.000 ms  9.000 ms  9.000 ms
 2   172.20.0.2   29.000 ms  29.000 ms  29.000 ms
 3   *172.20.2.1   48.000 ms (ICMP type:3, code:3, Des

I see it hitting the right Access list

R1#
*Mar  1 01:08:04.619: %SEC-6-IPACCESSLOGP: list Internal-IP permitted udp 192.168.1.10(0) -> 172.20.3.1(0), 29 packets

So my question is how are Route-maps processed, is it not top down line an access list? I am sure I could easily get this to work by changing the access list "one" and "two" to have deny statements so they don't capture the internal traffic at all. But I thought if a packet matches the first statement in a route map then it is processed and does not check agisnt any following statements.

fredrikjj

But I thought if a packet matches the first statement in a route map then it is processed and does not check agisnt any following statements.

• They are an ordered sequence of individual statements, each has a permit or deny result. Evaluation of ACL or route-maps consists of a list scan, in a predetermined order, and an evaluation of the criteria of each statement that matches. A list scan is aborted once the first statement match is found and an action associated with the statement match is performed.
  
  Route-Maps for IP Routing Protocol Redistribution Configuration - Cisco
  
  

​So basically, you want a 'set' statement in the first sequence of that route-map if you want it to end the processing of the route-map if there's a match.

DevilWAH

Ah ha!!

That might do it cheers

fredrikjj wrote: »

• They are an ordered sequence of individual statements, each has a permit or deny result. Evaluation of ACL or route-maps consists of a list scan, in a predetermined order, and an evaluation of the criteria of each statement that matches. A list scan is aborted once the first statement match is found and an action associated with the statement match is performed.
  
  Route-Maps for IP Routing Protocol Redistribution Configuration - Cisco
  
  

​So basically, you want a 'set' statement in the first sequence of that route-map if you want it to end the processing of the route-map if there's a match.

fredrikjj

http://www.cisco.com/en/US/products/ps6599/products_white_paper09186a00800a4409.shtml
Policy Route Maps

Each entry in a route map statement contains a combination of match and set clauses/commands. The match clauses define the criteria for whether appropriate packets meet the particular policy (that is, the conditions to be met). The set clauses than explain how the packets should be routed once they have met the match criteria.
For each combination of match and set commands in a route map statement, all sequential match clauses must be met simultaneously by the packet for the set clauses to be applied. There may be multiple sets of combinations of match and set commands in a full route map statement.
The route map statements can also be marked as permit or deny. If the statement is marked as a deny, the packets meeting the match criteria are sent back through the normal forwarding channels (in other words, destination-based routing is performed).



In other words, you could probably just set that first statement to deny and it'll do what you are looking for - aborting the policy based routing if there's a match.

fredrikjj

I replicated your topology and my results do not seem consistent with yours.

Here are my access lists:

ip access-list standard one 
permit 192.168.1.0 0.0.0.255
ip access-list standard two
 permit 192.168.2.0 0.0.0.255
!
ip access-list extended internal
 permit ip any 192.168.0.0 0.0.255.255
 permit ip any 172.20.0.0 0.0.255.255

My route-map:

route-map POLICY permit 10 
match ip address internal
!
route-map POLICY permit 20
 match ip address one
 set ip next-hop 172.20.0.2
!
route-map POLICY permit 30
 match ip address two
 set ip next-hop 172.20.1.2

That should be identical with your config,

Pinging 10.1.1.1 from 192.168.1.1:

IP: s=192.168.1.1 (Serial0/0), d=10.1.1.1, len 100, FIB policy match
IP: s=192.168.1.1 (Serial0/0), d=10.1.1.1, g=172.20.0.2, len 100, FIB policy routed

Pinging 10.1.1.1 from 192.168.2.1

IP: s=192.168.2.1 (Serial0/0), d=10.1.1.1, g=172.20.1.2, len 100, FIB policy routed
IP: s=192.168.2.1 (Serial0/0), d=10.1.1.1, len 100, FIB policy match

Pinging 172.20.3.1

IP: s=192.168.1.1 (Serial0/0), d=172.20.3.1, len 100, FIB policy match
IP: s=192.168.1.1 (Serial0/0), d=172.20.3.1, len 100, FIB policy rejected - normal forwarding

So it does seem to match 'internal' and then revert to the normal forwarding table, and not drop down to sequence 20 and sequence 30.


Note in this output that there have been matched packets on the sequence 10. This counter goes up when I ping 172.20.3.1 and get the debug output saying that normal forwarding is used.

R2#show route-map POLICY
route-map POLICY, permit, sequence 10
  Match clauses:
    ip address (access-lists): internal
  Set clauses:
[B]  Policy routing matches: 20 packets, 2080 bytes[/B]
route-map POLICY, permit, sequence 20
  Match clauses:
    ip address (access-lists): one
  Set clauses:
    ip next-hop 172.20.0.2
  Policy routing matches: 10 packets, 1040 bytes
route-map POLICY, permit, sequence 30
  Match clauses:
    ip address (access-lists): two
  Set clauses:
    ip next-hop 172.20.1.2
  Policy routing matches: 10 packets, 1040 bytes

If we change sequence 10 to deny and ping 172.20.3.1:

IP: s=192.168.1.1 (Serial0/0), d=172.20.3.1, len 100, FIB policy match
IP: s=192.168.1.1 (Serial0/0), d=172.20.3.1, len 100, FIB policy rejected(deny) - normal forwarding

This is consistent with this statement: If the statement is marked as a deny, the packets meeting the match criteria are sent back through the normal forwarding channels (in other words, destination-based routing is performed).


My conclusion is that it doesn't matter if you use permit or deny on a route-map sequence with no set statement when using policy based routing.

networker050184

fredrikjj wrote: »

My conclusion is that it doesn't matter if you use permit or deny on a route-map sequence with no set statement when using policy based routing.

That is my understanding as well unless there is some caveat with PBR.

DevilWAH

? was that using real equipment or something like GNS3?

fredrikjj

GNS3 with some random 12.4 image.

DevilWAH

fredrikjj wrote: »

GNS3 with some random 12.4 image.

ah i just noticed some thing, where did you apply the route map.

I set it up so that from the switch the F1/0 int has sub interfaces (PC gateway IP'S, router on a stick) and applied it to the sub interfaces. but your debug shows it on the S0/0 int?

PS cheers for going to the trouble to lab it up

fredrikjj

DevilWAH wrote: »

PS cheers for going to the trouble to lab it up

After I posted my second link to some Cisco document I realized how little value that actually added. It's not like you don't know how to use Google. If nothing else, at least we've determined that it's dangerous to take documentation at face value because this: A list scan is aborted once the first statement match is found and an action associated with the statement match is performed, seems kind of suspect. It probably doesn't mean what we think it means.

I just wish people would get into the habit of attaching .NET files and configs along with their posts

ah i just noticed some thing, where did you apply the route map.

I set it up so that from the switch the F1/0 int has sub interfaces (PC gateway IP'S, router on a stick) and applied it to the sub interfaces. but your debug shows it on the S0/0 int?

I used serial interfaces only and applied the route-map to a main interface. For no other reason than the fact that I was on my ancient laptop and it avoids the ARP lag from using Ethernet. My LANs were just two loopbacks.

DevilWAH

OK this is strange

new access list

Extended IP access list Internal-IP    10 permit ip any 192.168.0.0 0.0.255.255 log (3 matches)
    11 permit ip any host 172.20.3.1 (15 matches)
    12 permit ip any host 172.20.1.1
    20 permit ip any 172.20.0.0 0.0.255.255 log

Well OK I added the lines 11 and 12

Now if from a host I ping one of these IP address it is not policy routed and goes the default ospf routes. See change the destination IP by one and.....

R1#*Mar  1 00:11:59.519: IP: s=192.168.1.10 (FastEthernet1/0.2), d=172.20.3.1, len 92, FIB policy match
*Mar  1 00:11:59.519: IP: s=192.168.1.10 (FastEthernet1/0.2), d=172.20.3.1, len 92, FIB policy rejected(deny) - normal forwarding
R1#
*Mar  1 00:12:05.655: IP: s=192.168.1.10 (FastEthernet1/0.2), d=172.20.3.2, len 92, FIB policy match
*Mar  1 00:12:05.655: IP: s=192.168.1.10 (FastEthernet1/0.2), d=172.20.3.2, g=172.20.0.2, len 92, FIB policy routed

So why is line 20 not catching the same thing?

Sadly i cant attach a zip file

fredrikjj

posting links to cisco documentation again

Catalyst 6500 Release 15.0SY Software Configuration Guide - Policy Based Routing (PBR) [Cisco Catalyst 6500 Series Switches] - Cisco
The examples shown below involve the use of the access-list command (ACL). The log keyword should not be used with this command in policy-based routing (PBR) because logging is not supported at the interrupt level for ACLs.


It seems like you can't use 'log' on an ACL in Policy Based Routing.

networker050184

That is hardware dependent. It depends on how the ACLs are processed. If PBR is handled in hardware and logging is done in software it won't hit.

DevilWAH

Ah... right that is the one! cheers guys no logging in policies seems to be the rule...

So now back to the BGP design..