cat 3750 PBR strange behaviour

[ibrunello]

PBR & 3750 seems not to work together.

feat set is ADV IPServices

sdm routing template is enabled.

I can configure it, but it behaves strangely:

- when I traceroute from a device behind the PBRed VLAN, with an acl which matches the exact source address, the route-map matches just the first packet (the one with TTL=0), but not the following ones (TTL>1).

route-map rmTEST

match ip address aclMATCH

set ip next-hop 10.10.10.1

ip access-list extended aclMATCH

permit ip 192.168.1.0 0.0.0.255 172.16.12.0 0.0.0.255

any hint?

TIA

[Edison Ortiz]

When a traceroute is performed, each transit device will communicate directly with your end host, if the transit device is not within the permit ACL, the traffic won't be policy routed as it leaves the router.

HTH,

__

Edison.

[ibrunello]

Outbound icmp packets have policied destination (I mean, destination should be matched by ACL), and TTL > 1.

Transit device is NOT in destination IP on the forward icmp packet.

I get an icmp "expired in transit" from transit devices on behalf of destination.

[ibrunello]

further info:

I've been running a "debug ip policy", and it just matches just the first packet.

Further packets are not policy-routed, and in fact they hit the next non-pbr hop.

[Edison Ortiz]

Transit device is NOT in destination IP on the forward icmp packet.

You are answering your own question. It's not matching the ACL.

I get an icmp "expired in transit" from transit devices on behalf of destination.

That's a traceroute normal operation.

Again, traceroute isn't the best tool to test PBR when you have such ACL, if you were to do a permit ip any any, then all traffic will be PBR'd.

__

Edison.

[ibrunello]

Maybe we're talking about oranges and apples.

I'm stating that the icmp echo request (that is, forward packet, coming from the VLAN configured with ip policy) is not PBR'd, and it ought to be.

In fact, the icmp contains the right source ip, and the right destination ip.

The only difference is with TTL.

The packet should be policy routed toward the destination.

Then, devices in the middle should catch the packet (again, with the right source, and the right destination), find out that the TTL counter got to 0, and send back an "expired in transit".

PBR should make the correct assumption on how to route the packet.

Then, the packet "expires" before getting to destination only by chance, but this is beyond the PBR logic.

[ibrunello]

Maybe we're talking about oranges and apples.

I'm stating that the icmp echo request (that is, forward packet, coming from the VLAN configured with ip policy) is not PBR'd, and it ought to be.

In fact, the icmp contains the right source ip, and the right destination ip.

The only difference is with TTL.

The packet should be policy routed toward the destination.

Then, devices in the middle should catch the packet (again, with the right source, and the right destination), find out that the TTL counter got to 0, and send back an "expired in transit".

PBR should make the correct assumption on how to route the packet.

Then, the packet "expires" before getting to destination only by chance, but this is beyond the PBR logic.

[ibrunello]

further info:

- all devices between the source and the destination are aware of where the source is, and they don't apply any filtering on either incoming or outgoing packets.

- I tried, just to be sure not to trick some weird cef/route cache issue, i set the "permit ip any any", but the behaviour did not changed