Policy based routing on VRF interfaces to route traffic through TE Tunnel

Hi All,
Is there a method to do policy based routing on VRF interfaces and route data traffic through one TE tunnel and non-data traffic through another TE tunnel.
The tunnel is already build up with these below config
interface Tunnel25
ip unnumbered Loopback0
tunnel destination 10.250.16.250
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng path-option 10 explicit name test
ip explicit-path name test enable
next-address x.x.x.x
next-address y.y.y.y
router ospf 1
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 0
mpls traffic-eng tunnels
nterface GigabitEthernet5/2
mpls traffic-eng tunnels
mpls ip
Is there additional config needed to work ,also in the destination end for the return traffic,we want to use the normal PATH --I mean non TE tunnel.
We tested with the above scenario,but couldn't able to reach the destination.Meantime we had a question,when the packet uses the policy map while ingress,it may not know the associatuion with VRF(Is that right? --If so ,how to make it happen)
Any help would be really appreciated
Thanks
Regards
Anantha Subramanian Natarajan

hi Anantha!
I might not be the right person to comment on your first question. I have not configured MVPNs yet and not very confertable with the topic.
But I am sure that if you read through the CBTS doc thoroughly, you might be able to derive the answer yourself. One thing I notice is that " a Tunnel will be selected regularly according to the routing process (even isf it is cbts enabled). From the tunnels selected using the regular best path selection, the traffic is mapped to a perticular tunnel in the group if specific class is mapped to that tunnel.
So a master tunnel can be the only tunnel between the 2 devices over which the routing (bgp next hops) are exchanged and all other tunnels can be members of this tunnel. So your RPF might not fail.
You might have to explore on this a bit more and read about the co-existance of multicast and TE. This will be the same as that.
For your second question, the answer would be easy :
If you want a specific eompls cust to take a particular tunnel/path, just create a seperate pair of loopbacks on the PEs. Make the loopback learnt on the remote PE through the tunnel/path that you want the eompls to take. Then establish the xconnect with this loopback. I am assuming that your question is that a particular eompls session should take a particular path.
If you meant that certain traffic from the same eompls session take a different path/tunnel, then CBTS will work.
Regards,
Niranjan

Similar Messages

Policy Based Routing with VPN Client configuration

Hi to all,
We have a Cisco 2800 router in our company that also serves as a VPN server. We use the VPN Client to connect to our corporate network (pls don't laugh, I know that it is very obsolete but I haven't had the time lately to switch to SSL VPN).
The router has two WAN connections. One is the primary wan ("slow wan" link with slower upload 10D/1U mbps) and it is used for the corporate workstations used by the emploees. The other is our backup link. It has higher upload speed - 11D/11U mbps, (fast wan), and thus we also use the high upload link for our webserver (I have done this using PBR just for the http traffic from the webserver). For numerous other reasions we can not use the `fast wan` connection as our primary connection and it is used anly as a failover in case the primary link fails.
The `fast wan` also has a static IP address and we use this static IP for the VPN Client configuration.
Now the thing is that because of the failover, when we connect from the outside using the VPN Client, the traffic comes from the`fast wan` interface, but exits from the `slow wan` interface. And because the `slow wan` has only 1mbps upload the vpn connection is slow.
Is there any way for us to redirect the vpn traffic to always use the `fast wan` interface and to take advantage of the 11mbps upload speed of that connection?
This is our sanitized config
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp client configuration group dc
key ***
dns 192.168.5.7
domain corp.local
pool SDM_POOL_1
acl 101
max-users 3
netmask 255.255.255.0
crypto isakmp profile sdm-ike-profile-1
   match identity group dc
   isakmp authorization list sdm_vpn_group_ml_1
   client configuration address respond
   virtual-template 1
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto ipsec profile SDM_Profile1
set security-association idle-time 3600
set transform-set ESP-3DES-SHA
set isakmp-profile sdm-ike-profile-1
interface Loopback0
ip address 10.10.10.1 255.255.255.0
interface FastEthernet0/0
description *WAN*
no ip address
ip mtu 1396
duplex auto
speed auto
interface FastEthernet0/0.3
description FAST-WAN-11D-11U
encapsulation dot1Q 3
ip address 88.XX.XX.75 255.255.255.248
ip load-sharing per-packet
ip nat outside
ip virtual-reassembly
interface FastEthernet0/0.4
description SLOW-WAN-10D-1U
encapsulation dot1Q 4
ip address dhcp
ip nat outside
ip virtual-reassembly
no cdp enable
interface FastEthernet0/1
description *LOCAL*
no ip address
ip virtual-reassembly
duplex auto
speed auto
interface FastEthernet0/1.10
description VLAN 10 192-168-5-0
encapsulation dot1Q 10
ip address 192.168.5.1 255.255.255.0
ip nat inside
ip virtual-reassembly max-reassemblies 32
no cdp enable
interface FastEthernet0/1.20
description VLAN 20 10-10-0-0
encapsulation dot1Q 20
ip address 10.10.0.254 255.255.255.0
ip access-group PERMIT-MNG out
ip nat inside
ip virtual-reassembly
!!! NOTE: This route map is used to PBR the http traffic for our server
ip policy route-map REDIRECT-VIA-FAST-WAN
no cdp enable
interface Virtual-Template1 type tunnel
ip unnumbered Loopback0
tunnel mode ipsec ipv4
tunnel protection ipsec profile SDM_Profile1
interface Virtual-Template3
no ip address
interface Virtual-Template4
no ip address
ip local pool SDM_POOL_1 192.168.5.150 192.168.5.152
ip forward-protocol nd
!!! SLOW-WAN NEXT HOP DEFAULT ADDRESS
ip route 0.0.0.0 0.0.0.0 89.XX.XX.1 5
!!! FAST-WAN NEXT HOP DEFAULT ADDRESS
ip route 0.0.0.0 0.0.0.0 88.XX.XX.73 10
ip nat inside source route-map FAST-WAN-NAT-RMAP interface FastEthernet0/0.3 overload
ip nat inside source route-map SLOW-WAN-NAT-RMAP interface FastEthernet0/0.4 overload
access-list 101 remark SDM_ACL Category=4
access-list 101 permit ip 192.168.5.0 0.0.0.255 any
access-list 101 permit ip 10.10.0.0 0.0.0.255 any
ip access-list extended FAST-WAN-NAT
permit tcp 192.168.5.0 0.0.0.255 range 1025 65535 any
permit udp 192.168.5.0 0.0.0.255 range 1025 65535 any
permit icmp 192.168.5.0 0.0.0.255 any
permit tcp 10.10.0.0 0.0.0.255 range 1025 65535 any
permit udp 10.10.0.0 0.0.0.255 range 1025 65535 any
permit icmp 10.10.0.0 0.0.0.255 any
ip access-list extended REDIRECT-VIA-FAST-WAN
deny   tcp host 10.10.0.43 eq 443 9675 192.168.5.0 0.0.0.255
permit tcp host 10.10.0.43 eq 443 9675 any
ip access-list extended SLOW-WAN-NAT
permit ip 192.168.5.0 0.0.0.255 any
permit ip 10.10.0.0 0.0.0.255 any
route-map FAST-WAN-NAT-RMAP permit 10
match ip address FAST-WAN-NAT
match interface FastEthernet0/0.3
route-map REDIRECT-VIA-FAST-WAN permit 10
match ip address REDIRECT-VIA-FAST-WAN
set ip next-hop 88.XX.XX.73
route-map SLOW-WAN-NAT-RMAP permit 10
match ip address SLOW-WAN-NAT
match interface FastEthernet0/0.4

Can you try to use PBR Match track object,
Device(config)# route-map abc
Device(config-route-map)# match track 2
Device(config-route-map)# end
Device# show route-map abc
route-map abc, permit, sequence 10
Match clauses:
track-object 2
Set clauses:
Policy routing matches: 0 packets, 0 bytes
Additional References for PBR Match Track Object
This feature is a part of IOS-XE release 3.13 and later.
PBR Match Track Object
Cisco IOS XE Release 3.13S
The PBR Match Track Object feature enables a device to track the stub object during Policy Based Routing.
The following commands were introduced or modified: match track tracked-obj-number
Cheers,
Sumit

Policy based routing giving a headache

I have two internet connections on an 1841, through ethernet. I'm using subinterfaces. I have two default routes with floating static.
ip route 0.0.0.0 0.0.0.0 Y.Y.Y.209 5
ip route 0.0.0.0 0.0.0.0 X.X.X.65 10
When I remove the first route at weight 5, everything fails over properly and I can ping the x.x.x.65 address.
However if the first y.y.y.209 is in the routing table I cannot ping x.x.x.65 correctly.
Which of course I need one system within the LAN to route over that other connection. So I have setup a PBR statement, but seemingly since I cannot ping that next hop, (from the router or the server, it doesn't work.)
I see the policy-map matching the traffic coming from the server, but I just can't ping that other hop when the first default route is in place. Have gotten something similar to this working before on a 1760, but for whatever reason can't ping the second hop, on this 1841. Here's a config. I would have the expectation that I could ping both default gateways, since they are technically on the same subnet.
ip cef
no ip dhcp use vrf connected
no ip domain lookup
interface FastEthernet0/0
description PORT to DMZ VLAN
ip address 172.16.20.2 255.255.255.0
ip nat inside
ip policy route-map stn_util
no ip mroute-cache
duplex auto
speed auto
interface FastEthernet0/1
description PORT to TRUNK for MPOWER/COMCAST
no ip address
duplex auto
speed auto
interface FastEthernet0/1.30
description PORT to MPOWER
encapsulation dot1Q 30
ip address X.X.X.115 255.255.255.192
ip verify unicast reverse-path
ip nat outside
no ip mroute-cache
no snmp trap link-status
interface FastEthernet0/1.40
description PORT to COMCAST
encapsulation dot1Q 40
ip address Y.Y.Y.210 255.255.255.240
ip verify unicast reverse-path
ip nat outside
no ip mroute-cache
no snmp trap link-status
ip classless
ip route 0.0.0.0 0.0.0.0 Y.Y.Y.209 5
ip route 0.0.0.0 0.0.0.0 X.X.X.65 10
no ip http server
ip http authentication local
ip http timeout-policy idle 60 life 86400 requests 10000
ip nat inside source route-map NAT1-MPOWER interface FastEthernet0/1.30 overload
ip nat inside source route-map NAT2-COMCAST interface FastEthernet0/1.40 overloa
d
ip nat inside source static 172.16.20.1 Y.Y.Y.211 route-map NAT2-Static-COMC
AST
ip nat inside source static 172.16.20.10 Y.Y.Y.212 route-map NAT2-Static-COM
CAST
ip nat inside source static 172.16.20.11 Y.Y.Y.213 route-map NAT2-Static-COM
CAST
ip nat inside source static 172.16.20.12 Y.Y.Y.214 route-map NAT2-Static-COM
CAST
ip nat inside source static 172.16.20.12 X.X.X.112 route-map NAT1-Static-MP
OWER
ip nat inside source static 172.16.20.10 X.X.X.113 route-map NAT1-Static-MP
OWER
ip nat inside source static 172.16.20.11 X.X.X.114 route-map NAT1-Static-MP
OWER
access-list 150 permit ip host 172.16.20.12 any
access-list 160 remark DYNAMIC NAT
access-list 160 deny ip host 172.16.20.1 any
access-list 160 deny ip host 172.16.20.10 any
access-list 160 deny ip host 172.16.20.11 any
access-list 160 deny ip host 172.16.20.12 any
access-list 160 permit ip 172.16.20.0 0.0.0.255 any
access-list 170 remark STATIC NATS
access-list 170 permit ip host 172.16.20.1 any
access-list 170 permit ip host 172.16.20.10 any
access-list 170 permit ip host 172.16.20.11 any
access-list 170 permit ip host 172.16.20.12 any
access-list 170 deny ip 172.16.20.0 0.0.0.255 any
route-map NAT2-COMCAST permit 10
match ip address 160
match interface FastEthernet0/1.40
route-map NAT2-Static-COMCAST permit 10
match ip address 170
match interface FastEthernet0/1.40
route-map stn_util permit 10
description change UTIL server default route
match ip address 150
set ip next-hop X.X.X.65
route-map NAT1-Static-MPOWER permit 10
match ip address 170
match interface FastEthernet0/1.30
route-map NAT1-MPOWER permit 10
match ip address 160
match interface FastEthernet0/1.30

It depends on the result. Compare the output for the attached network from sh ip route and sh ip cef.
You can also run debug arp and try some pings, does it send requests? replies?
Which version of IOS are you running? Older versions had issues between CEF and route-maps. You can try to disable CEF.
You do not have an "ip local policy" configured?
I know it is not in what you attaced but it does not look complete.

Policy Based Routing - set ip next-hop

All,
I am trying to change the next hop for selective traffic to route via a WAN optimiser rather than follow the default route. I am trying to achieve this on a 4506 with IOS 12.2(20)EW.
I have configured an ACL intended to capture traffic from my desired subnet, to my desired subnet:
ip access-list extended INTER-STOR permit ip 192.168.XX.0 0.0.0.128 192.168.YY.0 0.0.0.128 log
I have then created the route map:
route-map WAN-OPT permit 10 match ip address INTER-STOR set interface Vlan1 set ip next-hop 192.168.XX.50
I have tested both with and without setting the interface. Neither make any difference.
I am then applying the route map policy to the vlan in which the traffic I wish to re-route is originating.
ip policy route-map WAN-OPT
I am finding however that this configuration doesn't work.
I have reviewed a number of documents and can not find any limitations based on the version of IOS I am using or my configuration.
This switch performs the routing for this environment, however there are no interfaces assigned to this vlan for anything other than testing on this switch. They are assigned on a stack on 3750's running as a VTP client. Again - testing from a port in the relevant vlan on this switch doing the routing (4500) does not change the results. The traffic continues to be routed the via the default route.
I'm not so sure that it is even the route map that has the problem as if I look at the access lists I can not see any hits being registered. I'm not sure whether this is a red-herring or not as I can't see what is wrong with the ACL or anything to suggest this ACL would not be supported.
If anybody can offer any guidance or suggestions it would be very much appreciated.
Thanks,

Below is the "offical" explanation, I have bolded and underlined ESTENTIAL information:-
set ip next-hop
•Specifies the next hop for which to route the packet (the next hop must be adjacent). This behavior is identical to a next hop specified in the normal routing table.
set interface
•Sets output interface for the packet. This action specifies that the packet is forwarded out of the local interface. The interface must be a Layer 3 interface (no switchports), and the destination address in the packet must lie within the IP network assigned to that interface. If the destination address for the packet does not lie within that network, the packet is dropped.
set ip default next-hop
•Sets next hop to which to route the packet if there is no explicit route for this destination. Before forwarding the packet to the next hop, the switch looks up the packet's destination address in the unicast routing table. If a match is found, the packet is forwarded by way of the routing table. If no match is found, the packet is forwarded to the specified next hop.
set default interface
•Sets output interface for the packet if there is no explicit route for this destination. Before forwarding the packet to the next hop, the switch looks up the packet's destination address in the unicast routing table. If a match is found, the packet is forwarded via the routing table. If no match is found, the packet is forwarded to the specified output interface. If the destination address for the packet does not lie within that network, the packet is dropped.
HTH>

Policy based routing

Hello,
I am setting up PBR. Looking at my configuration, will the next hop apply for both access lists 100 and 101? or will access-list 101 use 192.168.0.1 as the next up? I was hoping acl 101 will use 10.10.10.1 as next up.
router configuration:
route-map policy-based-routing permit 10
match ip address 100
set ip next-hop 192.168.10.1
route-map policy-based-routing permit 20
match ip address 101
set ip next-hop 10.10.10.1
access-list 100 permit ip 10.10.10.0 0.0.0.255 192.168.10.0 0.0.0.255
access-list 100 deny ip 10.10.10.0 0.0.0.255 any
access-list 101 permit ip 10.10.10.0 0.0.0.255 any
access-list 101 deny ip any any
ip route 0.0.0.0 0.0.0.0 10.10.10.1

Paul,
All you need is the following configuration.
route-map policy-based-routing permit 10
match ip address 100
set ip next-hop 192.168.10.1
access-list 100 permit ip 10.10.10.0 0.0.0.255 192.168.10.0 0.0.0.255
ip route 0.0.0.0 0.0.0.0 10.10.10.1
with the above configuration applied to the correct incoming interface, all traffic from 10.10.10.0 destined to 192.168.10.0 will use the next hop from the route map and all other traffic wil use the default route
HTH
Narayan

Policy based routing on a Layer 3 switch

I am doing some lab testing on policy based routing. I am having some issues that I can't see to get working right.
Here is the config:
ip local policy route-map Test-map
ip access-list extended icmp
permit icmp 192.168.1.0 0.0.0.255 192.168.200.0 0.0.0.255
permit icmp 192.168.2.0 0.0.0.255 192.168.200.0 0.0.0.255
ip access-list extended telnet
permit tcp 192.168.1.0 0.0.0.255 192.168.200.0 0.0.0.255 eq telnet
permit tcp 192.168.2.0 0.0.0.255 192.168.200.0 0.0.0.255 eq telnet
ip access-list extended test
permit icmp 192.168.1.0 0.0.0.255 192.168.200.0 0.0.0.255
route-map Test-map permit 10
match ip address icmp
set ip next-hop 192.168.1.3
route-map Test-map permit 20
match ip address telnet
set ip next-hop 192.168.1.2
The first thing I did was I only had 1 network on this box the 192.168.1.x and when I plugged a pc into a port on the switch and tried to ping the remote network of 192.168.200.1 it will not hit on my access-lists for my policy based routes.
If I do a ping from the switches IOS interface directly the access-lists get hits and the policy based routes work fine.
So I was puzzled by this and figured maybe policy based routes only work if they come from one network to another network. So I setup a 2nd vlan called 192.168.2.x and put my pc in that vlan. I then proceed to ping 192.168.200.1 and still was unable to get any hits on the access-lits or policy based routes.
So what am I doing wrong or am I trying to use policy based routing wrong here?

I've done that command but then when I do a "show run" I don't see it in the configuration and it doesn't seem to be working.
Also if everything is on the same vlan 100 will the pbr work? or does this require that I use two different vlans? (one for inside and one for outside) so that I have a interface from where the packets are coming from?

WSA and Cisco Policy Based Routing

I'm looking to convert my WSA from explicit to transparent proxy using policy based routing on a Cisco router. See the config below where xxx.xxx.xxx.xxx is the P1 interface on the WSA. Does anyone see any issues with the following in a production environment?
access-list 110 permit tcp any any eq www
route-map proxy-redirect permit 10
match ip address 110
set ip next-hop xxx.xxx.xxx.xxx
interface ethernet0/1
ip policy route-map proxy-redirect
The P1 interface on the WSA is located upstream from the router so I'm not checking for it in the ACL.

That router configuration looks good to me, but just make sure that the WSA was configured for Transparent mode during the initial System Setup Wizard configuration. If it was initially configured for explicit only, then you will need to run the wizard again to change it to transparent.
Also, make sure to add a deny statement to the top of access-list 110 for the WSA IP address if the WSA will be going out to the Internet through the same e0/1 interface. Loops are bad. :twisted:
Cheers,
Jason

Introduce second default gateway into policy-based routing and optimization

Questions:
1) How to get the second PBR_DEFAULT_GATEWAY address 10.20.20.3 into the policy-based routing for redundancy?
2) Any optimizations as more and more traffic (policy-based routed and otherwise) goes through interface Gi1/0/1?
Address range A.B.0.0/16 represents assigned Internet-routable addresses.
Network also uses 10.0.0.0/8, 172.16.0.0/20, 192.168.0.0/16.
DEFAULT_GATEWAY router participates in OSPF and injects the default routes 0.0.0.0/0 10.10.10.1 and 0.0.0.0/0 10.20.20.1 into OSPF.
PBR_DEFAULT_GATEWAY router participates in OSPF but filters out default routes injected by DEFAULT_GATEWAY router.
ROUTER_A participates in OSPF and receives default routes injected by DEFAULT_GATEWAY router.
ROUTER_A contains the attached policy-routing configuration that allows the subnet A.B.30.0/24 to route anywhere on the network and uses PBR_DEFAULT_GATEWAY as the way out.

Ok I will see if I can run out to work and try this today..
After thinking about this, If I need to get to local ip addresses (192.168.1.0 and 192.168.128.0), I might have to change my route map to include those ranges in an ACL, then assign the 172.20.200.1 as the gateway to get to those networks, with the last statement being the traffic to be sent out the firewall
for instance
# Access to one of my local networks
access-list 101 permit ip 172.20.200.0 0.0.0.255 192.168.1.0 0.0.0.255
# Send Internet traffic to ASA/PIX
access-list 172 permit ip 172.20.200.0 0.0.0.255 any
route-map pix-172-20-200 permit 10
match ip address 101
set ip next-hop 172.20.200.1
route-map pix-172-20-200 permit 20
match ip address 172
set ip next-hop 172.20.200.2
and so on?
I know I need to be in front of my switch to test the change from set ip default next-hop to set ip next-hop...
I wantto make sure I can still get to the local networks I need to get to.
I appreciate all your help, and I will test this later on today..
Thanks
Don Hickey

SRP527-U Policy Based Routing To Squid?

Hi,
I have a SRP527-U running 1.2.6.
I have a simple setup, a ADSL connection to the Internet and a bunch of PC's behind that with Internet access.
I've setup a host on the same VLAN as the other devices and I've set it up running squid.
What I'd like to do is use the Policy Based Routing function to force all users trying to browse the Internet through that squid instance.
That is
Source of 192.168.0.20/32 Port 80 -> Policy Based Route to Destination of 192.168.0.50 port 3128
Is that possible with this device, or is that outside of its capabilities? I've looked at the PBR section, but it seems to imply forcing all traffic out through a WAN Interface which isn't what I want to achieve.
Kind Regards,
Tim

Scott
If the destination IP is in the same subnet as source IP then it won't be routed it will be L2 switched so it would never use the default gateway ie.
src IP 172.21.1.10 255.255.255.0
dst IP 172.21.1.237 255.255.255.0
src compares it's own IP with it's subnet mask and sees it is on the 172.21.1.x network. src then compares the destination IP with it's own subnet mask and sees it is also on the 172.21.1.x network so it simply arps out for that address and when it gets the mac address it sends it direct to the destination. It would only use the default gateway if the destination IP was on a different network.
So i don't see how you will be able to do this and i'm not sure why you are seeing hits in your PBR acl for the host in the 172.21.1.x network.
Edit - what exactly do you mean when you say -
However when im in vlan 802 my host traffic never gets to 172.21.1.237 when pointed at the gateway 172.21.1.1.
How are you doing this ie. pointing it to the default gateway because as i say it should always be able to communicate with 172.21.1.237 as it is in the same subnet.
Jon

Policy Based Routing and IP Helper

Can anyone help with an issue i am having with PBR and an IP Helper. I cannot get devices in the VLAN with the associated SVI to get DHCP addresses, there is no DHCP server in the VLAN so an IP Helper is used but whenever i enable PBR on the SVI, DHCP stops working. The switch is a 6506 Catalyst running Version 12.2(17d)SXB11 of IOS
The SVI config for the VLAN is as below
ip address 10.2.60.254 255.255.255.0
ip helper-address 10.10.80.200
ip helper-address 10.10.80.201
ip policy route-map ACPBR
no ip igmp snooping explicit-tracking
no ipv6 mld snooping explicit-tracking
no ipv6 mld snooping
a route map configured as follows
route-map ACPBR permit 10
match ip address ACPBR_ACL
set ip default next-hop 10.99.1.252
route-map ACPBR permit 20
set default interface Null0
and an access list as follows
ip access-list extended ACPBR_ACL
deny udp any any eq bootps log
permit ip 10.2.60.0 0.0.0.255 any
So any DHCP traffic should hit the deny command and drop back to the normal routing process, at least thats my understanding. The logs on the 6506 even show the DENY being hit, see below
list ACPBR_ACL denied udp 0.0.0.0(68) -> 255.255.255.255(67), 1 packet
Can anyone advise why this may be happening, if i add the PBR to the SVI DHCP stops working, if i remove it then it starts working so it is definately PBR doing something.
Thanks
Ryan

Ryan,
The deny line in your ACL merely causes the DHCP traffic to be not processed in the ACPBR block 10. However, for this traffic, the processing of the route-map continues to block 20 with the set default interface Null0 command. This could be the cause of the drops you are seeing. Remember, the permit/deny in ACL here only select packets to be dealt with in the particular route-map block. However, it is the permit/deny in the route-map block header that determines whether the packet is going to be PBR-ed or normally routed.
Assuming you want to keep the DHCP traffic to be normally routed, one of ways of doing that would be:
ip access-list extended ACPBR_ACL deny udp any any eq bootps log permit ip 10.2.60.0 0.0.0.255 any!ip access-list extended ACPBR_DHCP permit udp any any eq bootps!route-map ACPBR permit 10 match ip address ACPBR_ACL set ip default next-hop 10.99.1.252!route-map ACPBR deny 15 match ip address ACPBR_DHCP!route-map ACPBR permit 20 set default interface Null0
This configuration causes the DHCP traffic to be processed in block 15, and because of the deny action in the block header, the traffic should fall back to normal routing.
While I am somewhat surprised that the PBR would affect broadcasts (it should not, and perhaps it affects only a part of the DHCP communication that does happen to be unicasted), I believe this modification of your config is worth trying.
Best regards,
Peter

Policy Based Routing is not working with slb configured

I have a 7609 with a slb firewallfarm configured. It is running IOS 12.2(18)SXE3 with sup720. The firewallfarm is configured with default settings with no access parameter, only real servers configured.
All the traffic is coming from a single vlan (it's not possible to implement another layer 2 way to make the traffic pass through) and I would like to make a single flow to exit from another interface and not pass to the real servers configured on FWfarm. I wrote the following PBR statements:
!!!!!!! Begin !!!!!!!
access-list 110 permit ip host XX.XX.XX.XX any
!where XX.XX.XX.XX is an omitted IP address
route-map NEW-ROUTEMAP permit 10
match ip address 110
set ip next-hop 192.168.253.3
interface Vlan55
!vlan 55 is the interface from where the selected flows comes
ip route-cache policy
ip policy route-map NEW-ROUTEMAP
!!!!! END !!!!!!!
The route-map seems working, in fact I can see matched ACL and route-map.
The problem is the SLB seems to take all the traffic in charge, also the one I would like to route to another interface, in fact if I put my desidered output interface in monitor I can see no traffic passing through.
SLB creates the sticky entry anyway, in fact as far as I know, the SLB has the priority to static routing and route-maps.
Any idea for a workaround? Is there a way to make PBR works with SLB?
Thanks in advance.
Ric

It's possible to make pbr work with slb for further details refere to the link ,
http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800ca75d.html

Policy based routing to host in same vlan/subnet

Hello i have nexus 7k that i have a policy based routing setup as follows for 2 vlans, 802 and 803, to set default route out to a host in vlan 802. i have applied my policy to the vlans and everything works fine for a host in vlan 803, it routes over and out properly. However when im in vlan 802 my host traffic never gets to 172.21.1.237 when pointed at the gateway 172.21.1.1. I can see the pbr statistics incrementing indicating that i am initially hitting the policy but im not sure where my traffic goes after that. I can talk to .237 direct in the vlan but i would like this to work through pbr to utilize all of my other routes and default gateway.
vlans 802
172.21.1.1/24
ip policy route-map West
vlan 803
172.21.17.1/24
ip policy route-map West
route-map West permit 10
match vlan 802-803
set ip default next-hop 172.21.1.237
Im thinking there is some kind of hairpinning problem or maybe im creating some kind of blackhole.
any help is appreciated.
thanks, scott

Scott
If the destination IP is in the same subnet as source IP then it won't be routed it will be L2 switched so it would never use the default gateway ie.
src IP 172.21.1.10 255.255.255.0
dst IP 172.21.1.237 255.255.255.0
src compares it's own IP with it's subnet mask and sees it is on the 172.21.1.x network. src then compares the destination IP with it's own subnet mask and sees it is also on the 172.21.1.x network so it simply arps out for that address and when it gets the mac address it sends it direct to the destination. It would only use the default gateway if the destination IP was on a different network.
So i don't see how you will be able to do this and i'm not sure why you are seeing hits in your PBR acl for the host in the 172.21.1.x network.
Edit - what exactly do you mean when you say -
However when im in vlan 802 my host traffic never gets to 172.21.1.237 when pointed at the gateway 172.21.1.1.
How are you doing this ie. pointing it to the default gateway because as i say it should always be able to communicate with 172.21.1.237 as it is in the same subnet.
Jon

Does icmp redirect work with policy based route

Setup:
R1 and R2 on same ip net.
On R1 policy based route is configured with R2 as next hop.
Will R1 send icmp redirect (to use R2 instead) to those hosts that match the policy based routing ?
Thanks.
Gert Schaarup

HI Gert,
The answer to your question is yes. I have verified this in a lab previously. As long as all the conditions for ICMP redirect have been met (source address on same net, best gateway on same net) then ICMP redirects are sent regardless of whether PBR or normal routing is being used.
Hope that helps - pls rate the post if it does.
Paresh

Denying telnet traffic from VRF interfaces on the router

Hi,
We are currently trying to accomplish incomming telnet traffic from an VRF interface to be denied by the router(7613--IOS:12.2(18)SXF4). In the line vty , we have associated an access-class specifying the block should be allowed for inbound telnet connection to the router. This is working good but it also allows the incomming telnet from an VRF interface having the same block as the global table block which is configured for allowing the incomming telnet connection. We don't want to allow any telnet connection from the vrf interface , even though it matches the permit block in the access-list
Kindly note that, we have not specified vrf-also command on the access-class.
Please let us a way to accomplish the above requirement .
Thanking You
Regards
Anantha Subramanian Natarajan

Hi,
Thanks for the suggestion.
I think, I haven't made my requirement clear. We would not like applying access-list to the VRF interfaces to acheive this requirement bcos, then we may have to bind to all the VRF interfaces(I mean customer interfaces),we acting as service provider. We are looking the way by applying access-class binded to line vty ,which is common to all the telnet traffic.
Kindly let us know,if you have some suggestions on the same
Regards
Anantha Subramanian Natarajan

Applying "route-map" in interfaces with encapsulation dot1q

Hello,
I would like to ask you if there were some trouble in applying route-maps in a interface and its subinterfaces, as it is shown:
interface GigabitEthernet0/2
ip address 11.0.9.26 255.255.255.252
ip policy route-map GestionRadios
interface GigabitEthernet0/2.11
encapsulation dot1Q 11
ip address 11.0.9.18 255.255.255.252
ip policy route-map RedOperativaA
interface GigabitEthernet0/2.12
encapsulation dot1Q 12
ip address 11.0.9.22 255.255.255.252
ip policy route-map RedOperativaB
I am not sure if it is correct totally. Besides I get this informacion doing "show ip policy" and it seems to be right.
Router#show ip policy
Interface      Route map
Gi0/2          GestionRadios
Gi0/2.11       RedOperativaA
Gi0/2.12       RedOperativaB
I would be very grateful for your help.
Thanks in advance
Regards,
Sandro

Sandro
We do not have much to work with in your post so giving you really good answers is difficult. You do not tell us what type of device this is (I assume probably a router, but perhaps it is a layer 3 switch?) or what version of code it is running. These things make a difference sometimes in what is supported or is not supported. But since you get output in show ip policy then I assume that the device does support configuration of this feature.
You show us the configuration of the interfaces but not the configuration of the route maps or the access lists which the route maps probably use. So we can not form an opinion of the validity of the route maps or the access lists.
And you do not tell us whether the Policy Based Routing is working or not (and in fact you do not tell us for sure that you are doing PBR - though that is generally what route maps on the interfaces are doing) so we are not clear whether there is a problem here or not.
But based on what you show us in this post I do not see any particular problems with the route maps and the way that you have applied them to interfaces (assuming that your goal is really to do PBR).
HTH
Rick

Policy based routing on VRF interfaces to route traffic through TE Tunnel

Similar Messages

Maybe you are looking for