Share:

Replies

The second task requires unique IP addresses from the viewpoint of the monitoring device. This has nothing to do with VRFs per se, just a plain IPv4 unicast requirement. Two solutions are known: give unique IPv4 addresses to all CEs (loopback IPs for monitoring) or use NAT.

The first task is achieved by creating a central service VPN for monitoring. An example config:

ip vrf NMS

rd 65000:1

route-target import 65000:162

export map NMS2vrfs

ip vrf Customer1

rd 65000:101

route-target export 65000:101

route-target import 65000:101

route-target import 65000:161

export map CEloopbacks

ip vrf Customer2

rd 65000:102

route-target export 65000:102

route-target import 65000:102

route-target import 65000:161

export map CEloops2NMS

route-map CEloops2NMS permit 10

match ip address 1

set extcommunity rt 65000:162 [additive]

route-map NMS2vrfs permit 10

match ip address 2

set extcommunity rt 65000:161 [additive]

access-list 1 permit host 10.1.1.1

access-list 1 permit host 10.2.2.2

access-list 2 permit 192.0.2.0 0.0.0.255

Your IP addresses, naming, RDs and RTs might be different. In my example I assume two CEs with 10.1.1.1 and 10.2.2.2 as monitoring Loopback IPs. The export map selectively exports only those IPs into the NMS vrf. Be aware that your monitoring LAN (192.0.2.0/24 in the example) must be reachable from all CEs, which means you have to import this prefix into all VRFs. Thus an official IPv4 address range might be required to avoid address conflicts with customer IPs.