Administering Customer Edge Routers

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

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

• Unmanaged CEs are wholly outside the service provider's administrative domain. Thus, there is no required connectivity from the CEs to the service provider network.

There is no IP connectivity between a PE and an unmanaged CE. Thus, there is no access to the unmanaged CE via SNMP, Telnet, and so forth. The service provider cannot view the configuration or the traps of the unmanaged CE.

• An unmanaged CE has independent IP addressing (nonlinear and overlapping).

• 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

• Customer routing and service provider routing are entirely separate.

• 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.

• The CoS parameters are on the CE.

• 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.

• NetFlow Collector devices are operational.

The MPLS VPN 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, MPLS VPN 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.

1. Define the VPN in MPLS VPN Solution, and use the MPLS VPN Solution software to update the configuration of the PE and CE that supports it on the network management subnet.

2. Go to Cisco IP Manager and define the CE object.

This assumes that all PE objects are already defined in Cisco IP Manager.

Use Cisco IP Manager to configure customer-facing LANs, customer-facing routing protocols, user names, passwords, VTY definitions, and so forth.

5. Update Cisco IP Manager's definition of the CE object to reflect the changes made to user names and passwords.

At this point, you are ready to go to MPLS VPN Solution. In MPLS VPN Solution, it is possible to define the target to represent the CE in such a way that the synchronization with Cisco IP Manager works smoothly. Note that a well-chosen naming scheme helps until Cisco IP Manager and MPLS VPN Solution are more fully integrated.

It should not be necessary to provide MPLS VPN Solution user names and passwords, but it would still be a good idea to do so in case configuration file collection is required while the CE is still attached to the network management subnet. If you do provide MPLS VPN Solution user names and passwords, the optimal IP address would be the alias offered by the terminal server for access to the CE (not the address of the terminal server itself).

6. In MPLS VPN Solution, provision normally, and request downloading of configlets to both the PE and the CE.

When the product uses Cisco IP Manager for downloading configlets, it uses the administrative information in Cisco IP Manager, including terminal server access for the CE. The PE provisions normally.

7. The PE is now in the field, but configured for service; the CE is in the network management subnet, fully configured and ready to ship.

8. Finally, update the object definitions in Cisco IP Manager and MPLS VPN Solution to reflect the fact that the CE has been shipped.

You can remove the terminal server information and replace it with the management IP address given by MPLS VPN Solution.

• Permit from {Cisco IP Manager host, MPLS VPN Solution 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 MPLS VPN 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, MPLS VPN Solution 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 <MPLS VPN Solution Host/32 CE_address>
IP route VRF Management <CIPM Host/32 CE_address>

The term "VRF Management" is for illustration purposes only; MPLS VPN 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 {MPLS VPN Solution Host, CIPM Host}
deny everything else

This is simple, and it means customers cannot gain access to the Management CE.

Cisco recommends the following:

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

ip route vrf management MPLS VPN Solution 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 {MPLS VPN Solution host, CIPM host} to <pool
 deny all

The input access list is as follows:

 permit <pool to {MPLS VPN Solution 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 {MPLS VPN Solution 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.