Unanswered Question
Apr 19th, 2009

Hi Cisco,

Im trying to route an internal network to our back wireless WAN link.

On our 3825 router, we have 2x physical interface (WAN/LAN). The backup wireless is connected to our switch stack on the LAN and I have created a sub-interface on the router with a VLAN assign to the sun-interface and the switch port.

Route Map is meant to route any traffic from interface GigabitEthernet0/1.150 out to the wireless backup via router interface GigabitEthernet0/1.500 and switch interface FastEthernet0/22 on VLAN 500.

Here is the config:


interface FastEthernet0/22


switchport access vlan 500

switchport mode access

speed 100

duplex full

storm-control broadcast level 20.00

spanning-tree portfast


Gig0/0 = WAN Primary Link

Gig0/1 = LAN Trunk to Switch Stack

interface GigabitEthernet0/1.150

encapsulation dot1Q 150

ip address

ip accounting output-packets

ip nat inside

ip virtual-reassembly

no ip mroute-cache

no snmp trap link-status

ip policy route-map WIRELESS


interface GigabitEthernet0/1.500

description LINK TO WIRELESS

encapsulation dot1Q 500

ip address

ip nat outside

ip virtual-reassembly

no snmp trap link-status


ip nat inside source route-map WIRELESS GigabitEthernet0/1.500 overload


access-list 80 permit


route-map WIRELESS permit 40

match ip address 80

set ip next-hop

It's not working when I initiate a traceroute to the public using source of GigabitEthernet0/1.150 or The path to the wireless link is via the router LAN then back to the switch stack then on VLAN 500.

Any ideas?


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Richard Burts Sun, 04/19/2009 - 17:26


I am confused. The route map WIRELESS is used as part of Policy Based Routing, as we would expect. But that route map is also used to control the address translation:

ip nat inside source route-map WIRELESS GigabitEthernet0/1.500 overload

What are you trying to accomplish here?

The other part of the issue is the way that you are attempting to test. What you have configured will do PBR for packets arriving on the interface Gi0/1.150 and being forwarded by the router. But you are attempting to test with a traceroute generated on the router itself. But the way that you have configured PBR will not process packets generated by the router itself. For PBR of packets generated by the router you need ip local policy. A better test would be to generate traffic from some host connected on Gi0/1.150.



valdesp250503 Sun, 04/19/2009 - 17:49

Hi Rick,

Thanks for the reply.

Yes, Route-Map is use for both PBR and NAT. Is this setup correctly?

Since we have a backup wireless link with no traffic, we have decided to allow one of our users on network Gi0/1.150 to use this link out to the Internet instead of using the primary WAN Gig0/0. NAT is put on for obvious reasons. I will test on the host end within Gi0/1.150.


valdesp250503 Sun, 04/19/2009 - 20:08


This is now fix. I have applied ip local policy route-map WORD on the global command which is what I needed to test from the router.

Thanks again.

valdesp250503 Sun, 04/19/2009 - 21:25

Hi Again,

OK, I know that the if I apply the ip local policy route-map WORD on the global command, the route-map works when tested from the router using source interface GigabitEthernet0/1.150.

I just tried from the host PC on the network GigabitEthernet0/1.150 (default gateway of the PC), it doesnt work...

Have I miss anything here?



Richard Burts Mon, 04/20/2009 - 08:22


If it works when you configure local policy routing I would assume that the Policy Routing part is working ok. This would lead me to suspect that the problem was in the address translation. It is a highly unusual config to have the route map control both the policy based routing and the address translation. I would suggest that you rewrite the address translation, taking out the route map and using just the access list to control the address translation.




This Discussion