Policy based routing on comware 7 - sanity check

[pattap]

Hi all

I'm having some issues with policy based routing on comware 7 switches.

I've just gone through hpe guide and I was hoping that someone with more experience could confirm this for me

If I get this right the below statements will achieve the same results

policy-based-route test permit node 10
if-match acl 3235

# traffic matching acl 3235 will be forwarded according to the routing table 

VS

policy-based-route test permit deny 10
if-match acl 3235

#as above, send traffic matching the acl according to the routing table 

[Ivan_B]

Hi @pattap !

Yes, that is correct, I'd also expect same result, but for different reasons.

Case 1:

policy-based-route test permit node 10
 if-match acl 3235

PBR policy node matches traffic according ACL 3235, it is ready to apply action like 'apply next-hop' (since the node's match mode is 'permit') but the 'apply' clause is not configured, therefore the matched traffic will be routed according to the routing table because PBR simply doesn't know what to do with the traffic.

Case 2:

policy-based-route test deny node 10
 if-match acl 3235

 PBR policy node 10 match mode is 'deny' which means it matches traffic according ACL 3235 and routes it according to the routing table.

Hope this helps!

[pattap]

ok so we got that confirmed, thanks 

I'm experiencing strange behaviour. It appears that despite my PBR configured and applied to vlan interface traffic is being forwarded based on the routing table 

The below is the config of the policy, it also have been applied to my vlan interface. Next hop is an IP address of GRE tunnel in front of my internet firewall which acts as default gateway. GRE terminates on HPE5900 in front of the firewall, the switch has a default route pointing to the FW.

The problem is that the traffic is not hitting the firewall at all, instead it hits another internet firewall with no GRE configured in front of it. This indicates that the traffic scoped by acl 3236 is being routed based on routing table rather than controlled by apply  next hot action within the policy.

policy-based-route WIFI permit node 20
if-match acl 3236
apply next-hop <ip address>

I'm losing my head over this. Any ideas will be much appreciated.

EDIT: also just realised there's no any hits on the switch with PBR configured on, it's hpe5710

acl number 3236 name Allow_WIFI_via_GRE
rule 10 permit ip source x.x.x.x x.x.x.x logging counting

I've just ran a debug ip packet acl 3236

got this result

*Mar 17 09:54:20:035 2021 C3_L3 ACL/7/Match: No match for source address in advanced rule 10.
*Mar 17 09:54:19:114 2021 C3_L3 ACL/7/Match: -Slot=2; No match for source address in advanced rule 10.
*Mar 17 09:54:20:103 2021 C3_L3 ACL/7/Match: No match for source address in advanced rule 10.
*Mar 17 09:54:20:103 2021 C3_L3 ACL/7/Match: No match for source address in advanced rule 10.

[Ivan_B]

Are you sure the wildcard mask in your ACL is correct?

[pattap]

yes it's /22 net and wild card in the acl is 0.0.3.255

edit: not sure if it's a bug on the switch but upgrading it to R2702P01 from R2702, can't think of anything else at that stage 

[Ivan_B]

Hmm, that's weird.. Configuration-wise you need only correct ACL, proper PBR node that matches ACL and sets next-hop and then you just apply the PBR to the Vlan-interface... So you say the PBR doesn't work on two different switches - 5900 and 5710? If so, I'd say it's configuration issue, because chance you are hitting one bug on two different platforms (different by chipsets and software) has very low probability...

BTW, could you do one test:
- Login to the switch and enable logging to terminal with 'terminal monitor' command
- Enter the Vlan-interface where you applied the PBR policy and remove it using 'undo ip policy-based-route' command
- Re-apply the PBR policy. Look for any errors. If any errors, post them here.

If no errors, please, send me the output from 'display ip policy-based-route interface' command as well as 'display acl <acl_used_in_PBR>' You can obfuscate IP addresses if you use real public IPs outside RFC1918 private ranges.

As for the upgrade of 5710 from 2702 to 2702P01 - I couldn't find any bugfix for anything related to PBR in the P01, so the chance the upgrade will fix it is not so high.

[pattap]

Hi Ivan

I wasn't clear on the two switches, what I meant was that the GRE is between 5710 and 5900, policy is on 5710.

We have PBR configured in the same way for the same purpose on other models, 5510's and 5800's and they all have their  GRE established with the same 5900 switch.

Tried what you said, seen no logs during re-applying the policy

Also what is very strange, I have generated some traffic from witin net sepcified in acl 3236 from another switch connected to this 5710 and I'm not seeing it in deb ip pack acl 3236 - yes ter monitor and ter deb are on, vlan is tagged across the uplink

[Ivan_B]

Sorry if my questions will look stupid, redundant and unneeded, but I do not have full 'display diag' from the switch, so let's verify a couple of very basic things that are currently unclear to me:

1. Is the next-hop IP address set by the 'apply next-hop' reachable from the routing table perspective? If the next-hop is not reachable, PBR won't work.
2. You don't use VRFs (vpn-instances), do you? If Vlan-interface224 is in separate vpn-instance or GRE tunnel is inside vpn-instance, that may require modification of ACL 3236 as well as 'apply next-hop' clause.
3. Are you sure that traffic from the network matched by the ACL 3236 comes on Vlan-interface224 of the switch? Of course this question makes sense if that rule matches different subnet, not the one of the Vlan-interface224 itself.
4. If that rule 10 matches the same subnet which Vlan-interface224 has, please, verify that your hosts use Vlan-interface224 IP address as default gateway, otherwise traffic won't be hitting the switch and it may explain why PBR doesn't work.
5. 'Matched' counter of the policy shows zero, so may be switch doesn't "like" the ACL 3236 due to certain, currently unknown reasons. Could you change it to match one single test IP (wildcard mask 0.0.0.0) and don't use any additional options like 'logging' and 'counting'?
6. Since you've mentioned you used debugging, let's try to debug not only ACL, but the PBR module itself:

terminal monitor
terminal debug
debugging ip policy-based-route

Check what messages you will get, maybe that output will point us to the right direction.

[pattap]

Hi Ivan 

No question is stupid and thanks for looking at this for me.

1. Yes next hop is applied by "apply next-hop" command. It is also reachable from the switch. It appears as direct route:

sorry about heavy redacting, . x.x.52.72/30 is the range for the GRE in question and 52.74 address is remote end of the tunnel.

2. No 

3. Yes, end devices are in vlan 224, this vlan is stretched across  to L2 switches, vlan tagged across the uplinks.

4. Yes devices in vlan 224 use int vlan 224 address as their default gateway

5 and 6 I need to be on site to generate traffic in that vlan, will do that later on today. I'll edit this response once I have the answers

[pattap]

A bit late but here are the results of points 5 and 6

5. I changed it to a single IP address and made sure it was the test device in vlan 224 I was using. I saw the ACL being matched based on the debug but traffic still wasn't sent via tunnel. I'm expecting traffic to go via tun24

6. with "IP policy based routing debugging switch is on" not a single entry popped in the terminal 

Also just on a side note. I just realised today that there is exactly same setup on one of other sites I have visited today also with 5710 as L3 and this is not working there either.