if you use a blank permit at the end of the statement for PBR you are going to cause unnecessary processing on the router for unmatched traffic that meets the requirements of the last statement which has no requirements. All traffic must then be processed and put back to normal routing as there is no ACL or next hop change. Never do this.
But I am going to re-copy my last email to hopefully clarify this and to give to other new-comers on the list. Kingsley, It depends on what you are using it for. Some situations you will use a trailing route-map to permit additional traffic. Sometimes you won't because you are only matching on a specific condition. for instance with route redistribution route-map TAG permit 10 match tag 86 If I only wanted to match on tag 86 for being redistributed I would only have that one statement But if I only wanted to filter if it had tag 86 then I would route-map TAG deny 10 match tag 86 route-map TAG permit 20 This would permit anything that doesn't have the tag 86. These are two basic examples. There are many different reasons why you would or would not want to use a route-map without any data. One other I may want to add tag 86 for network 10.1.1.0/24 and permit everything else access-list 1 permit 10.1.1.0 0.0.0.255 route-map TAG permit 10 match access-list 1 set tag 86 route-map TAG permit 20 I could go on and on like this with many different situations. So the answer is it depends. Just like with vlan-maps it really does depend. It is not a set rule that you should add the last one with an action of forward, (although it is typically recommended.) Regards, Tyson Scott - CCIE #13513 R&S, Security, and SP Managing Partner / Sr. Instructor - IPexpert, Inc. Mailto: <mailto:[email protected]> [email protected] Telephone: +1.810.326.1444, ext. 208 Live Assistance, Please visit: <http://www.ipexpert.com/chat> www.ipexpert.com/chat eFax: +1.810.454.0130 IPexpert is a premier provider of Self-Study Workbooks, Video on Demand, Audio Tools, Online Hardware Rental and Classroom Training for the Cisco CCIE (R&S, Voice, Security & Service Provider) certification(s) with training locations throughout the United States, Europe, South Asia and Australia. Be sure to visit our online communities at <http://www.ipexpert.com/communities> www.ipexpert.com/communities and our public website at <http://www.ipexpert.com/> www.ipexpert.com From: Kingsley Charles [mailto:[email protected]] Sent: Wednesday, June 02, 2010 10:13 AM To: Tyson Scott Cc: OSL Security Subject: Re: route-maps Hi Tyson I have already brought this topic but again want to discuss this. With respect to CCIE security, I see the following areas where we use route-maps Route distribution using redistribute command with route-maps Route filtering using distribute command with route-maps PBR As the end, do we need add a dummy with permit as route-map <name> permit With PBR, I don't thing it will have an effect. If you don't have it, it will go for normal destination based routing. If you have it, since, there is no match statement, again it goes for normal routing. For filtering and redistribution, do we need to dummy permit rule? If we have that what will be the effect. Please do explain the effect of having and not having the dummy permit statement for PBR, router filtering and redistribution. What should we follow from exam point of view? With regards Kings On Wed, Jun 2, 2010 at 7:32 PM, Tyson Scott <[email protected]> wrote: Just wanted to clarify as I was unsure on one of your statements below. Regards, Tyson Scott - CCIE #13513 R&S, Security, and SP Managing Partner / Sr. Instructor - IPexpert, Inc. Mailto: [email protected] Telephone: +1.810.326.1444, ext. 208 Live Assistance, Please visit: www.ipexpert.com/chat eFax: +1.810.454.0130 IPexpert is a premier provider of Self-Study Workbooks, Video on Demand, Audio Tools, Online Hardware Rental and Classroom Training for the Cisco CCIE (R&S, Voice, Security & Service Provider) certification(s) with training locations throughout the United States, Europe, South Asia and Australia. Be sure to visit our online communities at www.ipexpert.com/communities and our public website at www.ipexpert.com <http://www.ipexpert.com/> From: Kingsley Charles [mailto:[email protected]] Sent: Wednesday, June 02, 2010 10:01 AM To: Tyson Scott Cc: Jimmy Larsson; OSL Security Subject: Re: [OSL | CCIE_Security] Routing when doing IOS L2L I agree Tyson. On Wed, Jun 2, 2010 at 6:24 PM, Tyson Scott <[email protected]> wrote: Kings, when you say apply it globally I assume you mean "ip local policy". This only affects traffic generated by the router. The reason this is necessary is traffic originated by the router is originated from the control plane. PBR applied to an interface affects traffic from the data plane on the ingress of the interface. Thus router generated traffic can never meet this category. Interface PBR = ingress on an interface defined by your ACL in the route-map. local PBR = router generated traffic defined by your ACL. Both of these are shown in example in the Video on Demand but I don't think I call it out as a specific topic. I use them to overcome some routing problems over the DMVPN. Regards, Tyson Scott - CCIE #13513 R&S, Security, and SP Managing Partner / Sr. Instructor - IPexpert, Inc. Mailto: [email protected] Telephone: +1.810.326.1444, ext. 208 Live Assistance, Please visit: www.ipexpert.com/chat eFax: +1.810.454.0130 IPexpert is a premier provider of Self-Study Workbooks, Video on Demand, Audio Tools, Online Hardware Rental and Classroom Training for the Cisco CCIE (R&S, Voice, Security & Service Provider) certification(s) with training locations throughout the United States, Europe, South Asia and Australia. Be sure to visit our online communities at www.ipexpert.com/communities and our public website at www.ipexpert.com <http://www.ipexpert.com/> From: [email protected] [mailto:[email protected]] On Behalf Of Kingsley Charles Sent: Wednesday, June 02, 2010 4:31 AM To: Jimmy Larsson Cc: OSL Security Subject: Re: [OSL | CCIE_Security] Routing when doing IOS L2L Hi Jimmy You can find reverse-route under crypto maps. This was brought in for redundancy. The route for remote networks will be always pointing the peer. You need not configure the routers manually. With this, you need worry about the route it takes to the peer. The "set reverse-route" route was introduced later with IPSec profiles. This allows to set tag and distance. Very useful for DVTI based VPN, where you can redistribute using the tag. When you apply route-maps to the interface it impacts that interface alone. With configured globally, it impacts all interfaces. For the problem, try this On R1, you don't have a peer as it is a dynamic crypto map, "reverse-route static" won't work Just add "reverse-route" which will automatically find the peer and add the route for 2.2.2.2 or configure "reverse-route remote peer 172.16.1.1" with or without static option. or configure ip route 2.2.2.2 255.255.255.255 172.16.1.1 This should work. PBR is too sophisticated solution for this issue :-) With regards Kings On Wed, Jun 2, 2010 at 2:14 AM, Jimmy Larsson <[email protected]> wrote: TacAck: The difference in route-maps between my trial and your successfull example was that I was doing "set interface fa0/0" while you did "set ip next-hop 172.16.1.1". when doing it your way it works great. Tyson: I understand that route-maps is not the most beautiful way of solving things. Now I have tried it and will put that tool in the bottom of my tool-bag. Whats the difference between applying route-maps on interface and "local"? Do you have a good DocCD-link that I can read about route-maps? I am not a r/s-guy (yet) and it´s quite new to me. And NOW I finally understand the difference between "reverse-route" and "set reverse-route <options>"-statements! I saw them as 2 different ways of doing RRI but couldnt understand the difference. But when looking in the command reference I see that "reverse-route" is the only command that ENABLES RRI, the "set reverse-route" just tweaks the behaviour by changing distance and so on. Cool! This is cool! -- ------- Jimmy Larsson Ryavagen 173 s-26030 Vallakra Sweden http://blogg.kvistofta.nu ------- _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.819 / Virus Database: 271.1.1/2913 - Release Date: 06/02/10 05:57:00 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.819 / Virus Database: 271.1.1/2913 - Release Date: 06/02/10 05:57:00
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
