Cisco IOS XR Interface and Hardware Component Configuration Guide for the Cisco CRS Router, Release 4.3.x
Configuring the Satellite Network Virtualization (nV) System on the Cisco CRS Router
Downloads: This chapterpdf (PDF - 885.0KB) The complete bookPDF (PDF - 7.89MB) | Feedback

Configuring the Satellite Network Virtualization (nV) System on the Cisco CRS Router

Table Of Contents

Configuring the Satellite Network Virtualization (nV) System on the Cisco CRS Router

Contents

Prerequisites for Configuration

Overview of Satellite nV Switching System

Benefits of Satellite nV System

Overview of Port Extender Model

Features Supported in the Satellite nV System

Satellite System Physical Topology

Inter-Chassis Link Redundancy Modes and Load Balancing

Satellite Discovery and Control Protocols

Satellite Discovery and Control Protocol IP Connectivity

Quality of Service

Time of Day Synchronization

Satellite Chassis Management

Restrictions of the Satellite nV System

Implementing a Satellite nV System

Defining the Satellite nV System

Configuring the Host IP Address

Configuring the Inter-Chassis Links and IP Connectivity

Configuring Inter-Chassis Links and IP Connectivity in Redundant ICL mode

Auto-IP

Configuring the Satellite nV Access Interfaces

Plug and Play Satellite nV Switch Turn up: (Rack, Plug, and Go installation)

Upgrading and Managing Satellite nV Software

Prerequisites

Installing a Satellite

Monitoring the Satellite Software

Monitoring the Satellite Protocol Status

Monitoring the Satellite Inventory

Reloading the Satellite Device

Port Level Parameters Configured on a Satellite

Loopback Types on Satellite Ports

Configuration Examples for Satellite nV System

Satellite System Configuration: Example

Satellite Global Configuration

ICL (satellite-fabric-link) Interface Configuration

Satellite Interface Configuration

Satellite Management using private VRF

Additional References

Related Documents

Standards

MIBs

RFCs

Technical Assistance


Configuring the Satellite Network Virtualization (nV) System on the Cisco CRS Router


This module describes the configuration of the Satellite Network Virtualization system on the
Cisco CRS Router.

Table 2 Feature History for Configuring Satellite nV System

Release
Modification

Release 4.3.1

Support for Cisco CRS-3 Router with Cisco CRS-3 Modular Services Line Card as host was included.

Release 4.3.2

Multi-chassis and back to back support on Cisco CRS-3 Router was included.


Contents

Prerequisites for Configuration

Overview of Satellite nV Switching System

Overview of Port Extender Model

Implementing a Satellite nV System

Upgrading and Managing Satellite nV Software

Configuration Examples for Satellite nV System

Additional References

Prerequisites for Configuration

You must be in a user group associated with a task group that includes the proper task IDs. The command reference guides include the task IDs required for each command. If you suspect user group assignment is preventing you from using a command, contact your AAA administrator for assistance.

Before configuring the Satellite nV system, you must have these hardware and software installed in your chassis:

Host — Cisco CRS-3 Modular Services Line Card with fixed PLIM (14x10GE, 20x10GE, and MSC140). The Line card that hosts the Satellite nV device can be a Cisco CRS Multi Chassis and Back to Back system.

Satellite — Cisco ASR9000v.

Software — Cisco IOS XR Software Release 4.3.1 or later with hfr-asr9000v-nV-px.pie.

Overview of Satellite nV Switching System

The Satellite Network Virtualization (nV) service or the Satellite Switching System enables you to configure a topology in which one or more satellite switches complement one or more Cisco CRS-3 Routers, to collectively realize a single virtual switching system. In this system, the satellite switches act under the management control of the routers. The complete configuration and management of the satellite chassis and features is performed through the control plane and management plane of the
Cisco CRS-3 Router, which is referred to as the host.

Interconnection between the Cisco CRS-3 Router and its satellites is through standard Ethernet interfaces or bundle ethernet interfaces coming from a single modular services line card. All bundle members must be connected to the same satellite device.

When the Satellite nV service was introduced in Cisco IOS XR Software Release 4.3.x,
Cisco ASR 9000v was used as the satellite device. It had four 10 Gigabit ports that were used as Interchassis Links (ICL).

In general, the type of interface used on the host is decided on the basis of the satellite device used.
See Figure 1.

Figure 1

Satellite nV Switching System

This type of architecture can be realized in a carrier Ethernet transport network, with the satellite switches used as either access switches, or pre-aggregation and aggregation switches. These switches feed into the Cisco CRS-3 Router where more advanced Layer 2 and Layer 3 services are provisioned.

You can also utilize this model in a Fiber To The Business (FTTB) network application, where business internet and VPN services are offered on a commercial basis. Further, it can also be used in other networks, such as wireless or Radio Access Network(RAN) backhaul aggregation networks.

Benefits of Satellite nV System

The Satellite nV system offers these benefits:

1. Extended port scalability and density - You can create a virtual line card with more than 100 physical Gigabit Ethernet ports per slot. There is a significant increase of Ethernet port density in the resulting logical Cisco CRS-3 Router. For example, a single 14-port or 20-port Ten Gigabit Ethernet line card on the Cisco CRS-3 Router could integrate multiple satellite switches with a maximum of 100 Gig Ethernet ports per line card. This is beneficial because the Cisco CRS-3 Router has a per-slot non blocking capacity of up to 400 Gbps (with appropriate RSPs) and there is no other way of physically fitting hundreds of gigabit ethernet ports/ SFPs on the face plate of a single
Cisco CRS-3 line card.
As a result, in order to utilize the full capacity of an Cisco CRS-3 line card, it is necessary to physically separate out the ethernet ports, while maintaining logical management control. This would appear as if all ports were physically on a single large line card of the Cisco CRS-3 Router.

2. Reduced cost - All the core-routing capabilities and application features of the Cisco IOS XR software are available on low cost access switches.

3. Reduced operating expense - You can seamlessly upgrade software images, and also manage the chassis and services from a common point. This includes a single logical router view, single point of applying CLI or XML interface for the entire system of switches, a single point of monitoring the entire system of switches and a single point of image management and software upgrades for the entire system.

4. Enhanced feature consistency - All the features on the regular GigE ports of
Cisco CRS -3 Router are also available on the access ports of a satellite access switch in a functionally identical and consistent manner. The typical application of a satellite system would be in the access and aggregation layers of a network. By integrating the access switches along with the aggregation or core switch, you can ensure that there are no feature gaps between the access switch and the aggregation or core switch. All features, such as carrier ethernet features, QoS and OAM, function consistently, from access to core, because of this integrated approach.

5. Improved feature velocity - With the satellite solution, every feature that is implemented on the Cisco CRS-3 Router becomes instantly available at the same time in the access switch, resulting in an ideal feature velocity for the edge switch.

6. Better resiliency - The nV satellite solution enables better multi-chassis resiliency, as well as better end-to-end QoS. For more information on QoS capabilities, see Cisco IOS XR Quality of Service Configuration Guide for the Cisco CRS Router.

Overview of Port Extender Model

In the Port Extender Satellite switching system, a satellite switch is attached to its host through physical ethernet ports.

The parent Cisco CRS-3 Router is referred as the host in this model. From a management or a provisioning point of view, the physical access ports of the satellite switch are equivalent to the physical ethernet ports on the Cisco CRS-3 Router. You do not need a specific console connection for managing the Satellite Switching System, except for debugging purposes. The interface and chassis level features of the satellite are visible in the control plane of Cisco IOS XR Software running on the host. This allows the complete management of the satellites and the host as a single logical router.

Figure 2

Port Extender Satellite Switching System

In this model, a single Cisco CRS-3 Router hosts two satellite switches, SAT1 and SAT2, to form an overall virtual switching system; this is shown by the dotted line surrounding the Cisco CRS-3 Router, SAT1, and SAT2 in Figure 2.

This structure effectively appears as a single logical Cisco CRS-3 Router to the external network. External access switches A1, A2 connect to this overall virtual switch by physically connecting to SAT1 and SAT2 using normal ethernet links. The links between the satellite switches and the
Cisco CRS-3 Router are ethernet links, and are referred as ICLs (Inter-Chassis Links). The Cisco CRS-3 Router is referred as the host in this system. When there is congestion on the interchassis links, an inbuilt QoS protection mechanism is available for the traffic.


Note SAT1, SAT2, and the host Cisco CRS-3 Router need not be located in the same geographic location. This means that the ICLs need not be of nominal length for only intra-location or intra-building use. The ICLs may be tens, hundreds, or even thousands of miles in length, thereby creating a logical satellite switch spanning a large geography. This distance depends on the pluggables used on the CRS host and Satellite ICL port.


Features Supported in the Satellite nV System

This section provides details of the features of a satellite nV system.

Satellite System Physical Topology

The satellite system supports the point-to-point hub and spoke physical topology for the ICLs between satellite switches and the host Cisco CRS-3 Router. This topology allows a physical Ethernet MAC layer connection from the satellite to the Cisco CRS-3 Router. This can be realized using a direct Ethernet over Fiber or Ethernet over Optical transport (such as Ethernet over a SONET/ SDH/ CWDM/ DWDM network).

This topology also allows a satellite switch to be geographically at a separate location, other than that of the host Cisco CRS-3 Router.

Inter-Chassis Link Redundancy Modes and Load Balancing

The Satellite system supports these redundancy modes:

Non-redundant inter-chassis links mode - In this mode, there is no link level redundancy between inter-chassis links of a satellite.

Redundant inter-chassis links mode - In this mode, the link level redundancy between inter-chassis links are provided using a single link aggregation (LAG) bundle.

In the redundant ICL mode, the load balancing of traffic between members of the IC bundle is done using a simple hashing function based on the satellite access port ID, and not based on the flow based hash using L2 or L3 header contents from the packets. This ensures that a single ICL is used by all packets for a given satellite access port. As a result, the actions applied for QoS and other features consider all the packets belonging to a single satellite access port.


Note Both the Access Bundles and ICL bundles can co-exist, but not concurrently.


For more details on QoS application and configuration on ICLs, see Cisco IOS XR Modular Quality of Service Configuration Guide for the Cisco CRS Router.

Satellite Discovery and Control Protocols

A Cisco proprietary discovery and control protocol is used between the satellite switches and the host devices, to handle discovery, provisioning, and monitoring of the satellite devices from the host Cisco CRS-3 Satellite System in-band over the ICLs. The Satellite Discovery And Control (SDAC) Protocol provides the behavioural, semantic, and syntactic definition of the relationship between a satellite device and its host.

Satellite Discovery and Control Protocol IP Connectivity

The connectivity for the SDAC protocol is provided through a normal in-band IP routed path over the ICLs using private and public IP addresses appropriate for the carrier's network.

You can configure a management IP address on the host CLI for each satellite switch and corresponding IP addresses on the ICLs. You can select addresses from the private IPv4 address space (for example, 10.0.0.0/8 or 192.1.168.0/24) in order to prevent any conflict with normal service level IPv4 addresses being used in the IPv4 FIB. You can also configure a private VRF that is used for only satellite management traffic, so that the IP addresses assigned to the satellites can be within this private VRF. This reduces the risk of address conflict or IP address management complexity compared to other IP addresses and VRFs that are used on the router.

Quality of Service

Most Layer-2, Layer-3 QoS and ACL features are supported on Satellite Ethernet interfaces that are similar to normal physical Ethernet interfaces, with the exception of any ingress policy with a queueing action. However, for QoS, there may be some functional differences in the behavior because in the
Cisco IOS XR Software Release 4.3.1, user-configured MQC policies are applied on the
Cisco CRS-3 Router, and not on the satellite switch interfaces. For more detailed information on QoS policy attributes, features, and their configuration, see Cisco IOS XR Modular Quality of Service Configuration Guide for the Cisco CRS Router.


Note User-configured QoS policies are independent of any default port level QoS that are applied in order to handle IC link congestion and oversubscription scenarios. In addition to the default port-level QoS applied on the satellite system ports, there is also some default QoS applied on the host side, to the ingress and egress traffic from and to the Satellite Ethernet ports.


Time of Day Synchronization

The Time of Day parameter on the satellite switch is synchronized with the time of day on the host. This ensures that time stamps on debug messages and other satellite event logs are consistent with the host, and with all satellite switches across the network. This is achieved through the SDAC Discovery Protocol from the host to the satellite switch when the ICLs are discovered.

Satellite Chassis Management

The chassis level management of the satellite is done through the host because the satellite switch is a logical portion of the overall virtual switch. This ensures that service providers get to manage a single logical device with respect to all aspects including service-level, as well as box-level management. This simplifies the network operations. These operations include inventory management, environmental sensor monitoring, and fault/alarm monitoring for the satellite chassis through the corresponding CLI, SNMP, and XML interfaces of the host.


Note The Satellite nV System hardware features, support for SFPs, and compatible topologies are described in the Cisco ASR 9000 Series Aggregation Services Router Hardware Installation Guide.


Restrictions of the Satellite nV System

These are some of the software restrictions of the Cisco CRS-3 Satellite System:

The inter-chassis link redundancy is supported only through the static EtherChannel, and not through LACP based link bundles. Minimum and maximum link commands are not applicable when ICL is a bundle.

If a satellite system is operating in redundant ICL mode, then you cannot configure link bundles of any form (with or without LACP) on the access ports of that same satellite switch.

If a satellite system is operating in redundant ICL mode, then Ethernet OAM features are not supported on the access ports of that satellite.

These features, protocols, and topologies are not supported on the Cisco CRS-3 Satellite System:

L2VPN

QinQ

TE tunnel over Satellite interface

Pseudowire Headend

GRE over satellite interface

L2TPv3

Multicast over satellite interface

Satellite interface as core facing interface

801.1ad/.1ah encapsulation

HSRP and VRRP

HW DBA based netflow

If a satellite system is operating in redundant ICL mode, then Cisco Discovery Protocol(CDP) and Link Layer Discovery Protocol(LLDP) are not supported on the access ports of that satellite.

You cannot connect the same satellite box to more than one Cisco CRS-3 Modular Services Line Card.

Both the access link bundles and ICL bundles can co-exist, but not concurrently.

BFD echo mode is not supported on Satellite Gigabit Ethernet links. BFD Asynchronous mode is supported on the Satellite Gigabit Ethernet links that are not part of a bundle. When Satellite links are part of the Access bundle, only BFD over Logical Bundles (BLB) is supported.

Adding non-ICL links (normal TenGigE links) to ICL bundle is not supported. This configuration is not rejected, but the behavior is unpredictable.

Bundling of satellite and non-satellite interfaces is not supported.

Bundling of satellite interfaces from different satellite boxes is not supported.

Only Cisco CRS-3 Modular Services Line Card with fixed PLIM (14x10GE and 20x10GE) can be used to interconnect with the Satellite boxes.

All bundle members must be from same satellite. The maximum number of bundle members is restricted to 44.

ISSU and MDR are not supported on the satellite.

Implementing a Satellite nV System

The Interface Control Plane Extender(ICPE) infrastructure has a mechanism to provide the Control Plane of an interface physically located on the Satellite device in the local Cisco IOS XR software. After this infrastructure is established, the interfaces behave like other physical ethernet interfaces on the router.

The ICPE configuration covers these functional areas, which are each required to set up full connectivity with a Satellite device:

Defining the Satellite nV System

Configuring the Host IP Address

Configuring the Inter-Chassis Links and IP Connectivity

Plug and Play Satellite nV Switch Turn up: (Rack, Plug, and Go installation)

Defining the Satellite nV System

Each satellite that is to be attached to Cisco IOS XR software must be configured on the host, and also be provided with a unique identifier. In order to provide suitable verification of configuration and functionality, the satellite type, and its capabilities must also be specified.

Further, in order to provide connectivity with the satellite, an IP address must be configured, which will be pushed down to the satellite through the Discovery protocol, and allows Control protocol connectivity.

This task explains how to define the satellite system by assigning an ID and basic identification information.

SUMMARY STEPS

1. configure

2. nv

3. satellite Satellite ID

4. serial-number string (Optional)

5. description string (Optional)

6. type type

7. ipv4 address address

8. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

nv

Example:

RP/0/RP0/CPU0:router(config)# nv

Enters the nV configuration submode.

Step 3 

satellite Sat ID

Example:

RP/0/RP0/CPU0:router(config-nV)# satellite <100-239>

Declares a new satellite that is to be attached to the host and enters the satellite configuration submode.

The Cisco CRS Router chassis supports 139 satellite racks. Satellite Ids ranges from 100 to 239.

Step 4 

serial-number string

Example:

RP/0/RP0/CPU0:router(config-nV)# serial-number CAT1521B1BB

(Optional) Serial number is used for satellite authentication.

Step 5 

description string

Example:

RP/0/RP0/CPU0:router(config-nV)# description Milpitas Building12

(Optional) Specifies any description string that is associated with a satellite such as location and so on.

Step 6 

type type_name

Example:

RP/0/RP0/CPU0:router(config-nV)# satellite 200 type ?

asr9000v Satellite type

Defines the expected type of the attached satellite.

Step 7 

ipv4 address address

Example:

RP/0/RP0/CPU0:router(config-nV)# ipv4 address 10.22.1.2

Specifies the IP address to assign to the satellite. ICPE sets up a connected route to the specified IP address through all configured ICLs.

Step 8 

end

or

commit

Example:

RP/0/RP0/CPU0:router(config)# end

or

RP/0/RP0/CPU0:router(config)# commit

Saves configuration changes.

When you issue the end command, the system prompts you to commit changes:

Uncommitted changes found, commit them before 
exiting(yes/no/cancel)? 
[cancel]:
 
        

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.

Configuring the Host IP Address

This procedure gives you the steps to configure a host IP address on a loopback interface.

SUMMARY STEPS

1. configure

2. interface Loopback0

3. ipv4 address 8.8.8.8 255.255.255.255

4. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

interface loopback0

Example:

RP/0/RP0/CPU0:router(config)# interface loopback0

Specifies the loopback address for the interface.

Step 3 

ipv4 address

Example:

RP/0/RP0/CPU0:router(config-int)# ipv4 address 8.8.8.8 255.255.255.255

Configures the host IP address on a loopback interface.

Step 4 

end

or

commit

Example:

RP/0/RP0/CPU0:router(config)# end

or

RP/0/RP0/CPU0:router(config)# commit

Saves configuration changes.

When you issue the end command, the system prompts you to commit changes:

Uncommitted changes found, commit them before 
exiting(yes/no/cancel)? 
[cancel]:
 
        

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.

Configuring the Inter-Chassis Links and IP Connectivity

Inter-Chassis Links (ICLs) need to be explicitly configured, in order to indicate which satellite is expected to be connected. You must also specify the access port, that is down-stream GigE ports, which crosslink up to the Host through the configured ICL.

In order to establish connectivity between the host and satellite, suitable IP addresses must be configured on both sides. The satellite IP address is forwarded through the Discovery protocol. The configuration is described in the section, Defining the Satellite nV System.


Note This configuration shows the use of the global default VRF. The recommended option is to use a private VRF for nV IP addresses as shown in the Satellite Management using private VRF subsection under Satellite System Configuration: Example.


This procedure shows the configuration of ICL in non-reundant mode.

SUMMARY STEPS

1. configure

2. interface interface_name

3. description

4. ipv4 point-to-point (optional)

5. ipv4 unnumbered Loopback0 (optional)

6. nv

7. satellite-fabric-link satellite id

8. remote-ports interface-type

9. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

interface interface-name

Example:

RP/0/RP0/CPU0:router(config)# interface TenGigE0/2/0/0

The supported inter-chassis link interface types are limited by the connectivity provided on the supported satellites. GigabitEthernet, TenGigE, and Bundle-Ether interfaces are the only supported ICL types.

Step 3 

description

Example:

RP/0/RP0/CPU0:router(config-interface)# description To Sat5 1/46

Specifies the description of the supported inter-chassis link interface type.

Step 4 

ipv4 point-to-point

Example:

RP/0/RP0/CPU0:router(config-interface)# ipv4 point-to-point

(Optional) Configures the IPv4 point to point address.

Step 5 

ipv4 unnumbered loopback0

Example:

RP/0/RP0/CPU0:router(config-interface)# interface unnumbered loopback0

(Optional) Configures the IPv4 loopback address on the interface.

Step 6 

nv

Example:

RP/0/RP0/CPU0:router(config-if)# nv

Enters the Network Virtualization configuration mode.

Step 7 

satellite-fabric-link satellite <id>

Example:

RP/0/RP0/CPU0:router(config-int-nv)# satellite-fabric-link satelite 200

Specifies that the interface is an ICPE inter-chassis link.

Step 8 

remote-ports interface-type

Example:

RP/0/RP0/CPU0:router(config-int-nv)# remote-ports GigabitEthernet 0/0/0-43

Configures the remote satellite ports 0 to 43.

Step 9 

end

or

commit

Example:

RP/0/RP0/CPU0:router(config)# end

or

RP/0/RP0/CPU0:router(config)# commit

Saves configuration changes.

When you issue the end command, the system prompts you to commit changes:

Uncommitted changes found, commit them before 
exiting(yes/no/cancel)? 
[cancel]:
 
        

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.

Configuring Inter-Chassis Links and IP Connectivity in Redundant ICL mode

This procedure describes the configuration of ICL in redundant mode.

SUMMARY STEPS

1. configure

2. interface bundle-ether id

3. description

4. nv

5. satellite-fabric-link satellite id

6. remote-ports interface-type

7. interface interface-type

8. bundle id id mode on

9. end
or
commit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/RP0/CPU0:router# configure

Enters global configuration mode.

Step 2 

interface bundle-ether id

Example:

RP/0/RP0/CPU0:router(config)# interface Bundle-Ether 100

Specifies the supported inter-chassis link interface type.

Step 3 

description

Example:

RP/0/RP0/CPU0:router(config-interface)# description To Sat5 1/46

Specifies the description of the supported inter-chassis link interface type.

Step 4 

nv

Example:

RP/0/RP0/CPU0:router(config-if)# nv

Enters the Network Virtualization configuration mode.

Step 5 

satellite-fabric-link satellite <id>

Example:

RP/0/RP0/CPU0:router(config-int-nv)# satellite-fabric-link satelite 200

Specifies that the interface is an ICPE inter-chassis link.

Step 6 

remote-ports interface-type

Example:

RP/0/RP0/CPU0:router(config-int-nv)# remote-ports GigabitEthernet 0/0/0-43

Configures the remote satellite ports 0 to 43.

Step 7 

interface interface_type

Example:

RP/0/RP0/CPU0:router(config-interface)# interface TenGigE0/0/0/6

Configures the specified interface.

Step 8 

bundle id mode on

Example:

RP/0/RP0/CPU0:router(config-interface)# bundle id 100 mode on

Specifies the bundle id and activates it.

Step 9 

end

or

commit

Example:

RP/0/RP0/CPU0:router(config)# end

or

RP/0/RP0/CPU0:router(config)# commit

Saves configuration changes.

When you issue the end command, the system prompts you to commit changes:

Uncommitted changes found, commit them before 
exiting(yes/no/cancel)? 
[cancel]:
 
        

Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.

Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.

Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.

Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.


Note For information on QoS configuration on ICLs , see Cisco IOS XR Modular Quality of Service Configuration Guide for the Cisco CRS Router.


Auto-IP

The Auto IP feature improves the plug-and-play set up of an nV satellite system. With the Auto IP feature, IP connectivity to the satellite is automatically provisioned. As a result:

The nV Satellite Loopback interface is created on the host

Loopback interface is given an IP address from a private satellite VRF

Satellite fabric links are unnumbered to the loopback interface

The IP address assigned to satellite is auto-generated from the satellite VRF

In the case of Auto IP, you do not need to provide IP address on the nv satellite global configuration and on the ICL. In the case of manual IP, you need to provide IP address on the nV satellite global configuration and on ICL.

The auto-IP feature assigns an IP address in the format 10.x.y.1 automatically, where:

x is the top (most significant) 8 bits of the satellite ID

y is the bottom 8 bits (the rest) of the satellite ID

Configuration Example for Auto IP

configure
nv satellite 150
type asr9000v
 
   
configure
interface TenGigabitEthernet 0/1/0/0
nv satellite-fabric-link satellite 150
remote-ports GigabitEthernet 0/0/0-5
 
   

You do not have to assign IP for the satellite and 10.0.<satellite-id>.1 is assigned automatically.

nV-Loopback0 is created automatically. **nVSatellite VRF is created automatically, and assigned to nV-Loopback0. 10.0.0.1/32 is assigned to nV-Loopback0.

nV-Loopback0 is referenced by the Ten Gigabit Ethernet interface automatically when it is made as an ICL.

There is no CLI to enable Auto IP. If you do not configure manual IP, this will be invoked.


Note You can also override the Auto IP feature by using the standard IP configuration.


Configuring the Satellite nV Access Interfaces

The access GigabitEthernet interfaces on the satellite are represented locally in Cisco IOS XR Software using interfaces named GigabitEthernet similar to other non-satellite GigabitEthernet interfaces. The only difference is that the rack ID used for a satellite access GigabitEthernet interface is the configured satellite ID for that satellite.

These interfaces support all features that are normally configurable on GigabitEthernet interfaces (when running over a physical ICL), or Bundle-Ether interfaces (when running over a virtual ICL).

Plug and Play Satellite nV Switch Turn up: (Rack, Plug, and Go installation)

1. Unpack the satellite rack, stack, and connect to the power cord.

2. Plug in the qualified optics of correct type into any one or more of the SFP+ slots and appropriate qualified optics into SFP+ or XFP slots on the host. Connect through the SMF/MMF fiber.


Note Connect the 10GigE fibers from the host to any of the 10G SFP+ ports on the satellite device in any order.



Note The Satellite nV service can use the Cisco CRS-3 Router as host. The Cisco ASR 9000v can be used as satellite device.


3. Configure the satellite nV system through CLI or XML on the host 10GigE ports. Configure the host for nV operations as described in the sections Defining the Satellite nV System, Configuring the Host IP Address, and Configuring the Inter-Chassis Links and IP Connectivity.

4. Power up the chassis of the satellite device.


Note For power supply considerations of ASR 9000v, refer to the Appendix C, Cisco ASR 9000 and Cisco CRS Satellite Systems (ASR 9000v) of the Cisco ASR 9000 Series Aggregation Services Router Hardware Installation Guide online.


5. You can check the status of the satellite chassis based on these chassis error LEDs on the front face plate.

If the Critical Error LED turns ON, then it indicates a serious hardware failure.

If the Major Error LED turns ON, then it indicates that the hardware is functioning well but unable to connect to the host.

If the Critical and Major LEDs are OFF, then the satellite device is up and running and connected to the host.

You can do satellite ethernet port packet loopback tests through the host, if needed, to check end to end data path.


Note When the satellite software requires an upgrade, it notifies the host. You can do an inband software upgrade from the host, if needed. Use the show nv satellite status on the host to check the status of the satellite.


Upgrading and Managing Satellite nV Software

Satellite software images are bundled inside a PIE and the PIE name is dependent on the type of satellite, such as hfr-asr9000v-nV-px.pie within the
Cisco CRS-3 Router package. The Cisco IOS XR software production SMU tool can be used to generate patches for the satellite image in the field to deliver bug fixes or minor enhancements without requiring a formal software upgrade.

This section provides the commands to manage the satellite nV Software.

Prerequisites

You must have installed the satellite installation procedure using the Plug and Play Satellite installation procedure. For more information, see Plug and Play Satellite nV Switch Turn up: (Rack, Plug, and Go installation).

Installing a Satellite

To download and activate the software image on the satellite, use the install nv satellite satellite ID / all transfer/activate commands. The transfer command downloads the image to the satellite. When the transfer command is followed by the activate command, the software is activated on the satellite.

Example

RP/0/RP0/CPU0:sat-host# install nv satellite 100 transfer
 
   
Install operation initiated successfully.
RP/0/RP0/CPU0:sat-host#RP/0/RP0/CPU0:May  3 20:12:46.732 : icpe_gco[1146]: 
%PKT_INFRA-ICPE_GCO-6-TRANSFER_DONE : Image transfer completed on Satellite 100 
 
   
RP/0/RP0/CPU0:sat-host# install nv satellite 100 activate
 
   
Install operation initiated successfully.
LC/0/2/CPU0:May  3 20:13:50.363 : ifmgr[201]: %PKT_INFRA-LINK-3-UPDOWN : Interface 
GigabitEthernet100/0/0/28, changed state to Down 
RP/0/RP0/CPU0:May  3 20:13:50.811 : invmgr[254]: %PLATFORM-INV-6-OIROUT : OIR: Node 100 
removed 
 
   

Note If the activate command is run directly, then the software image is transferred to the satellite and also activated.


Example

RP/0/RP0/CPU0:sat-host# install nv satellite 101 activate
 
   
Install operation initiated successfully.
 
   
RP/0/RP0/CPU0:sat-host#RP/0/RP0/CPU0:May  3 20:06:33.276 : icpe_gco[1146]: 
%PKT_INFRA-ICPE_GCO-6-TRANSFER_DONE : Image transfer completed on Satellite 101 
RP/0/RP0/CPU0:May  3 20:06:33.449 : icpe_gco[1146]: %PKT_INFRA-ICPE_GCO-6-INSTALL_DONE : 
Image install completed on Satellite 101 
RP/0/RP0/CPU0:May  3 20:06:33.510 : invmgr[254]: %PLATFORM-INV-6-OIROUT : OIR: Node 101 
removed

Note For the satellite image upgrade to work, you must ensure that the management-plane CLI is not configured on the Cisco CRS-3 Router. If it is configured, then you need to add this exception for each of the 10GigE interfaces, which are the satellite ICLs.


You can include the exception using this CLI:

control-plane
 management-plane
  inband
    !
   !
   interface TenGigE0/0/0/5  <=== To enable TFTP on nV satellite ICL
allow TFTP

If you do not include this exception, then the image download and upgrade fails.

Monitoring the Satellite Software

To perform a basic status check, use the show nv satellite status brief command.

RP/0/RP0/CPU0:router# show nv satellite status brief
 
   
Sat-ID  Type      IP Address    MAC address     State
------  --------  ------------  --------------  --------------------------------
100     asr9000v  101.102.103.105  dc7b.9426.1594  Connected (Stable)              
200     asr9000v  101.102.103.106  0000.0000.0000  Halted; Conflict: no links configured
220               194.168.9.9   0000.0000.0000  Halted; Conflict: satellite has no type 
configured
 
   

Note To check if an upgrade is required on satellite, run the show nv satellite status satellite satellite_id command.


Example

RP/0/RP0/CPU0:router# show nv satellite status satellite 100
 
   
Satellite 100
-------------
  State: Connected (Stable)
  Type: asr9000v
  Description: sat-test
  MAC address: dc7b.9427.47e4
  IPv4 address: 100.1.1.1
  Configured Serial Number: CAT1521B1BB
  Received Serial Number: CAT1521B1BB
  Remote version: Compatible (latest version)
    ROMMON: 125.0 (Latest)
    FPGA: 1.13 (Latest)
    IOS: 200.8 (Latest)
  Configured satellite fabric links:
    TenGigE0/2/0/6
    --------------
      State: Satellite Ready
      Port range: GigabitEthernet0/0/0-9
    TenGigE0/2/0/13
    ---------------
      State: Satellite Ready
      Port range: GigabitEthernet0/0/30-39
    TenGigE0/2/0/9
    --------------
      State: Satellite Ready
      Port range: GigabitEthernet0/0/10-19
 
   

Note In this example output, Remote version, ROMMON, FPGA, and IOS must show the latest version. If it does not, an upgrade is required on the satellite. The version numbers displayed are the installed version on the ASR 90000v. If a version number is displayed, instead of latest key word in the above output, that would correspond to the ASR9000v image bundles in the satellite pie.


Monitoring the Satellite Protocol Status

To check the status of the satellite discovery protocol, use the show nv satellite protocol discovery command.

RP/0/RP0/CPU0:router# show nv satellite protocol discovery brief
 
   
Interface       Sat-ID  Status                          Discovered links
--------------  ------  ------------------------------  -----------------------
Te0/1/0/0       100     Satellite Ready                 Te0/1/0/0              
Te0/1/0/1       100     Satellite Ready                 Te0/1/0/1              
 
   

(Or)

RP/0/RP0/CPU0:router# show nv satellite protocol discovery interface TenGigE 0/1/0/0
 
   
  Satellite ID: 100
  Status: Satellite Ready
  Remote ports: GigabitEthernet0/0/0-15
  Host IPv4 Address: 101.102.103.104
  Satellite IPv4 Address: 101.102.103.105
  Vendor: cisco, ASR9000v-DC-E
  Remote ID: 2
  Remote MAC address: dc7b.9426.15c2
  Chassis MAC address: dc7b.9426.1594

To check the status of the satellite control protocol status, use the show nv satellite protocol control command.

RP/0/RP0/CPU0:router# show nv satellite protocol control brief
 
   
Sat-ID  IP Address     Protocol state  Channels
------  ------------   --------------  -----------------------------------
    101.102.103.105  Connected     Ctrl, If-Ext L1, If-Ext L2, X-link, Soft Reset, 
Inventory, EnvMon, Alarm
 
   
 
   
RP/0/RSP0/CPU0:shanghai# sh nv satellite protocol control   
Satellite 100
-------------
  IP address: 101.102.103.105
  Status: Connected
  Channels:
    Control
    -------
      Channel status: Open
      Messages sent: 24 (24 control), received: 23 (23 control).
    Interface Extension Layer 1
    ---------------------------
      Channel status: Open
      Messages sent: 7 (3 control), received: 14 (2 control).
    Interface Extension Layer 2
    ---------------------------
      Channel status: Open
      Messages sent: 11 (3 control), received: 10 (2 control).
    Interface Extension Cross-link
    ------------------------------
      Channel status: Open
      Messages sent: 4 (3 control), received: 3 (2 control).
....
 
   
 
   

Monitoring the Satellite Inventory

You can use the show inventory chassis, show inventory fans, show environment temperatures commands in the admin configuration mode to monitor the status of satellite inventory.

RP/0/RP0/CPU0:router(admin)# show inventory chassis
 
   
NAME: "module 0/RSP0/CPU0", DESCR: "ASR9K Fabric, Controller, 4G memory"
PID: A9K-RSP-4G, VID: V02, SN: FOC143781GJ
...
NAME: "fantray SAT100/FT0/SP", DESCR: "ASR9000v"
PID: ASR-9000v-FTA, VID: V00 , SN: CAT1507B228
 
NAME: "module SAT100/0/CPU0", DESCR: "ASR-9000v GE-SFP Line Card"
PID: ASR-9000v, VID: N/A, SN: 
NAME: "module mau GigabitEthernet100/0/CPU0/8", DESCR: "CISCO-AVAGO     "
PID: SFP-GE-S, VID: V01, SN: AGM1424P08N
 
   
NAME: "module mau TenGigE100/0/CPU0/3", DESCR: "CISCO-FINISAR   "
PID: SFP-10G-SR, VID: V02, SN: FNS144502Y3
 
   
NAME: "power-module SAT100/PM0/SP", DESCR: "ASR-9000v Power Module"
PID: ASR-9000v, VID: N/A, SN: 
NAME: "Satellite Chassis ASR-9000v ID 100", DESCR: "ASR9000v"
PID: ASR-9000v-AC-A, VID: V00 , SN: CAT12345678
 
   
 
   
 
   
RP/0/RP0/CPU0:router(admin)# show inventory fans 
 
   
NAME: "fantray SAT100/FT0/SP", DESCR: "ASR9000v"
PID: ASR-9000v-FTA, VID: V01 , SN: CAT1531B4TC
 
   
NAME: "fantray SAT101/FT0/SP", DESCR: "ASR9000v"
PID: ASR-9000v-FTA, VID: V01 , SN: CAT1542B0LJ
 
   
NAME: "fantray SAT102/FT0/SP", DESCR: "ASR9000v"
PID: ASR-9000v-FTA, VID: V01 , SN: CAT1531B4T7
 
   
 
   
RP/0/RP0/CPU0:sat-host(admin)# show inventory | b GigabitEthernet100/
 
   
NAME: "module mau GigabitEthernet100/0/CPU0/0", DESCR: "CISCO-FINISAR   "
PID: SFP-GE-S, VID:  , SN: FNS11350L5E
 
   
NAME: "module mau GigabitEthernet100/0/CPU0/1", DESCR: "CISCO-FINISAR   "
PID: SFP-GE-S, VID: V01, SN: FNS0934M290
 
   
NAME: "module mau GigabitEthernet100/0/CPU0/2", DESCR: "CISCO-FINISAR   "
PID: SFP-GE-S, VID:  , SN: FNS12280L59
 
   
 
   
RP/0/RP0/CPU0:router(admin)# show environment temperatures 
 
   
R/S/I   Modules Sensor                  (deg C)
0/RSP0/*
        host    Inlet0                  33.1
        host    Hotspot0                46.9
                              
0/RSP1/*
        host    Inlet0                  32.1
        host    Hotspot0                45.9
                              
0/0/*
        host    Inlet0                  37.3
        host    Hotspot0                52.3
                              
0/1/*
        spa0    InletTemp               34.0
        spa0    Hotspot                 34.5
                              
        spa1    LocalTemp               38.0
        spa1    Chan1Temp               36.0
        spa1    Chan2Temp               39.0
        spa1    Chan3Temp               39.0
        spa1    Chan4Temp               48.0
                              
        host    Inlet0                  36.1
        host    Hotspot0                64.0
                              
0/2/*
        host    Inlet0                  39.2
        host    Hotspot0                54.6
                              
0/3/*
        host    Inlet0                  41.3
        host    Hotspot0                48.5
                              
0/FT0/*
        host    Inlet0                  42.3
        host    Hotspot0                36.1
                              
0/FT1/*
        host    Inlet0                  40.4
        host    Hotspot0                35.8
                              
SAT100/FT0/*
        host    Hotspot0                53.0
                              
 
   
SAT101/FT0/*
        host    Hotspot0                56.0
                              
 
   
SAT102/FT0/*
        host    Hotspot0                53.0

Reloading the Satellite Device

In order to reload the satellite device, use the hw-module satellite satellite id/all reload command.

Example

RP/0/RP0/CPU0:router# hw-module satellite 101 reload 
 
   
Reload operation completed successfully.
RP/0/RP0/CPU0:May  3 20:26:51.883 : invmgr[254]: %PLATFORM-INV-6-OIROUT : OIR: Node 101 
removed
 
   

Port Level Parameters Configured on a Satellite

These are the port-level parameters that can be configured on a satellite nV system:

Admin state (shut and no shut)

Ethernet MTU

Ethernet MAC Address.

Ethernet link auto-negotiation that includes,

Half and full duplex

Link speed

Flow control

Static configuration of auto-negotiation parameters such as speed, duplex, and flow control

Carrier delay

Layer-1 packet loopback which includes,

Line loopback

Internal loopback

All satellite access port features on Cisco ASR 9000 Series Router.

Loopback Types on Satellite Ports

There are two types of loopback interfaces that can be configured on satellite ports. They are,

Line Loopback

Internal Loopback

These illustrations show how the loopback interface types function on a satellite.

Figure 3

Line Loopback

Figure 4

Internal Loopback

You can specify the type of loopback to be used, as specified in this example:

Interface GigabitEthernet 100/0/0/0
loopback line | internal

Configuration Examples for Satellite nV System

This section contains these examples:

Satellite System Configuration: Example

Satellite Global Configuration

ICL (satellite-fabric-link) Interface Configuration

Satellite Interface Configuration

Satellite Management using private VRF

Satellite System Configuration: Example

This example shows a sample configuration for setting up the connectivity of a Satellite System.

Satellite Global Configuration

The satellite ID, type, serial number, description, and satellite IP address are configured in the satellite global configuration submode:

nv
 satellite 100
  type asr9000v
  serial-number CAT1521B1BB
  description milpitas bldg20
  ipv4 address 10.0.0.100
 !
! 

ICL (satellite-fabric-link) Interface Configuration

On the interface connected to the satellite (TenGig or Bundle interface), the ports associated with the satellite ID must be specified. All fabric links connected to the same satellite must use the same (host) IPv4 address. The same or different host IPv4 addresses can be used for the same host to connect to different satellites.

interface Loopback1000
 ipv4 address 10.0.0.1 255.0.0.0
interface TenGigE0/2/1/0
 description To Sat5 1/46
 ipv4 point-to-point
 ipv4 unnumbered Loopback1000
 nv
  satellite-fabric-link satellite 200
   remote-ports GigabitEthernet 0/0/0-30
  !
 !
!

Note These examples illustrate using IP addresses from the global VRF of the router for satellite management traffic. As discussed Satellite Discovery and Control Protocol IP Connectivity section, this can also be done using a private VRF, to prevent IP address conflict with the global VRF. In this case, the loopback interface and the ICL interfaces in the examples must be assigned to the private VRF dedicated for satellite management traffic.


Satellite Interface Configuration

The Satellite interface can be used as any other regular GigabitEthernet interfaces:

interface GigabitEthernet200/0/0/0
ip address 99.0.0.1 255.255.255.0
!
! 
 
   
interface GigabitEthernet200/0/0/2
bundle id 100 mode active
!
! 

Satellite Management using private VRF

You can use a special private VRF instead of the global default routing table, to configure the loopback interface and ICLs used for satellite management traffic. IP addresses in this VRF will not conflict with any other addresses used on the router.

router(config)# vrf NV_MGMT_VRF
router(config)# address ipv4 unicast
 
   
router(config)# interface Loopback 1000 
router(config)# vrf NV_MGMT_VRF
router(config)# ipv4 address 10.0.0.1 / 24
 
   
router(config)# interface TenGige 0/1/0/3  
router(config)# vrf NV_MGMT_VRF
router(config)# ipv4 point-to-point  
router(config)# ipv4 unnumbered Loopback 1000
router(config)# nv  
router(config-nv)# satellite-fabric-link satellite 200
router(config-nv)# remote-ports GigabitEthernet 0/0/28-39
router(config)# nv satellite 200 
router(config)# ipv4 address 10.0.0.2 / 24  
 
   

Additional References

These sections provide references to related documents.

Related Documents

Related Topic
Document Title

Cisco IOS XR master command reference

Cisco IOS XR Master Commands List

Satellite System software upgrade and downgrade on Cisco IOS XR Software

Cisco IOS XR Getting Started Guide for the Cisco CRS Router

Cisco IOS XR interface configuration commands

Cisco IOS XR Interface and Hardware Component Command Reference

Satellite QoS configuration information for the Cisco IOS XR software

Cisco IOS XR Modular Quality of Service Configuration Guide for the Cisco CRS Router

Bidirectional Forwarding Detection features on the satellite system

Cisco Routing Configuration Guide

Multicast features on the satellite system

Cisco Multicast Configuration Guide

Broadband Network Gateway features on the satellite system

Cisco Broadband Network Gateway Configuration Guide

AAA related information and configuration on the satellite system

Cisco System Security Configuration Guide

Information about user groups and task IDs

Configuring AAA Services on Cisco IOS XR Software module of Cisco IOS XR System Security Configuration Guide


Standards

Standards
Title

No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.


MIBs

MIBs
MIBs Link

There are no applicable MIBs for this module.

To locate and download MIBs for selected platforms using
Cisco IOS XR software, use the Cisco MIB Locator found at the following URL:

http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml


RFCs

RFCs
Title

None

N.A


Technical Assistance

Description
Link

The Cisco Technical Support website contains thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.

http://www.cisco.com/support