I85PREP
⌘ K
Aruba Comware Advanced study materials
Aruba Comware Advanced study resources

Inter-VLAN Routing Black Hole with ACL and PBR

Aruba Comware Advanced · Put your knowledge to work in context.

All case studies

Inter-VLAN Routing Black Hole with ACL and PBR

A core switch routes VLAN 10 (10.10.10.0/24, gateway 10.10.10.1) and VLAN 20 (10.20.20.0/24, gateway 10.20.20.1). A policy-based route (PBR) on VLAN 10 interface sends traffic from 10.10.10.0/24 destined to 10.20.20.0/24 to next-hop 10.10.10.254 (a firewall). An inbound ACL on VLAN 10 interface (applied with packet-filter 3000 inbound) permits 10.10.10.0/24 to 10.20.20.0/24. Users in VLAN 10 cannot reach VLAN 20; the firewall logs show no traffic. Pings from the core to 10.20.20.1 succeed. display packet-filter interface Vlan-interface10 inbound shows the ACL applied. The firewall's inside interface is 10.10.10.254/24.

1. Explain why the firewall sees no traffic and what the core is actually doing with the packets.

Read the worked answer

Diagnosis: The PBR next-hop 10.10.10.254 is reachable, but the packets are being dropped before PBR redirect, or PBR is redirecting to a next-hop the core cannot ARP/route to in the correct VRF. The key clue: firewall logs show nothing. If PBR were working, the firewall would at least see SYNs (even if it dropped them).

Most likely causes, in order:

  1. ACL vs PBR order: On Comware, packet-filter inbound on the VLAN interface is evaluated before PBR. If the ACL is correct it should pass; but if the ACL's source is written as 10.10.10.0 0.0.0.255 and the match is on the post-NAT or a different source, it silently drops. Verify hit counts with display packet-filter statistics interface Vlan-interface10 inbound.
  2. PBR next-hop unreachable in the routing table/ARP: If 10.10.10.254 is not in the same subnet as the VLAN 10 interface (it is, /24), ARP should resolve. Check display arp for 10.10.10.254; if absent, PBR cannot forward and the packet is dropped, never reaching the firewall.
  3. PBR policy not applied to the interface even though the ACL is: check display ip policy-based-route and that the policy is bound with ip policy-based-route <name> on Vlan-interface10.

Why core-to-10.20.20.1 ping works: That traffic originates from the core itself, bypasses the inbound ACL and PBR (locally generated), and uses the direct connected route - so it proves nothing about user forwarding.

2. Give a step-by-step verification plan to isolate ACL drop vs PBR drop vs ARP failure.

Read the worked answer

Plan:

  1. ACL hit counters: display packet-filter statistics interface Vlan-interface10 inbound - if the permit rule's counter is not incrementing while users send traffic, the ACL is dropping (check rule order and implicit deny). If it increments, ACL is not the problem.
  2. PBR counters: display ip policy-based-route (and policy statistics) - confirm the policy is bound and the node matches. If the policy is bound but the node has no next-hop ARP entry, packets are dropped at redirect.
  3. ARP: display arp | include 10.10.10.254 - must show a resolved MAC on Vlan-interface10. If incomplete, the firewall's inside IP/VLAN is wrong or the firewall blocks ARP.
  4. Routing: display ip routing-table 10.20.20.0 - confirm the PBR next-hop is the intended path and that there is no more-specific route overriding PBR (PBR wins over routing, but a missing next-hop ARP still drops).
  5. Trace: use tracert from a VLAN 10 host; if it dies at 10.10.10.1, the drop is on the core (ACL/PBR/ARP); if it reaches 10.10.10.254, the firewall is dropping silently (check its policy and logging).

Conclusion logic: ACL counter static + PBR bound + ARP incomplete => PBR/ARP drop. ACL counter incrementing + no firewall log => PBR not redirecting (policy not bound or wrong match).