cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
718
Views
0
Helpful
7
Replies

Problems with PBR for public network

chrisl1977
Level 1
Level 1

I've recently replaced two other routers with Cisco 1841s, and in the process migrated our public access to a third VLAN on these routers. The problem I am having is this public network needs a completely different gateway from the other two VLANs. I've tried setting up a PBR policy on both routers, and it seems to work to a point. Packets can pass between 192.168.255.0/24 and 192.168.254.0/24 ok, but packets from 192.168.254.0/24 get lost on the way to the internet. The problem is in the conf of these two routers, as this setup worked on two different routers dedicated to this connection.

The config files are attached. Any help is welcome and appreciated!

Thanks - Chris

7 Replies 7

Richard Burts
Hall of Fame
Hall of Fame

Christopher

I am not sure that there is enough information here to really be sure what the problem is. But based on what I see so far and on the symptoms that you describe I would guess that the problem is that on the way to the Internet the traffic from 192.168.254.0 needs to be translated but is not being translated.

The next hop in your default route from local is 172.16.0.1. Is this the router that is doing address translation? Is so can we see how its translation is set up?

I would also offer a couple of observations about these configs:

- the policy route map uses access lists 121 and 122. But there are not any access list 121 or 122 in the config that you posted. Is this just an omission in your cut and paste or are they really missing?

- both routers have static routes for the subnets on their connected interfaces. These static routes are not needed. The local subnet will show up in the routing table as a connected route and the static route does no good.

HTH

Rick

HTH

Rick

Oops - the access lists were in there yesterday, but I took them out as these routers are in production.

LOCAL ACL's

access-list 121 permit 192.168.254.0 255.255.255.0 any

access-list 122 permit any 192.168.254.0 255.255.255.0

REMOTE ACL's

access-list 121 permit 192.168.254.0 255.255.255.0 any

By not needing the static routes for the connected interfaces, I'm assuming you mean those that end in an interface name (ex: FastEthernet0/0.1)?

Christopher

I do not see anything on the remote router that references access list 121. Am I missing something?

The static routes that I am talking about are these on the remote router:

ip route 172.16.1.0 255.255.255.0 FastEthernet0/0.1

ip route 172.16.10.0 255.255.255.0 FastEthernet0/0.2

ip route 192.168.1.16 255.255.255.252 Multilink1

ip route 192.168.254.0 255.255.255.0 FastEthernet0/0.4060

and these from the local router:

ip route 172.16.0.0 255.255.255.0 FastEthernet0/0.1

ip route 172.16.4.0 255.255.255.0 FastEthernet0/0.2

ip route 192.168.1.16 255.255.255.252 Multilink1

ip route 192.168.255.0 255.255.255.0 FastEthernet0/0.4060

With the information about the access lists I am trying to understand the logic of the Policy Based Routing and it is not making much sense to me. The PBR is configured on interface FastEthernet0/0.4060 so it is looking at traffic that is input on that interface. The first instance in the route map (permit 10) specifies that it is dealing with traffic whose source address is 192.168.254.0. How will any traffic be input on that interface with source address of 192.168.254.0?

And the second instance in the route map (permit 20) looks for traffic whose destination is 192.168.254.0 and sets the next hop as 192.168.255.1.

Can you clarify what is going on with this?

HTH

Rick

HTH

Rick

Since a picture is worth 1000 words, I thought the attached diagram might help. I'll fix the routing tables tomorrow, but I really need help with why the public internet access is pooched. Thanks - Chris

Christopher

Thank you for the picture. It does help. Between the picture and the router configs I think that I am beginning to see the issue.

I believe that the problem is that the traffic from the Public Access at the remote is not being sent to the other gateway (192.168.255.1) and is being forwarded to the "normal" gateway (172.16.0.1). This is because of a misunderstanding of how to apply PBR. The config of the local router applies PBR only to the VLAN interface. This means that it is applied only to traffic that is input on that interface.

If my understanding is correct your main requirement here is that traffic from the Public Access at the remote should be forwarded to an alternate gateway at 192.168.255.1. To accomplish that the PBR must be applied to the interface where that traffic is input - which would be on the multilink interface. If you move the route map to the multilink interface then it should route the traffic as you desire. It would look something like this:

interface Multilink1

ip policy route-map PUBLIC

route-map PUBLIC permit 20

match ip address 122

set ip next-hop 192.168.255.1

I am not sure that you need PBR on the VLAN interface and I am not sure that you need this:

route-map PUBLIC permit 10

match ip address 121

set ip next-hop 192.168.1.18

and if you do need it, you certainly do not need both parts in the same route map.

HTH

Rick

HTH

Rick

Rick -

I'm trying to enter the access-list for 122, but it keeps reverting to 0.0.0.0 on me.

I enter "access-list 122 permit ip any 192.168.254.1 255.255.255.0", and then it changes to "access-list 122 permit ip any 0.0.0.0 255.255.255.0" when I look at the running config.

What am I doing wrong?

Christopher

You are treating the wildcard mask like you were on a PIX or ASA and using the normal masking bits. To match the class C network on a router it should be like this:

access-list 122 permit ip any 192.168.254.0 0.0.0.255

HTH

Rick

HTH

Rick
Review Cisco Networking for a $25 gift card