Securely Managing CE Devices

In providing a managed CPE service, a service provider needs to have access to its customer CPEs. However, all CEs (including customer-owned CEs) should be under the management umbrella. A network management VRF, called the VPN_Network_Management, contains the circuit addresses of all the CE routes. Note that the term circuit implies the IP connectivity between these managed customer devices and the NOC. The service provider network management station(s) originates from this VRF. Conversely, each customer VRF should contain the service provider network management station(s) in order to permit bidirectional communication between the management workstation and the CE router. An example of the interaction between the CE router and the service provider network management station is shown in Figure 8-3.

Management VRF Overview

By creating a management VRF, all CE routers can be managed from a single spot; and by virtue of the transitivity rule, which states that only routes originating from the VRF are exported, routing separation is guaranteed between CE routers. Figure 8-4 illustrates the importing and exporting of routes from the management VRF. All CE routers are easily identified, as they all should use a circuit address from the same service provider?managed address space.

Example 8-1 allows connection to a service provider network management station. When provisioning VRFs, access to the network management stations would be part of the basic provisioning process, so what is shown in Example 8-1 would be typical across all VRFs.

Example 8-1. NOC Station Access to Customer VRFs

ip vrf VPN_Allied_Industries

 rd 64700:10600

 route-target export 64700:10600

 route-target import 64700:10600

!

! Export routes to the Management VRF

!

 route-target export 64700:1

!

! Import Management host(s) only

!

 route-target import 64700:10

In addition to the normal import/export route-targets for the VRF, two more route-targets are specified. The route-target export 64700:1 exports all routes from this VRF to the management VRF using the extended community attribute 64700:1. The route-target import 64700:10 imports any VPN-IPv4 addresses with the extended community attribute 64700:10, which identifies any management host(s).

Example 8-2 shows a management VRF example. This VRF is configured at the PE that connects to the service provider management subnet. Multiple PEs could provide the network management service for redundancy.

Example 8-2. Network Management VRF Configuration

ip vrf VPN_Management

 rd 64700:1

 import map IN-Management

 export map OUT-Management

 route-target export 64700:1

 route-target import 64700:1

!

! Only allow CE circuit addresses into VRF

!

ip prefix-list CE-Circuits seq 10 permit 172.24.6.0/16 ge 30

ip prefix-list CE-Circuits seq 10 permit 172.24.7.0/16 ge 30

!and so on...

!

route-map IN-Management permit 10

 match ip address prefix-list CE-Circuits

!

! Set Management Workstation route to 64700:10

!

route-map OUT-Management permit 10

 match ip address 20

 set extcommunity rt 64700:10

!

! Access List to identify management hosts (one line for each host)

!

access-list 20 permit 146.171.66.90 0.0.0.0

...

!

! Set a static route to Management workstation(s)

!

ip route vrf VPN_Management 146.171.66.0 255.255.255.0 <NH Int> <NH IP>

!

! Enter other routes to Management hosts...

Management VRF Details

This VRF uses the service provider?specified "well known" RD and RT of 64700:1. In addition to the normal import/export route-targets for the VRF, two route-maps are specified: IN-Management and OUT-Management.

The IN-Management route-map limits any imported addresses to that of the circuit address space. In other words, the address prefix must be a subnet 30 bits long, and it must begin with 172.24.6.0, 172.24.7.0, and so on?the address pools to which all CE circuit addresses belong.

All other routes in the customer VRF are excluded. The service provider could poll a CE hub or switch by simply providing it with 172.24.x.x address, which could be included in the VRF.

The management VRF is connected to an interface that could originate from many subnets, in addition to the management subnet. For purposes of example, let's say the management subnet is 146.171.66.0. To guarantee that only the host addresses of management workstations are included in the customer VRF, static routes should be used to identify each management address individually.

The static route command specifies the management VRF, the host address, the next hop interface, and the next hop address.

The OUT-Management route-map sets all management host addresses (those that match the access-list 20) to the extended-community attribute of 64700:10, which is then imported into the customer VRF with a corresponding import map.

As an example, the management workstation has an IP address of 146.171.66.90. In the above configuration, a static route is added for each management workstation so we can manage routes down to individual hosts. This prevents CEs from accessing anything else on the management subnet except for the specific hosts.

If these host address routes are redistributed to a CE via a routing protocol such as RIPv2, the CE may re-advertise the route back to the PE in a summarized form even though split-horizon is enabled. (Do not send routes out an interface you received them on.)

For example, if the host route 146.171.66.90 255.255.255.255 is advertised to a CE with auto-summary enabled, that route will be summarized to a B-class address of 146.171.0.0 255.255.0.0 and advertised back to the PE.

The split-horizon process will allow the route to pass because it is not the same as the route that was received.

Two ways to avoid this problem are to

• Turn auto-summary off at the CE

• Use route distribution filtering at the PE