|
|
When accessing the Cisco MPLS VPN solution over a DOCSIS 1.0-compliant hybrid fiber-coaxial (HFC) network, the PC client obtains a DHCP address from the secondary IP address range configured on the cable subinterface attached to its cable access router. A session initiated by a client as depicted in Figure 5-1:
1. Transmits through the cable access router attached to the VPN subinterface determined by its DHCP assigned IP address
2. Routes packets to and from the PC across the MPLS VPN cloud
3. Distributes customer network packets through C back to the TAG VPN to the user
In a DOCSIS 1.0-compliant HFC network, all traffic from a given cable access router is identified by the same Service ID (SID). On the VHG/PE, all traffic with the same SID value terminates on the same subinterface. At the VHG/PE, the subinterface is statically configured to map all traffic to a specific VRF. As a result, traffic from all CPEs behind a given cable access router is mapped to the same VPN. There is no remote user authorization and authentication necessary in this solution. Address assignment is DHCP-based. Accounting is based on Netflow.
The VPN to which a remote cable access router is attached is determined by the IP address assigned by a DHCP server. Cisco Network Registrar (CNR) is the DHCP server used in this solution. Client class processing is used on CNR to determine which subnet and subsequent VPN the cable access router attaches to, and is based on the cable access router MAC address.
 |
Note Whenever a service provider (SP) is mentioned in this section, it refers to the multiple service operator (MSO) in cable terminology. |
Cisco uBR924 cable access routers are used to connect the remote access users to the SP DOCSIS 1.0-compliant HFC network. At the residential side, the cable access router is attached to a LAN connecting to the remote users' host PCs.
|
Note The Cisco uBR924 router is EOL. Please refer to the EOL page for further information http://www.cisco.com/univercd/cc/td/doc/pcat/elhw__g1.htm#xtocid0 and/or the Cisco Product page http://www.cisco.com/public/products_prod.shtml . |
The following VHG/PE platforms are used:
|
Note The Cisco uBR7223 and Cisco uBR7246 routers are EOL. Please refer to the EOL page for further information http://www.cisco.com/univercd/cc/td/doc/pcat/elhw__g1.htm#xtocid0 and/or the Cisco Product page http://www.cisco.com/public/products_prod.shtml . |
The SP access network is a DOCSIS 1.0-compliant HFC network. Cable access routers connect over the HFC network to a Cisco uBR7223 or Cisco uBR7246. At the headend, the Cisco uBR7223 or Cisco uBR7246 routes packets between the HFC network and the MPLS VPN backbone. In this case, the Cisco uBR7223 or Cisco uBR7246 functions as the PE router.
|
Note The Cisco uBR7223 and Cisco uBR7246 routers are EOL. Please refer to the EOL page for further information http://www.cisco.com/univercd/cc/td/doc/pcat/elhw__g1.htm#xtocid0 and/or the Cisco Product page http://www.cisco.com/public/products_prod.shtml . |
Cisco Network Registrar (CNR) serves as the DHCP server for this solution. CNR 3.5 or 4.0 are appropriate. CNR 3.5(1) runs on Windows NT 4.0, Windows 2000, Solaris 2.5.1, Solaris 2.6, and Solaris 7.
|
Note CNR 3.5, CNR 3.5.1, and CNR 4.0 are EOL. Please refer to the EOL page for further information
http://www.cisco.com/univercd/cc/td/doc/pcat/elhw__g1.htm#xtocid0 and/or the Cisco Product
page http://www.cisco.com/public/products_prod.shtml . Cisco Network Registrar's 3.5(1) GUI also runs on Windows 95 and Windows 98. |
DHCP is used for address assignment in DOCSIS 1.0 SID to MPLS VPN integration. DHCP requests are handled by one or a combination of the following methods:
Both the cable access router and the corresponding VHG/PE interface must have IP addresses. The address for the subinterface must be provisioned. The cable access router requests an address from DHCP when it boots up. The request is relayed by the VHG/PE to the appropriate DHCP server. It could be a SP DHCP server or the VPN DHCP server. The DHCP server assigns an address to the cable access router based on its MAC address and the GIADDR of the VHG/PE that forwarded the request. The cable access router's MAC address is provisioned at the DHCP server and is bound to a specific service/VPN.
|
Note Each subinterface and each VRF must be configured with a primary and secondary IP address. Cable access routers get their IP addresses from a primary IP address space, whereas PCs on the LAN behind the cable access router get their IP addresses from a secondary address space. |
The addresses assigned to the cable access router and the VHG/PE's subinterface may be private addresses (assigned from the service provider's private pool) on the condition that these interfaces must be reachable from other PE routers connected to the same VPN.
When host PC located on the cable access router's LAN boots up, it initiates a similar series of steps in that it sends a DHCP discover request, which the cable access router passes on to the VHG/PE router. The VHG/PE relays the request to the appropriate DHCP server. The DHCP server assigns an address to the PC from the VPN's address pool, that is, from the ISP's address pool.
Netflow is used for accounting in DOCSIS 1.0 SID to MPLS VPN integration. Netflow collects per-flow statistics such as time of first packet, time of last packet, number of packets, and number of octets. A flow is identified by source address, source port, destination address, and destination port. When configured for Netflow accounting, the VHG/PE collects per-flow accounting data and exports it to a Netflow Collector workstation, which stores it in flat files. A Netflow Analyzer is then used for analyzing the collected data.
The DOCSIS 1.0 SID to MPLS VPN integration supports two types of core networks, IP MPLS and ATM MPLS.
The network management components relevant for this solution are:
|
Note The Cisco uBR7223, Cisco uBR7246, and Cisco uBR924 routers are EOL. Please refer to
the EOL page for further information
http://www.cisco.com/univercd/cc/td/doc/pcat/elhw__g1.htm#xtocid0 and/or the
Cisco Product page
http://www.cisco.com/public/products_prod.shtml . CCM Release 2.2 requires a Sun Ultra 60 workstation for small deployments (up to 20,000 cable modems) or a Sun Enterprise 250 workstation for large deployments (over 20,000 cable modems) with dual processors, Solaris 2.6 OS, 9 GB of available disk space, and 2 GB of RAM. |
Fault monitoring is performed at the device and service levels.
At the device level, fault monitoring is performed by the element managers. (CEMF has an event manager component.) CCM provides fault monitoring per dial port.
CIC is used at the service level to provide event correlation and filtering, monitoring, customer and administrative partitioning, and flow-through integration to other systems. CIC is an OEM product from Micromuse's NetCool. CIC's release 2.0 provides eventing at the IP VPN service level through integration with VPNSC.
SLA reporting is performed using the Service Assurance Agent (SA Agent) in IOS. In conventional MPLS VPN customer sites, VPNSC configures SA Agent probes on managed CE routers or shadow CE routers. However, in remote access sites, there is no real CE router. The SA Agent probes are configured on the PE routers at the POPs and are not configured on the NAS, because a NAS is not connected to a particular VPN prohibiting probes being routed using VRFs. VPNSC collects statistics from the SA Agent MIB and provides reports on a per-VPN basis. For PPP users, performance numbers are derived from AR.
Concord's Net Health provides performance and SLA reporting at a VPN service level through integration with VPNSC.
RPMS is used to provide SLA information regarding incoming call rates per VPN customers, and so on.
The SA Agent probes are configured on the cable access routers at the CPE.
Provisioning Cable DOCSIS 1.0 SID to MPLS VPN integration entails:
1. Initial configuration through router pre-staging, using config Xpress, using an element manager (e.g., SCM), using CIPM templates, or any combination of the above. This configuration is not necessarily tied to VPN services and includes:
a. Configuring the Cisco uBR7200 VHG/PE routers and cable access routers at the CPE using SCM.
|
Note In this solution the Cisco IOS command line interface (CLI) is used for configuring routers and Access Registrar (see the "Cisco IOS Software Fundamentals" section) and a graphical user interface (GUI) for RPMS and CNR. |
2. Although this is tied to customer provisioning, it is different from the VPN service provisioning (for example, adding a site, adding a Cisco uBR7223 or Cisco uBR7246, or adding a VPN). An example would be a customer with an existing VPN requesting access for cable users. This includes:
|
Note VPNSC 1.2 supports the provisioning of SID to VRF mapping and the relevant configuration on both VHG/PE and CPE routers. Refer to the MPLS VPNSC documentation suite at http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/index.htm. |
3. VPN service configurations are repetitive tasks that are critical to automate, including:
c. Actual service activation, performed by VPNSC, where a VPN is created and CE sites and remote access sites are added to it.
|
Note For VPNSC configuration, refer to the MPLS VPNSC documentation suite at http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/index.htm. |
Perform the following steps to configure the Cisco uBR7200 VHG/PE routers and cable access routers at the CPE using SCM.
|
Note This example is just one way of performing this configuration task. |
a. Router (config)# ip vrf management
b. Router (config-vrf)# rd 100:1
c. Router (config-vrf)# route-target export 100:1
d. Router (config-vrf)# route-target import 100:1
e. Router (config-vrf)# route-target import 1000:1000
f. Router (config)# ip vrf vpn2
g. Router (config-vrf)# rd 200:1
h. Router (config-vrf)# route-target export 200:200
i. Router (config-vrf)# route-target export 1000:1000
j. Router (config-vrf)# route-target import 200:200
k. Router (config-vrf)# route-target import 100:1
l. Router (config)# ip vrf vpn3
m. Router (config-vrf)# rd 300:1
n. Router (config-vrf)# route-target export 300:300
o. Router (config-vrf)# route-target export 1000:1000
The management VPN learns the routes from the other VRFs from the import statement. The other two VPNs (referred to as "vpn2" and "vpn3") export their routes to the management VPN and import the management VPN's routes. Refer to the "Sample VHG/PE Configuration File" section for a complete sample Cisco uBR7246 configuration file featuring this type of VPN configuration.
|
Note The management VPN exports and imports routes to and from each of the other VPNs. Nonmanagement VPNs do not exchange information with one another, however, thus preserving isolation between nonmanagement VPNs. |
Step 2 Configure the cable subinterfaces on the VHG/PE by entering the following IOS command lines.
For provisioning and management:
a. Router (config)# interface Cable3/0.1
b. Router (config-if)# ip vrf forwarding management
For VPN cable access router and VPN users subnets
a. Router (config)# interface Cable3/0.2
b. Router (config-if)# ip vrf forwarding vpn2
c. Router (config-if)# ip address 24.25.12.1 255.255.255.0 secondary
d. Router (config-if)# ip address 24.25.13.1 255.255.255.0
e. Router (config-if)# cable dhcp-giaddr policy
f. Router (config-if)# cable helper-address 24.25.1.18 cable-modem
For non-VPN cable and users subnets
a. Router (config)# interface Cable3/0.3
b. Router (config-if)# ip address 24.25.15.1 255.255.255.0 secondary
c. Router (config-if)# ip address 24.25.14.1 255.255.255.0
d. Router (config-if)# cable dhcp-giaddr policy
e. Router (config-if)# cable helper-address 24.25.1.18 cable-modem
The first subinterface is placed in the management VPN. It is configured with a cable helper-address that forwards all DHCP requests to a Cisco Network Register DHCP server. The CNR DHCP server is connected to a router interface within the management VPN, either on this router or on a remote router. Create cable subinterfaces for each VPN and for non-VPN users, if required. Create a primary and a secondary IP address for each subinterface. The primary IP address subnet is used by the cable access routers and the secondary IP address subnet is used by the hosts connected to the cable access router. The cable DHCP-GIADDR policy command instructs the VHG/PE to differentiate DHCP requests from a cable access router and a host behind the cable access router. If different IP addresses are listed by the cable helper-address for hosts and cable access routers, the request is sent to different DHCP servers.
The DHCP-GIADDR command also causes the VHG/PE to set the GIADDR field of PC DHCP requests to that of the secondary interfaces IP address. This enhances the network administrators ability to define DHCP scopes on the Cisco Network Register (CNR) server.
In this configuration, VPN users are connected to cable interface 3/0.2, and non-VPN users attach to 3/0.3.
Both non-VPN and VPN cable access routers receive IP addresses from the same DHCP server. The VPN hosts obtains IP addresses from a DHCP server within the VPN. The non-VPN hosts obtain IP addresses from a server reachable from the global routing table.
The sharing of routes between the management VPN and user VPN allows the user VPN cable access routers to obtain and renew their IP addresses. The non-VPN hosts need additional routing configuration commands to obtain and renew their IP addresses.
Since the DHCP request from the non-VPN user cable access router enters the network on a non-VPN interface and the DHCP server is connected to the management VPN, the global routing table requires a route to the DHCP server. The easiest way to achieve this is to configure a static route on the router connected to the DHCP server, and redistribute the static route into the global routing table. The DHCP server's router interface is in the management VPN, which must have a route back to the user's subnet. A simple way to achieve this is to place a static route within the management VPN pointing at a P router's interface. The P router uses the global routing table to reach the user's subnet.
The keyword global should be used with the static route. For example, if the DHCP server were connected to a router that is remote to the VHG/PE, the static route could be "ip route vrf vpn1 24.25.17.0 255.255.255.0 195.10.20.1" global, where 195.10.20.1 is a P router's interface.
CNR uses client class processing and secondary scopes to assign the correct IP address to the VPN and non-VPN cable access routers. The VPN cable access routers have their MAC addresses listed in a client class. The client class is tied to a scope selection tag. When a DHCP request is received from a cable access router that matches a client listed in a client class, the DHCP scope selected must have the included selection tag attached. Because VPN cable access routers use client class processing, it is a good idea to use it for non-VPN cable access routers, as well. The client class "default" is used to avoid listing each MAC address for the non-VPN cable access routers. This client class matches all MAC addresses that are not contained in another client class. Its scope selection tag selects a non-VPN cable access router scope. Scopes that provide IP addresses for hosts do not need to use client class processing, or selection tags. The DHCP discover packet from a host carries the GIADDR of the host subnet. CNR uses this field to select the correct scope.
CNR currently has a limit of 30 tags. If more than 30 scopes must be created, the use of the include and exclude tag scope selection feature must be employed. A client class can specify which scope is to be selected by both include tag and exclude tag statements. In this manner the tags can be used in a binary fashion. A scope can have multiple tags attached to it. For example, if 11 tags are defined, a scope could have three of them attached to it. The client class for this scope would specify inclusion of these three tags and exclusion of the other eight. The requested scope would be unique in that it had the three included tags attached to it and no others tags.
When any cable access router boots for the first time, the VHG/PE forwards its DHCP discover packet as if it is connected to the first logical subinterface on the VHG/PE. It sets the GIADDR field of the DHCP DISCOVER packet equal to the IP address of the first logical subinterface. CNR uses the GIADDR field to determine from which scope the IP address is to be assigned. In the following scenario, CNR uses the GIADDR field of the DHCP discover packet to determine which scope should be used to provide the requested IP address. It does this before performing client class processing. Because the initial DHCP discover packet from every cable modem has its GIADDR field set to the IP address of the first logical cable subinterface, the scope that matches this GIADDR is selected. If a single IP address is contained within this scope and it is reserved to a dummy MAC address, CNR determines that there are no more IP addresses available within that scope. CNR then examines any scopes that are secondary to this scope and then uses client class processing to determine the correct scope. For this reason, all of the scopes used to provide cable modem IP addresses must be secondary scopes to the scope whose address range contains the IP address of the first logical cable subinterface.
Cisco recommends that you do not assign IP addresses from the address space of the first logical subinterface in this solution. Instead, configure the scope for the logical subinterface's IP address range to contain only a single IP address, and reserve that IP address to a nonexistent MAC address.
If interface bundling is not used on the VHG/PE, there must be a separate group of primary and secondary scopes for each cable interface. This is because the VHG/PE sets the GIADDR field of the cable access router's initial DHCP DISCOVER packet equal to the IP address of the first logical interface subinterface on every physical interface. Likewise, if there are multiple VHG/PE routers in the network, there must be separate primary and secondary scope combinations for each router.
In this example, the scope that covers the IP address range of the first logical cable subinterface is displayed on the CNR GUI in Figure 5-3.
|
Note For Cisco Network Registrar (CNR) configuration details, refer to http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/ciscoasu/nr/nr3-5/index.htm and http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/mplscabl.htm. |
Step 2 Reserve a dummy MAC address.
Its only IP address is reserved to a dummy MAC address (Figure 5-4), so no IP addresses are assigned from this scope on the CNR GUI Reservations tab.
Step 3 Assign the scope for VPN cable access router IP addresses.
The scope provides IP addresses for VPN cable access routers on the CNR GUI General tab in Figure 5-5.
Step 4 Configure a secondary scope.
Figure 5-6 shows a secondary scope to the logical first interfaces scope on the CNR GUI Advanced tab.
Step 5 Attach a scope selection tag of tag-VPN-cable access router to this scope.
Step 6 Create two client classes and attach "Includes" scope selection tags.
The client class VPN-Modem requires that any scope, provided for devices with MAC addresses listed within it, have a selection tag of "tag-VPN-Modem" attached to it (Figure 5-8). A client class can have multiple "Includes" tags attached.
Step 7 Place the MAC address for the VPN cable access routers in the client-class VPN-Modem.
The MAC addresses for the VPN cable access routers are matched by "default" on the CNR GUI Client tab, shown in Figure 5-9.
Perform the following steps to configure the VPN/ISP DHCP server.
|
Note The GIADDR of the DHCP request is set to the secondary IP address of the respective cable subinterface. |
Perform the following steps to configure a new customer's cable access router.
|
Note A TFTP server providing DOCSIS 1.0 cable access router configuration files, and time-of-day server, must be configured in the network. |
Posted: Fri Mar 28 16:08:11 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
