06-18-2008 07:59 AM - edited 03-05-2019 11:42 PM
I have a 3560 running 12.2.25 with all interfaces in vlan 1 except G0/1 to 1 WAN circuit and G0/14 to different WAN circuit.
Interface vlan 1 has subnet A as primary, subnet B as secondary.
I want all traffic source subnet A to go to G0/1 and all traffic source subnet B to go to int G0/14.
Obviously I want any traffic with destination A or B to remain on site.
Using PBR applied to vlan 1, I can get the WAN traffic to go to the relevant interface, but I can't get the local traffic to stay local.
This is because the 3560 does not support deny actions in route-maps (nor does the 3750), so I can'g get traffic destined for A or B to avoid the policy route map.
This must be a common requirement - any assistance appreciated.
Many thanks - this is driving me nuts
Rick Hellawell
P.S ignore the config guide for 12.2.25 PBR, it is lying. 12.2.44 tells a truer story
Solved! Go to Solution.
06-19-2008 12:57 AM
HI Rick,
You mean to say route-map CABLE_WIRELESS deny 10 command is not supported on the switch.
Why don't you try this -
route-map CABLE_WIRELESS permit 10
description *** Source address ACL 110 to C&W VSAT ***
match ip address 110
set ip next-hop 155.250.29.10
!
route-map CABLE_WIRELESS permit 20
description *** Source address ACL 120 BT VSAT ***
match ip address 120
set ip next-hop 155.250.29.6
access-list 110 deny ip any 10.10.10.0 0.0.0.255
access-list 110 deny ip any 10.10.20.0 0.0.0.255
access-list 110 permit ip 10.10.10.0 0.0.0.255 any
access-list 120 deny ip any 10.10.10.0 0.0.0.255
access-list 120 deny ip any 10.10.20.0 0.0.0.255
access-list 120 permit ip 10.10.20.0 0.0.0.255 any
-> Sushil
06-18-2008 08:10 AM
Would a VRF work for your situation?
06-18-2008 08:22 AM
Not sure exactly. The circuits are actually satellite links and all routing on the device is static. The second circuit has gone in to alleviate bandwidth pressure on the first one. The secondary IP subnet is new, and I want to move a couple of high usage servers into that subnet to use the new bandwidth.
Traffic coming to that site from the WAN is controlled by the relevant subnets being advertised by the satellite providers.
I was hoping a simple PBR would work, and unluckily the device had 12.2.25 on it, the doc for which tells me denied traffic drops out of the policy. unfortunately it was wrong.
So hadn't really thought of vrf. I am in UK so will think about it over night thanks
06-18-2008 10:48 AM
Hi Rick,
Help me understand your requirement.
Let's say you have two subnets -
10.10.10.X
10.10.10.X
Traffic ORIGINATING from 10.10.10.X should go thorough LINK A and from 10.10.20.X through LINK B.
That's achieved by PBR which you are applying on VLAN 1.
Now traffic DESTINED for 10.10.10.X & 10.10.20.X show remain on site. What's meant by this. Help me understand where is this traffic coming from?
-> Sushil
06-19-2008 12:28 AM
Sushil,
Thanks for your interest
The problem is traffic generated from say 10.10.10.x destined for either 10.10.10.x or 10.10.20.x. This hits the policy route before regular switching/routing on the 3560, and so gets sent to one of the WAN links.
Within PBR the first route-map would normally be "source 10.10.10.x - dest 10.10.20.x deny". This would drop this traffic out of the policy and it would be treated by standard switching/routing on the 3560.
Problem is the 3560 doesn't support "deny" policies.
All 3560 interfaces in VLAN 1 except:
interface GigabitEthernet0/1
description *** to BT VSAT ZAM01 ***
no switchport
ip address 155.250.29.1 255.255.255.248
duplex full
interface GigabitEthernet0/14
description *** To C&W VSAT ZAM01B ***
no switchport
ip address 155.250.29.9 255.255.255.248
speed 100
duplex full
interface Vlan1
ip address 10.10.10.0 255.255.255.0 secondary
ip address 10.10.20.0 255.255.255.0
access-list 100 permit ip any 10.10.10.0 0.0.0.255
access-list 100 permit ip any 10.10.20.0 0.0.0.255
access-list 110 permit ip 10.10.10.0 0.0.0.255 any
access-list 120 permit ip 10.10.20.0 0.0.0.255 any
route-map CABLE_WIRELESS deny 10
description *** Local source-dest traffic avoid policy route map ***
match ip address 100
!
route-map CABLE_WIRELESS permit 20
description *** Source address ACL 110 to C&W VSAT ***
match ip address 110
set ip next-hop 155.250.29.10
!
route-map CABLE_WIRELESS permit 30
description *** Source address ACL 120 BT VSAT ***
match ip address 120
set ip next-hop 155.250.29.6
!
Unfortunately I cannot apply "ip policy route-map CABLE_WIRELESS" to VLAN 1 as the deny statement in the first route map is not supported.
So how do I prevent the policy applied to vlan 1 acting on local LAN traffic? or how do I write a clever policy which doesn't have a deny statement in?
Thanks
Rick
06-19-2008 12:57 AM
HI Rick,
You mean to say route-map CABLE_WIRELESS deny 10 command is not supported on the switch.
Why don't you try this -
route-map CABLE_WIRELESS permit 10
description *** Source address ACL 110 to C&W VSAT ***
match ip address 110
set ip next-hop 155.250.29.10
!
route-map CABLE_WIRELESS permit 20
description *** Source address ACL 120 BT VSAT ***
match ip address 120
set ip next-hop 155.250.29.6
access-list 110 deny ip any 10.10.10.0 0.0.0.255
access-list 110 deny ip any 10.10.20.0 0.0.0.255
access-list 110 permit ip 10.10.10.0 0.0.0.255 any
access-list 120 deny ip any 10.10.10.0 0.0.0.255
access-list 120 deny ip any 10.10.20.0 0.0.0.255
access-list 120 permit ip 10.10.20.0 0.0.0.255 any
-> Sushil
06-19-2008 02:32 AM
Thanks Sushil,
I'll have a play and let you know
Rick
06-19-2008 04:54 AM
The route-map has an implicit deny at the end so by manually placing the deny won't meet your requirements.
The deny will instruct the source and destination NOT to use the PBR and it will default to using the routing table.
If you want to filter inter-vlan traffic, you must place an ACL on each SVI (Switch Virtual Interface) blocking such traffic.
HTH,
__
Edison.
06-19-2008 05:01 AM
Hi Edison,
If you look at Rick's requirement, he does not want the traffic comming form 10.10.10.X going to 10.10.10.X to be routed through the route map.
Now if you look at the ACL -
access-list 110 permit ip 10.10.10.0 0.0.0.255 any
access-list 120 permit ip 10.10.20.0 0.0.0.255 any
The first statement would get matched for such traffic and never hits the implicit deny at the end of the ACL.
That's the reason why I have suggested him the ACL which would deny such traffic at the begning and woul dget routed normally instead of using PBR.
access-list 110 deny ip any 10.10.10.0 0.0.0.255
access-list 110 deny ip any 10.10.20.0 0.0.0.255
access-list 110 permit ip 10.10.10.0 0.0.0.255 any
access-list 120 deny ip any 10.10.10.0 0.0.0.255
access-list 120 deny ip any 10.10.20.0 0.0.0.255
access-list 120 permit ip 10.10.20.0 0.0.0.255 any
That's what is requierd. So I feel it should work.
Rick can you please confirm if what I have understood from your query is correct.
I might be wrong as well :)
-> Sushil
06-19-2008 05:07 AM
Sushil,
Reading the thread one more time, I believe your solution is what he is after.
Sorry for the confusion.
__
Edison.
06-19-2008 05:11 AM
You know Edison, after reading your post even I went through the post once again to check the requirement :)
Anyway let's hope that it works which is what Rick needs, otherwise we'll break our heads once again to think of something else :)
-> Sushil
06-19-2008 06:59 AM
thanks both, I think Sushil's solution looks to do what I want. The only bit I am not sure about is whether the access-list deny will drop the traffic through to the switch itself, or whether it will stop the traffic altogether.
I am trying to test but have somewhat motley selection of devices to test with.......
06-19-2008 11:41 PM
Rick, ACL in PBR is neither passing the trafic nor dropping it.
Its acting just as a filter. Whatever traffic is permitted by the ACL would be thrown to PBR decision and would be routed according to configured PBR.
Whatever traffic doesn't match ACL [deny statement] would not be thrown to PBR instead it would be routed through the regular routing table.
-> Sushil
06-26-2008 12:00 AM
Sushil,
Apologies for not updating sooner, but have been testing ACL as you suggested, and implemented last night. Phone has been silent so looking good.
So many thanks for all your time and help on this.
Regards
Rick Hellawell
06-26-2008 12:23 AM
Hey Rick that's a great news!!!
I really appreciate you confirming this, otherwise most of the time people don't even bother to update in case the solution works, or they get some other workaround.
Hope your phone doesn't start ringing, at least for this issue :)
-> Sushil
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide