So where Part 1 of this lab left off, we learned that without that “catch all” clause at the end permitting traffic, then it is dropped like an ACL would. Going through the 2-way Redistribution video, I also learned that sequence #’s do also work exactly like ACL’s, so you will want to plan your sequence #’s to leave room for further clauses either above or below their number.
So really on here I just want to demonstrate that the sequence # for clauses can be moved to adjust the route-map to work correctly come test day, or some unneeded policies may need to be removed to allow the route-map to work properly, and getting used to looking at just “sh route-map” output and being able to write out the clauses in sequence number is going to be crucial to know and understand.
So to get the party started, lets take a look at our current “sh route-map” output:
R3#sh route-map
route-map RIP2OSPF, permit, sequence 10
Match clauses:
ip address (access-lists): 5
Set clauses:
metric-type type-1
Policy routing matches: 0 packets, 0 bytes
route-map RIP2OSPF, permit, sequence 15
Match clauses:
ip address (access-lists): 15
Set clauses:
metric-type type-1
Policy routing matches: 0 packets, 0 bytes
R3#
So one important note here quick, route-map sequence numbers default to go upward in increments of 10, 20, etc. However, without knowing this, I put sequence 15 for the 172.12.15.0 networks clauses, which now leaves my only sequences 11-14 between them for additional clauses if needed – Be sure to leave yourself as much room as possible for additional clauses that may later need to be added!
So I am going to remove that number 15 and make it 20, and increment by the default # of 10 while labbing, to get into good route-map habits:
R3(config)#no route-map RIP2OSPF permit 15
R3(config)#route-map RIP2OSPF permit 20
R3(config-route-map)#match ip add 15
R3(config-route-map)#set metric-type type-1
R3(config-route-map)#do sh route-map
route-map RIP2OSPF, permit, sequence 10
Match clauses:
ip address (access-lists): 5
Set clauses:
metric-type type-1
Policy routing matches: 0 packets, 0 bytes
route-map RIP2OSPF, permit, sequence 20
Match clauses:
ip address (access-lists): 15
Set clauses:
metric-type type-1
Policy routing matches: 0 packets, 0 bytes
R3(config-route-map)#
So as can be seen making the change was quite easy, and I’ve highlighted the headers that show the sequence numbers of the route-map, and the clauses configured within them. Next I actually configured over my virtual-link RID for R3 making lo33 with network 33.33.33.0 on the last lab, which I have since fixed and added instead lo30 with network address 30.30.30.0 /24 and added it to the RIP domain.
So next I want to write this “catch-all clause” with a sequence number of 50, the sequence # for this type of clause is fairly arbitrary, but it must be higher than all other clause #’s:
R3(config-route-map)#route-map RIP2OSPF permit 50
R3(config-route-map)#
ASR#2
[Resuming connection 2 to r4 … ]
R4#sh ip route ospf
Gateway of last resort is not set
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/20] via 172.12.34.3, 00:00:21, FastEthernet0/1
O E1 5.0.0.0/8 [110/21] via 172.12.34.3, 02:10:10, FastEthernet0/1
30.0.0.0/24 is subnetted, 1 subnets
O E2 30.30.30.0 [110/20] via 172.12.34.3, 00:00:21, FastEthernet0/1
172.12.0.0/16 is variably subnetted, 7 subnets, 2 masks
O E1 172.12.15.0/24 [110/21] via 172.12.34.3, 00:10:41, FastEthernet0/1
O 172.12.33.3/32 [110/2] via 172.12.34.3, 02:11:31, FastEthernet0/1
O E2 172.12.123.0/24 [110/20] via 172.12.34.3, 00:00:21, FastEthernet0/1
R4#
And there are all our routes brought in by the catch-all clause. However, I’ve decided we don’t know need to see the 3.3.3.3 network anymore, so that is going bye bye:
R3(config)#do sh access-list
Standard IP access list 5
10 permit 5.0.0.0, wildcard bits 0.255.255.255 (6 matches)
Standard IP access list 15
10 permit 172.12.15.0, wildcard bits 0.0.0.255 (4 matches)
R3(config)#access-list 3 permit 3.3.3.3 0.0.0.0
R3(config)#route-map RIP2OSPF deny 30
R3(config-route-map)#match ip add 3
R3(config-route-map)#
ASR#2
[Resuming connection 2 to r4 … ]
R4#sh ip route ospf
Gateway of last resort is not set
O E1 5.0.0.0/8 [110/21] via 172.12.34.3, 02:15:38, FastEthernet0/1
30.0.0.0/24 is subnetted, 1 subnets
O E2 30.30.30.0 [110/20] via 172.12.34.3, 00:00:16, FastEthernet0/1
172.12.0.0/16 is variably subnetted, 7 subnets, 2 masks
O E1 172.12.15.0/24 [110/21] via 172.12.34.3, 00:16:09, FastEthernet0/1
O 172.12.33.3/32 [110/2] via 172.12.34.3, 02:16:59, FastEthernet0/1
O E2 172.12.123.0/24 [110/20] via 172.12.34.3, 00:00:16, FastEthernet0/1
R4#
***So there are a couple of important things to touch on with the above output. First when route-maps “match” to an ACL, it will increment as normal when it gets hits, and this is very important to know for troubleshooting route-map behaviors (highlighted in green). Second (as can be seen highlighted in blue) in the output, the ACL is made with a permit only to define the network, then it is denied when making the route-map sequence and “match” used to call out the ACL / Network(s) being denied.*** Important stuff!
So for network 30.30.30.0 /24 I am going to just adjust the metric itself to 99, cause I got 99 problems but route-maps ain’t one:
R3(config)#access-list 30 permit 30.30.30.0 0.0.0.255
R3(config)#route-map RIP2OSPF permit 40
R3(config-route-map)#match ip add 30
R3(config-route-map)#set metric 99
R3(config-route-map)#
ASR#2
[Resuming connection 2 to r4 … ]
R4#sh ip route ospf
Gateway of last resort is not set
O E1 5.0.0.0/8 [110/21] via 172.12.34.3, 02:28:55, FastEthernet0/1
30.0.0.0/24 is subnetted, 1 subnets
O E2 30.30.30.0 [110/99] via 172.12.34.3, 00:00:13, FastEthernet0/1
172.12.0.0/16 is variably subnetted, 7 subnets, 2 masks
O E1 172.12.15.0/24 [110/21] via 172.12.34.3, 00:29:26, FastEthernet0/1
O 172.12.33.3/32 [110/2] via 172.12.34.3, 02:30:16, FastEthernet0/1
O E2 172.12.123.0/24 [110/20] via 172.12.34.3, 00:13:33, FastEthernet0/1
R4#
Which given that is our last network I wanted to demonstrate with, the catch-all clause being sequence 50 was not planned to cap off the networks to use, but worked out as a great coincidence!
Now lets take a look at our “sh route-map” and see if we can break some stuff in this perfect world of route-map configurations going right every time:
R3#sh route-map
route-map RIP2OSPF, permit, sequence 10
Match clauses:
ip address (access-lists): 5
Set clauses:
metric-type type-1
Policy routing matches: 0 packets, 0 bytes
route-map RIP2OSPF, permit, sequence 20
Match clauses:
ip address (access-lists): 15
Set clauses:
metric-type type-1
Policy routing matches: 0 packets, 0 bytes
route-map RIP2OSPF, deny, sequence 30
Match clauses:
ip address (access-lists): 3
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map RIP2OSPF, permit, sequence 40
Match clauses:
ip address (access-lists): 30
Set clauses:
metric 99
Policy routing matches: 0 packets, 0 bytes
route-map RIP2OSPF, permit, sequence 50
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes
R3#
It shows what access-list it’s referencing, the clauses or lack there of, and life is good. However for mischief sake I want to permit that 3.3.3.3 network back into R4’s route table, so I am going to squeeze a command between sequence 20 and 30 permitting it and see if it negates the permit below it like I believe it should:
R3(config)#route-map RIP2OSPF permit 25
R3(config-route-map)#match ip add 3
R3(config-route-map)#set metric 99
R3(config-route-map)#
ASR#2
[Resuming connection 2 to r4 … ]
R4#sh ip route ospf
Gateway of last resort is not set
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/99] via 172.12.34.3, 00:00:11, FastEthernet0/1
O E1 5.0.0.0/8 [110/21] via 172.12.34.3, 02:39:25, FastEthernet0/1
30.0.0.0/24 is subnetted, 1 subnets
O E2 30.30.30.0 [110/99] via 172.12.34.3, 00:00:21, FastEthernet0/1
172.12.0.0/16 is variably subnetted, 7 subnets, 2 masks
O E1 172.12.15.0/24 [110/21] via 172.12.34.3, 00:39:56, FastEthernet0/1
O 172.12.33.3/32 [110/2] via 172.12.34.3, 02:40:46, FastEthernet0/1
O E2 172.12.123.0/24 [110/20] via 172.12.34.3, 00:24:03, FastEthernet0/1
R4#
It did work and I even snuck in a set metric 99 as a clause cause 3.3.3.3 ain’t got route-map problems either anymore, until I do this:
R3(config-route-map)#route-map RIP2OPF deny 5
R3(config-route-map)#
Ha! Take that OSPF thinking your such a cool protocol, and so fancier than RIP!…. Ahem. So lets confirm what we already know we are going to see on R4:
R4#clear ip route *
R4#sh ip route ospf
Gateway of last resort is not set
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/99] via 172.12.34.3, 00:00:06, FastEthernet0/1
O E1 5.0.0.0/8 [110/21] via 172.12.34.3, 00:00:06, FastEthernet0/1
30.0.0.0/24 is subnetted, 1 subnets
O E2 30.30.30.0 [110/99] via 172.12.34.3, 00:00:06, FastEthernet0/1
172.12.0.0/16 is variably subnetted, 7 subnets, 2 masks
O E1 172.12.15.0/24 [110/21] via 172.12.34.3, 00:00:06, FastEthernet0/1
O 172.12.33.3/32 [110/2] via 172.12.34.3, 00:00:06, FastEthernet0/1
O E2 172.12.123.0/24 [110/20] via 172.12.34.3, 00:00:06, FastEthernet0/1
R4#
ASR#1
[Resuming connection 1 to r3 … ]
R3(config-route-map)#do sh route-map
route-map RIP2OPF, deny, sequence 5
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes
Say whaaat? If you notice I did a “clear ip route *” on R4 because I thought the routes just had not kicked in yet, but sure enough there are all the routes and I even hopped back to R3 to confirm it’s first line is SUPPOSED to be the catch all of deny doom for this route-map. So I haven’t read or learned this through technical training yet, but I would bet that a deny statement requires some sort of criteria to deny on, so I am going to make a “catch all” ACL to go with our “ruin everyones good time” route-map sequence 5:
R3(config)#access-list 99 permit 0.0.0.0 0.0.0.0
R3(config)#route-map RIP2OSPF deny 5
R3(config-route-map)#match ip add 99
R3(config-route-map)#
ASR#2
[Resuming connection 2 to r4 … ]
R4#sh ip route ospf
Gateway of last resort is not set
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/99] via 172.12.34.3, 00:00:16, FastEthernet0/1
O E1 5.0.0.0/8 [110/21] via 172.12.34.3, 00:00:16, FastEthernet0/1
30.0.0.0/24 is subnetted, 1 subnets
O E2 30.30.30.0 [110/99] via 172.12.34.3, 00:00:16, FastEthernet0/1
172.12.0.0/16 is variably subnetted, 7 subnets, 2 masks
O E1 172.12.15.0/24 [110/21] via 172.12.34.3, 00:00:16, FastEthernet0/1
O 172.12.33.3/32 [110/2] via 172.12.34.3, 00:07:31, FastEthernet0/1
O E2 172.12.123.0/24 [110/20] via 172.12.34.3, 00:00:16, FastEthernet0/1
R4#
Okay, w, tf? Let’s see what our handy dandy “sh route-map” has to say on R3:
R3(config-route-map)#do sh access-list
Standard IP access list 3
10 permit 3.3.3.3 (7 matches)
Standard IP access list 5
10 permit 5.0.0.0, wildcard bits 0.255.255.255 (15 matches)
Standard IP access list 15
10 permit 172.12.15.0, wildcard bits 0.0.0.255 (13 matches)
Standard IP access list 30
10 permit 30.30.30.0, wildcard bits 0.0.0.255 (5 matches)
Standard IP access list 99
10 permit 0.0.0.0
R3(config-route-map)#do sh route-map
route-map RIP2OPF, deny, sequence 5
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map RIP2OSPF, deny, sequence 5
Match clauses:
ip address (access-lists): 99
Set clauses:
Policy routing matches: 0 packets, 0 bytes
AH HA! CISCO YOU SNAKE IN THE GRASS, YOU GOT ME AGAIN WITH THIS SAME BEHAVIOR AGAIN ON A COMPLETELY DIFFERENT CONFIG TYPE!
NEW RULE: BEFORE CONFIGURING SOMETHING NEW, COMPLETELY REMOVE ALL OLD CONFIGURATIONS OF IT, CONFIRM IT’S GONE AND ONLY THEN CONFIGURE THE NEW STATEMENT REPLACING IT:
R3(config-route-map)#no route-map RIP2OSPF deny 5
R3(config)#
I noticed this kicked me back to global config, so I am not sure if I just deleted the entire route-map which would end this lab session (woohoo!), I was actually wondering if I’d have to enter it twice for both sequence 5 statements we had in our show output. SO, why not see if we still have a route-map:
R3(config)#do sh route-map
route-map RIP2OPF, deny, sequence 5
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map RIP2OSPF, permit, sequence 10
Match clauses:
ip address (access-lists): 5
Set clauses:
metric-type type-1
Policy routing matches: 0 packets, 0 bytes
route-map RIP2OSPF, permit, sequence 20
Match clauses:
ip address (access-lists): 15
Set clauses:
metric-type type-1
Policy routing matches: 0 packets, 0 bytes
route-map RIP2OSPF, permit, sequence 25
Match clauses:
ip address (access-lists): 3
Set clauses:
metric 99
Policy routing matches: 0 packets, 0 bytes
route-map RIP2OSPF, deny, sequence 30
Match clauses:
ip address (access-lists): 3
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map RIP2OSPF, permit, sequence 40
Match clauses:
ip address (access-lists): 30
Set clauses:
metric 99
Policy routing matches: 0 packets, 0 bytes
route-map RIP2OSPF, permit, sequence 50
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes
R3(config)#
So fortunately it didn’t kill our entire route-map, I am guessing I was kicked back to global config because I was sitting in the sequences configuration, and that is also why the one matching an ACL is missing and not the first one on the list. So I will give 5 another delete, and reconfigure it with the ACL to see if we may finally ruin R4’s good times:
R3(config)#no route-map RIP2OSPF deny 5
% Could not find route-map entry RIP2OSPF 5
R3(config)#do show route-map
route-map RIP2OPF, deny, sequence 5
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes
…????!!!??!? I feel like calling Cisco TAC right now and demanding an answer, WHAT DO YOU MEAN YOU CANNOT FIND THE ROUTE-MAP ENTRY I’VE HIGHLIGHTED IN RED FOR YOUR CONVENIENCE YOU STUPID ROUTER???
Ok, so… I am not sure where to go from here, I will try configuring a second sequence 5 again referencing the ACL, and back out to global config before removing so hopefully it removes the first one instead of the one containing my ACL:
R3(config)#no route-map RIP2OSPF deny 5
R3(config)#do sh route-map
route-map RIP2OPF, deny, sequence 5
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes
Ok, this is getting old so to prove my points about whether or not we can issue a deny all catch all at the top, I am moving it to the top of the route-map sequence numbers:
R3(config)#route-map RIP2OSPF deny 1
R3(config-route-map)#match ip add 99
R3(config-route-map)#
ASR#2
[Resuming connection 2 to r4 … ]
R4#sh ip route ospf
Gateway of last resort is not set
3.0.0.0/32 is subnetted, 1 subnets
O E2 3.3.3.3 [110/99] via 172.12.34.3, 00:00:05, FastEthernet0/1
O E1 5.0.0.0/8 [110/21] via 172.12.34.3, 00:00:05, FastEthernet0/1
30.0.0.0/24 is subnetted, 1 subnets
O E2 30.30.30.0 [110/99] via 172.12.34.3, 00:00:05, FastEthernet0/1
172.12.0.0/16 is variably subnetted, 7 subnets, 2 masks
O E1 172.12.15.0/24 [110/21] via 172.12.34.3, 00:00:05, FastEthernet0/1
O 172.12.33.3/32 [110/2] via 172.12.34.3, 00:29:38, FastEthernet0/1
O E2 172.12.123.0/24 [110/20] via 172.12.34.3, 00:00:05, FastEthernet0/1
R4#
So I wrote off this behavior as perhaps being something that cannot be issued before a permit statement, so I configured sequence 11 with the same criteria, and still a full route table. So here is my final theory:
Like route tables and distribute-lists, route-maps will search the sequences for the longest match to it’s criteria before applying the clause, so because they route-map statements are fine tuned to specific networks (mostly) it is ignoring this catch-all at the beginning because it is finding longer / better matches down the sequence lines.
So that would also validate why the catch-all clause works, because if there is no specific sequence number for additional routes being redistributed, it just permits them.
However, having two sequence 5’s when I was trying to add the ACL to the existing sequence 5, and then the router saying there is no sequence 5 when there clearly will be something I hope to learn down the road cause I am fried for tonight.
Coming up is some very good concepts with route leaking and route loop prevention using route tagging for 2-way redistribution. It can quickly become more an IE level topic of configuration, but learning the fundamentals of route-map tagging and the theory was very interesting and I’m eager to lab it up!
I will just turn the lab off without the wr mem, as tomorrow, we 2-way redistribute with route-map tagging in full force 🙂
The DEVNET GRIND! 