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,

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

Thanks Sushil,

I'll have a play and let you know

Rick

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.

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

Sushil,

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

Sorry for the confusion.

__

Edison.

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

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

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

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

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