Skip to main content

Palo Alto NDP Monitoring

Palo Alto NDP Monitoring

PAN-OS version 8.0 Palo Alto Networks introduced another IPv6 feature, namely “NDP Monitoring for Fast Device Location“. It basically adds a few information to the existing neighbor cache such as the User-ID (if present) and a “last reported” timestamp. That is: the admin has a new reporting window within the Palo Alto GUI that shows the reported IPv6 addresses along with its MAC addresses. This is really helpful for two reasons: 1) a single IPv6 node can have multiple IPv6 addresses which makes it much more difficult to track them back to the MAC address and 2) if SLAAC is used you now have a central point where you can look up the MAC-IPv6 bindings (comparable to the DHCP server lease for legacy IPv4).

For IPv4 you already have the DHCPv4 “View Allocation” window on the Palo Alto GUI. But for IPv6 addresses that are generated by the nodes themselves via SLAAC, everyone lacks a reporting instance for the MAC-IPv6 bindings. I wrote a few posts about monitoring MAC-IPv6 address bindings a couple of years ago. This feature now makes the traceability of IPv6 nodes available, at least for the local link (layer 2) from the firewall. (Reminder: NDP is link-local only, hence does not traverse any layer 3 routing instance.)
For this test I used a PA-200 with PAN-OS 8.0.3.

Activation & Tracing

You must only activate the “Enable NDP Monitoring” checkmark within the IPv6 tab for each interface you would like to enable it. You’re done. ;)

Every new Neighbor Advertisement is now stored along with its MAC address. Palo Alto will also add the User-ID if it’s known for that particular IPv6 address. Note the new clickable symbol in the “Features” column which opens the list. You can also filter the output, e.g., for a MAC address. This is quite useful since a single MAC address can have multiple IPv6 addresses, either because of privacy extensions or because of couple of configured addresses, such as virtual hosts on an F5 load-balancer as in my case:

Neighbor Cache vs. NDP Monitoring

The NDP Monitoring is not that different from the already available neighbor cache, though it uses some other sources. While the “neighbor cache” is an IPv6 standard functionality, this “NDP monitoring” captures neighbor advertisements and duplicate address detection (DAD) messages. Comparing both outputs on the CLI the NDP Monitoring has two more columns: “user id” and “last reported” (while it has a bad column size since the first two columns have no spacing when using subinterfaces). The following listing shows the normal neighbor cache (beginning at line 1), the new NDP monitoring output (line 52) and a filtered version of the NDP monitoring output based on a single MAC address (line 91).
I am not quite sure why I have more entries within the neighbor cache compared to the NDP monitoring. And only two link-local fe80:: addresses in the NDP mon section while 13 (!) in the interface. Hm. Maybe this is related to the fact that the NDP Monitor feature was not enabled since the start of the firewall. It is probably congruent with the “interface” output after the next reboot

Comments

Popular posts from this blog

CLI Commands for Troubleshooting FortiGate Firewalls

CLI Commands for Troubleshooting FortiGate Firewalls 2015-12-21 Fortinet , Memorandum , Network Cheat Sheet , CLI , FortiGate , Fortinet , Quick Reference , SCP , Troubleshooting Johannes Weber This blog post is a list of common troubleshooting commands I am using on the FortiGate CLI . It is not complete nor very detailled, but provides the basic commands for troubleshooting network related issues that are not resolvable via the GUI. I am not focused on too many memory, process, kernel, etc. details. These must only be used if there are really specific problems. I am more focused on the general troubleshooting stuff. I am using it personally as a cheat sheet / quick reference and will update it from time to time. Coming from Cisco, everything is “show”. With Fortinet you have the choice confusion between show | get | diagnose | execute . Not that easy to remember. It is “ get router info6 routing-table” to show the routing table but “ diagn...

Check Throughput of Interfaces - Palo Alto Networks NGFW

Check Throughput of Interfaces - Palo Alto Networks NGFW Following command shows brief interface throughput. > show system statistics session To see the complete statistics, run the show system state browser command > show system state browser Press Shift+L and click on Ports To enable tracking and updates press Y and U To see additional ports, press space bar

From MPLS to SD-WAN to SASE: An Evolution of Enterprise Networking

From MPLS to SD-WAN to SASE: An Evolution of Enterprise Networking The way we do business is changing. As critical business applications migrate to the cloud, and the mobile workforce continues to grow, networking and security solutions need to evolve in order to meet the changing business needs. Gartner believes (and we agree) that the future of networking lies with  SASE (Secure Access Service Edge)  – the convergence of networking and security into one cloud service. Here’s why. 1990s – 2000s: MPLS and the Era of Clear Network Boundaries? Back in the day, networking models were hardware-centric and manually configured. Applications, data, and services lived within private datacenters and relied on remote access solutions to connect remote workers. Dedicated network connectivity, known as MPLS, was the preferred approach for connecting remote locations. MPLS provides predictable performance, low latency and packet loss, and central management. However, MPLS is ...