- Community Home
- >
- Networking
- >
- Switching and Routing
- >
- Comware Based
- >
- Re: Policy based routing on comware 7 - sanity che...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-16-2021 09:23 AM
03-16-2021 09:23 AM
Policy based routing on comware 7 - sanity check
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-16-2021 11:04 AM - edited 03-16-2021 11:06 AM
03-16-2021 11:04 AM - edited 03-16-2021 11:06 AM
Re: Policy based routing on comware 7 - sanity check
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-17-2021 02:44 AM - edited 03-17-2021 02:55 AM
03-17-2021 02:44 AM - edited 03-17-2021 02:55 AM
Re: Policy based routing on comware 7 - sanity check
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-17-2021 04:13 AM
03-17-2021 04:13 AM
Re: Policy based routing on comware 7 - sanity check
Are you sure the wildcard mask in your ACL is correct?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-17-2021 04:47 AM - edited 03-17-2021 05:16 AM
03-17-2021 04:47 AM - edited 03-17-2021 05:16 AM
Re: Policy based routing on comware 7 - sanity check
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-17-2021 05:43 AM
03-17-2021 05:43 AM
Re: Policy based routing on comware 7 - sanity check
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-17-2021 08:21 AM - edited 03-17-2021 08:59 AM
03-17-2021 08:21 AM - edited 03-17-2021 08:59 AM
Re: Policy based routing on comware 7 - sanity check
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-17-2021 10:22 AM
03-17-2021 10:22 AM
Re: Policy based routing on comware 7 - sanity check
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-18-2021 01:39 AM
03-18-2021 01:39 AM
Re: Policy based routing on comware 7 - sanity check
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-23-2021 04:03 AM - edited 03-23-2021 04:55 AM
03-23-2021 04:03 AM - edited 03-23-2021 04:55 AM
Re: Policy based routing on comware 7 - sanity check
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.