Administering Customer Edge Routers

If the CEs are unmanaged, the provider can use IPv4 connectivity for all management traffic. VPNSC: MPLS Solution software is not employed for provisioning or managing unmanaged CEs.

Regarding unmanaged CEs, service providers should note the following considerations:

• Because unmanaged CEs are outside the service provider's administrative domain, the service provider does not maintain or configure unmanaged CEs.

• The service provider does not administer the following elements on the unmanaged CE:

  • IP addresses

  • Host name

  • Domain Name server

  • Fault management (and timestamp coordination by means of the Network Time Protocol)

  • Collecting, archiving, and restoring CE configurations

  • Access data such as passwords and SNMP strings on the unmanaged CE

• Prototype CE configlets are generated, but they are not automatically downloaded to the router.

• There is no configuration management.

  • With no configuration management, no configuration history is maintained and there is no configuration change management.

  • Changes to a service request (on the PE-CE link) are not deployed to the CE.

• There is no configuration auditing because there is no means to retrieve the current CE configuration.

• You can perform routing auditing.

• You can use the Service Assurance Agent (SA Agent) to measure response times between shadow routers, but you cannot use SA Agent to measure response times between CEs.

The VPNSC: MPLS Solution network management subnet is required when the provider's service offering entails the management of CEs. Once a CE is in a VPN, it is no longer accessible by means of conventional IPv4 routing unless one of the techniques described in this chapter is employed.

The MPE needs access to the following devices:

Device	Connectivity	Function
1. Customer Edge Routers (CEs)	Access from the network management subnet into the VPNs	Provision or change configuration and collect SA Agent performance data
2. Shadow routers	Access from the network management subnet into the VPNs	A simulated CE used to measure data travel time between two devices
3. Provider Edge Routers (PEs)	standard IP connectivity	Provision or change configuration
4. NetFlow Collector	standard IP connectivity	Collect data

At the current time, VPNSC: MPLS Solution recommends three main network management subnet implementation techniques:

When employing the Management VPN technique, the MPE-MCE link uses a management VPN to connect to managed CEs. To connect to the PEs and NetFlow Connector, the MPE-MCE link employs a parallel IPv4 link.

In the Extranet Multiple VPN (sometimes referred to as the rainbow VPN), several security and access list considerations exist, but these considerations are centralized at the MPE and MCE devices.

The MPE includes the BGP routes to all customer routes. This should constrained such that only the CE subnet routes are imported to the interior gateway protocol.

The Out-of-Band technique has the advantage of being relatively simple to set up, and no management VPN is required. However, its disadvantages are that it is expensive since it requires an IPv4 connection to each CE. Also, due to the delicate staging requirements for this technique, the Out-of-Band implementation does have a high degree of complexity.

• Permit from {Cisco IP Manager host, VPNSC host} to anything in the "pool."

• Deny all others.

Apply these access rules outbound on the CE on its interface up to the PE so that only VPNSC: MPLS Solution and Cisco IP Manager can send packets, and then only to management addresses. Additional rules of type are as follows:

• Permit from "pool" to {Cisco IP Manager host, VPNSC host} for TCP established.

• Deny all others.

These rules should apply on the CE as an input list on its link from the PE. Thus, only responses are allowed in—general CEs cannot start a session to the management machines—and then only from legal IP addresses.

Given these rules of type, only the CE can send packets into the network management subnet, and even those must be in response to a network management subnet query. Spoofing could be an issue, but for that Cisco recommends anti-spoofing access lists as part of the basic configuration of CEs at customer sites—deny all packets coming from within a site marked with a management address.) The CEs do not need the CE-PE link when returning management packets.

IP route VRF Management VPNSC_host/32 CE_address
IP route VRF Management CIPM_host/32 CE_address

The term "VRF Management" is for illustration purposes only; VPNSC: MPLS Solution builds all this and picks a name for the VRF.

To prevent injections of inappropriate routes, it is helpful to add this command:

IP route VRF Management 0.0.0.0/0 Null0

That is all you want to put in the local VRF table. From there, it dynamically learns all the routes to the other CEs.

However, you cannot prevent it also knowing a directly connected route for the link between this PE and the Management CE. You must protect against customer attempts to gain access to the Management CE. The access lists described above control only transit traffic across that CE.

Therefore, Cisco recommends that the PE have an access list applied outbound on the link to the CE in the following form:

permit packets to {VPNSC Host, CIPM Host}
deny everything else

This is simple and it prevents customers from gaining access to the Management CE.

Cisco recommends the following:

1. In the PE configuration file, enter the following commands:

ip route vrf management VPNSC_host ip/32 <mce
ip route vrf management CIPM_host ip/32 <mce

  To dump unknowns, add this command:

ip route vrf management 0.0.0.0/0 Null0

2. Whenever possible, use statics on the Management CE too—use a static or set of statics covering legal management addresses, as discussed above.

  The output access list: On the Management CE, connected to Link B (with access to the VPNs), make an output access list as follows:

 permit {VPNSC host, CIPM host} to <pool
 deny all

   The input access list is as follows:

 permit <pool to {VPNSC host, CIPM host} with tcp-established
 deny all

4. To protect the Management CE, create an output access list on the PE's link B interface:

 permit to {VPNSC host, CIPM host}
 deny all

5. If desired, also place an access list to protect the IPv4 link, depending on the service provider's own access needs to the network management subnet.