PBR on 3560

Answered Question
Jun 18th, 2008
User Badges:

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

Correct Answer by Sushil Kumar Katre about 8 years 11 months ago

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Collin Clark Wed, 06/18/2008 - 08:10
User Badges:
  • Purple, 4500 points or more

Would a VRF work for your situation?

hellawellr Wed, 06/18/2008 - 08:22
User Badges:

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

Sushil Kumar Katre Wed, 06/18/2008 - 10:48
User Badges:
  • Gold, 750 points or more

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

hellawellr Thu, 06/19/2008 - 00:28
User Badges:

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



Correct Answer
Sushil Kumar Katre Thu, 06/19/2008 - 00:57
User Badges:
  • Gold, 750 points or more

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

hellawellr Thu, 06/19/2008 - 02:32
User Badges:

Thanks Sushil,


I'll have a play and let you know


Rick

Edison Ortiz Thu, 06/19/2008 - 04:54
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

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.

Sushil Kumar Katre Thu, 06/19/2008 - 05:01
User Badges:
  • Gold, 750 points or more

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

Edison Ortiz Thu, 06/19/2008 - 05:07
User Badges:
  • Super Bronze, 10000 points or more
  • Hall of Fame,

    Founding Member

Sushil,


Reading the thread one more time, I believe your solution is what he is after.


Sorry for the confusion.


__


Edison.

Sushil Kumar Katre Thu, 06/19/2008 - 05:11
User Badges:
  • Gold, 750 points or more

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

hellawellr Thu, 06/19/2008 - 06:59
User Badges:

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.......

Sushil Kumar Katre Thu, 06/19/2008 - 23:41
User Badges:
  • Gold, 750 points or more

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

hellawellr Thu, 06/26/2008 - 00:00
User Badges:

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

Sushil Kumar Katre Thu, 06/26/2008 - 00:23
User Badges:
  • Gold, 750 points or more

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

hellawellr Thu, 06/26/2008 - 00:30
User Badges:

Yeah, well I might need your help on the next one sometime so best to keep you happy!!!!


Thanks again


Rick

Actions

This Discussion