Introduction
Satellite for ASR9000 is an innovative new technology on the ASR9K family. There is a good guide on satellite available here, but there are always more questions to be answered. This FAQ tries to keep track of them.
Features
Q. What is the Auto-IP feature of nV satellite ?
A. Auto-IP automates the configuration of the management path between the ASR9K and the satellite. This is the new default configuration mode for all satellites available from XR 4.3.1 release onwards. With Auto-IP, a special internal VRF (**nVSatellite) is automatically created on the nV host 9K, loopback interfaces are automatically created, IP addresses automatically assigned within this internal VRF on both the loopback interface and to each satellite and the ICLs automatically configured to use IP unnumbered and re-use the auto-created IP address of the host loopback interface. Thus all of the nV management plane configuration is auto-created without the user needing to specify anything other than the satellite ID. The full explicit manual configuration of all aspects of the nV management VRF, IP addresses, loopback interface and IP unnumbered is still supported and if configured, these will over-ride the auto-created values generated by the Auto-IP feature.
Q. Which IOS-XR features are unsupported on nV satellite interfaces ? When will they be supported ?
A. Nearly all of the features that are supported on normal ethernet interfaces of an ASR9K are also supported on nV satellite access ethernet interfaces in a functionally identical manner. Some features that are caveated in certain software releases are:
(a) BFD is not supported on nV satellite interfaces in the 4.2.X and 4.3.0 software releases.
- This restriction is removed starting from the 4.3.1 release.
(b) When bundled ICLs are used, CDP is not supported on nV acess interfaces.
- This restriction is expected to be removed in the upcoming 5.1.1 release.
(c) When bundled ICLs are used, Ethernet link OAM is not supported on nV access interfaces.
- This restriction is expected to be removed in the upcoming 5.1.1 release.
(d) When bundled ICLs are used, link bundles are not supported on nV access interfaces.
- This restriction is expected to be removed in a future release. Until then link bundles can be supported on nV access interfaces that are mapped to non-bundled ICLs.
(e) A mix of bundled and non-bundled ICLs is not supported on the same satellite switch in the 4.2.X software releases.
- This restriction has been removed from the 4.3.0 release onwards.
Q. Can one have a mix of bundled and non-bundled ICLs on the same satellite switch ?
A. Yes. Any mix of bundled and non bundled ICLs can co-exist on the same nV satellite device. (In the 4.2.x release, all ICLs on a satellite had to be in the same ICL bundle or not be bundled. Since 4.3.0, this restriction is removed).
Q. Can ICLs of the same satellite terminate on different ASR9K line cards ?
A. Yes. As long as the line card is from the Typhoon line card family or newer, different ICLs from a satellite can terminate on any mix of line cards on the ASR9K.
Functional Behavior, Operation, Monitoring
Q. Is an nV satellite device fully transparent to all L2 and L3 control protocols ?
A. Yes. All L2/ L3 control protocols on the nV access ports are transparently forwarded between the satellite and the ASR9K. Ethernet link level PAUSE frames are the only frame types that are not forwarded by the satellite to the ASR9K.
Q. What happens to the data path traffic and access ports if an ICL link goes down ?
A. Assuming there are other ICLs still active, the control/ management plane of a satellit is not impacted when an ICL link goes down. If the ICL is non-redundant (non-bundled) then all access ports mapped to it immediately transition to DOWN state, the TX laser is disabled on the access ports and data plane traffic is impacted. In the ASR9K control plane, these access interfaces transition to DOWN state. Of course if the ICL was part of a redundant ICL and at least one another link within that ICL bundle was still UP then all access ports would get redistributed over the remaining ICL links and the access ports would not transition to DOWN state.
Note:
Related Information
