Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Route map question.

Status
Not open for further replies.

Giant99

Technical User
Sep 19, 2008
22
GB
In the Cisco BSCI official exam cert guide it states;

'Traffic that matches a permit is affected by the route map, traffic that matches a deny or does not find a match in the list is not affected by the route map'.

This does not make sense to me. If traffic matches a deny it should be denied. This means it is affected by the route map.

Am I missing something?
 
A route map isn't necessarily denying traffic, but it is being used to set parameters.

For instance, with BGP, you can use a route-map to append the ASpath to one network but not another. The packets that do not match, do not get modified or appended, so they are not affected by the route map.

Clear as mud?

 
This is kind of like NAT---any address that matches a permit is affected by the acl, but any that does not simply does not get natted---it is still allowed through, though the acl may say to deny it. Since route maps are used for setting parameters as Todd stated, then the deny statements mean that (let's say a route map for NAT) the addresses that are not matched simply do not get natted, or whatever else the route map is used for.
When I build a VPN in a router, I always use addresses from the LAN for the vpn pool. For me to be able to remote connect to nodes once the vpn is established, I must deny the vpn addresses from being natted. I do this with a route map...I use 10.68.68.69 and 10.68.68.70 as my vpn addresses, and the LAN is 10.68.68.0/24

ip local pool vpn_pool_1 10.68.68.69 10.68.68.70

Then I create an acl for NAT that denies the vpn pool and allows everything else in the LAN subnet...

access-list 101 deny ip any 10.68.68.68 0.0.0.3
access-list 101 permit ip 10.68.68.0 0.0.0.255 any

I make the route map...

route-map nat permit 1
match address 101

Then the NAT statement...

ip nat inside source route-map nat int di1 overload

So addresses 10.68.68.69 and 10.68.68.70 are not natted, yet they are obviously permitted for the vpn to connect. The route-map itself is only concerned with what gets natted and what does not, since it is pointed to acl 101, and acl 101 is used in the nat statement. THEREFORE...


'Traffic that matches a permit is affected by the route map, traffic that matches a deny or does not find a match in the list is not affected by the route map'.

Burt
 
Sweet setup Burt!
I read another post where the guy did the same thing basically and it makes more sense now! Strange to run into it here after reading just a few days ago (Was studying PVLANs)...


With PVLANs you could do the same setup but place every host you wanted to in a separate Private-VLAN and only use one /24 in stead of a more complex subnetting solution like /30's for your servers etc.

Really liking the PVLANs plus they are so easy to configure! Looked difficult at first but really not that bad!

B Haines
CCNA R&S, ETA FOI
 
Yeah---you could actually NAT this way or without even introducing a route map---works the same way. I'm just complicated like that...
TAD! Where are you? Where have you been? Haven't heard from you in a bit!

Burt
 
Hi Burt,

Still around, just doing winter prep chores for the farm...cutting firewood, insulating, repairing plumbing and some electrical stuff, drywalling, etc. Have to get my workshop up to snuff so I can reinstall my racks of gear and hunker down for the CCIE R&S lab. Plus prepping for exams for several courses I need to refresh for instructor credentials. Not much posting time since you guys are doing a great job!

Anyway, route maps are funky in their behavior depending on the context. Most uses have the permit and deny to identify what will actually be manipulated by the route map. They are like the Swiss Army knife of networking.

Back to lurking!

 
Did someone say dragoons?

B Haines
CCNA R&S, ETA FOI
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top