Skip to main content

NHRP check for extraneous configs

  • 2 August 2024
  • 0 replies
  • 24 views

This is a good example of how NQE can work well with IP subnet information.

In this case the customer had found that the router's parser would not exclude misconfigurations. They found that some of the NHRP configuration commands had used the incorrect subnet.  The correct IP configs were there as well, but now it means there are extra config lines and it would be nice to clean these up. There were under 100 devices that were violations out of the tens of thousands of devices that were collected.

Config segment from Cisco router with a violation.
!
interface Tunnel0
 ip address 10.16.1.16 255.255.255.0
 ip nhrp map multicast 172.16.16.1
 ip nhrp map 10.6.16.1 172.16.16.1 <<--This command does not match the tunnel subnet
 ip nhrp map multicast 192.168.16.1
 ip nhrp map 10.16.1.1 192.168.16.1
 ip nhrp network-id 16
 ip nhrp nhs 10.16.1.1
!

/**
* @intent Find ip nhrp commands that are not in the same subnet as the tunnel subnet
* @description The 'ip nhrp map' and 'ip nhrp nhs' address should be
* addresses that are in the same ip subnet as the subnet configured under the
* tunnel interface. The violation is if the configured address is NOT in the interface's
* subnet.
*/

pattern01 =
```
interface {ifaceName:string}
ip address {intIP:ipv4Address} {intMask:ipv4Address}
ip nhrp {type:string} {ip_address:ipv4Address}
```;

foreach device in network.devices
foreach match in blockMatches(device.files.config, pattern01)
let intSubnet = ipSubnet(match.data.intIP, match.data.intMask)
select {
//
// notice this violation compares an ip address to the subnet
// there is no string mapping to ip address or subnet needed.
//
violation: match.data.ip_address not in intSubnet,
device: device.name,
interface: match.data.ifaceName,
intSubnet: intSubnet,
nhrp_type: match.data.type,
ip_address: match.data.ip_address
}

 

Be the first to reply!

Reply