Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

PBR on 3560

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

1 ACCEPTED SOLUTION

Accepted Solutions

Re: PBR on 3560

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

15 REPLIES

Re: PBR on 3560

Would a VRF work for your situation?

New Member

Re: PBR on 3560

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

Re: PBR on 3560

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

New Member

Re: PBR on 3560

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

Re: PBR on 3560

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

New Member

Re: PBR on 3560

Thanks Sushil,

I'll have a play and let you know

Rick

Hall of Fame Super Bronze

Re: PBR on 3560

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.

Re: PBR on 3560

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

Hall of Fame Super Bronze

Re: PBR on 3560

Sushil,

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

Sorry for the confusion.

__

Edison.

Re: PBR on 3560

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

New Member

Re: PBR on 3560

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

Re: PBR on 3560

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

New Member

Re: PBR on 3560

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

Re: PBR on 3560

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

New Member

Re: PBR on 3560

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

Thanks again

Rick

182
Views
5
Helpful
15
Replies