Securely Managing the Core Network
The configuration for managing the core network is slightly different than managing CE devices because the addresses of the PE routers exist in the global routing table and not in a VRF. There are several ways PE management may be achieved:
P and PE management via VRF table
P and PE management via global table
Building on Example 8-2 in the previous section, Figure 8-4 shows an example for P and PE management via VRF table where the P and PE loopback addresses (in the service provider's case, 172.24.4.0) are in the global routing table, while the address of the management workstation is in the VRF. To create connectivity between the MPLS core network and the management workstation, a global static route pointing to the MPLS network loopbacks must be injected into the VRF, and a static route pointing to the management workstation must be injected into the global routing table.
NOTE
One could also provide all Ps and PEs with a second loopback address for management purposes and put the second loopback into the management VPN. In fact, this is a commonly deployed practice today.
For the purposes of this example, let's assume the following:
The management workstations are connected to FA0/1/0 on a router called TSG000_GTWY_01.
The IP subnet that the management workstations reside on is 146.171.66.0 255.255.255.0.
The gateway router is connected to the GSR called TSG000_CLSR_01 via POS0/0/0.
The following configuration illustrates the commands necessary. The first static route command injects a route into the VPN_Management VRF (defined previously), indicating that all loopback routes in the 172.24.4.0 space are reachable via the interface pos0/0/0, which happens to point to the GSR. The pos0/0/0 is the interface on the PE (7507) that the downstream P (GSR) router is connected to.
ip route vrf VPN_Management 172.24.4.0 255.255.255.0 pos0/0/0 ip route 146.171.66.0 255.255.255.0 fa0/1/0
The second static route exists in the global routing table of the P and PE network (outside the VRF) and provides reachability back to the management subnet that is physically connected on fa0/1/0.
NOTE
This return route does not need to be associated with a VRF. A VRF may be configured on an interface, but this does not prevent routes in the global table from also using this interface like a normal routing network that does not use MPLS.
There is a small caveat with this solution: the route for the loopback addresses is pointing to the next hop interface. Why is the next hop not the loopback address of the PE directly connected to the management subnet? If a route is injected into a PE pointing to itself, no recursive lookups will be done for the subsequent routes, so nothing will be reachable. The routes need to point to the next hop for this to work.
The PE that the management VRF is defined on will be reachable, but via the next hop, which will route the packet back to the PE. This is not an elegant solution, but it appears to work. A workaround for managing the directly connected PE is to use a PE?CE circuit address instead for this PE. In this case, it would be the IP address configured on fa0/1/0.
NOTE
We do realize that for a large service provider, provisioning static routes is not optimal, and therefore we assume the use of a provisioning tool such as Cisco IP Solution Center (ISC) to automate these provisioning examples for both Layers 2 and 3 in addition to Metro Ethernet and traffic engineering tunnel deployment in order to accommodate a fuller service management palette required for the service provider.
Another way of managing the core network is to simply connect the management network directly to an interface defined in the global routing table so that it does not have a VRF associated with it. This would be the simplest and most straightforward way to manage the core network, as shown in Figure 8-5.
Figure 8-5. Managing the Core Network
