on 07-14-2013 05:11 AM
This document provides a guide on how to use the satellite (ASR9000v) with the ASR9000 and ASR9900 series routers. It will be discussed what you can and cannot do, how to verify the satellite operation and use cases.
This document is written assuming that 5.1.1 or greater software release will be used.
Satellite is a relatively new technology that was introduced in XR 4.2.1. Satellite provides you a great and cheap way to extend your 1G ports by using this port-extender which is completely managed out of the ASR9000. The advantage is that you may have 2 devices, but 1 single entity to manage. All the satellite ports are showing up in the XR configuration of the ASR9000.
Another great advantage of the Satellite is that you can put it on remote locations, miles away from the ASR9000 host!
Although there is a limit to the number of satellites you can connect to an ASR9000 (cluster), the Satellite general concept of ASR9000 is shown here in this picture:
The physical connections are very flexible. The link between the Satellite and the ASR9000 is called the ICL or "Inter Chassis Link".
This link transports the traffic from the satellite ports to the 9000 host.
In the ASR9000 host configuration you define how the satellite ports are mapping between the ICL and the satellite ports.
You can statically pin ports from the Satellite to a single uplink (that means there is no protection, when that uplink fails, those satellite
ports become unusable), or you can bundle uplinks together and assign a group of ports to that bundle. This provides redundancy,
but with the limitation that the satellite ports that are using an uplink bundle, can't be made part of a bundle themselves.
We'll talk about restrictions a bit later.
In the picture below you see Access Device A1 connecting with a bundle that uses uplink (green) to the 9k host LC-2.
A second satellite has all their ports in a bundle ICL.
Note that there is no bandwidth constraints enforced, so theoretically you can have a 2 member ICL bundle and 30 Satellite ports mapped to it, but that would mean there is oversubscription.
While the ASR9000v/Satellite is based on the Cisco CPT-50, you cannot convert between the 2 devices by loading different software images.
You can't use the 9000v as a standalone switch, it needs the ASR9000 host.
Visual differences include that the 9000v starts the port number at 0, where the CPT starts at 1. Also the CPT has 4 different power options
and the ASR9000v only 3: AC-A, DC-A, DC-E (A for Ansi, E for ETSI).
Satellite packet format over L1 topologies looks like this; there is a simple sneaky dot1q tag added which we call the nV tag:
In L2 topologies, such as simple ring, we use dot1ad.
There is a license required to run the ASR9000v. There are 3 licenses for 1, 5, or 20 Satellites per 9k host named:
While licenses are not hard enforced, this meaning the system will still work even though a license may not be present, however you are urged to obtain the proper license, syslog messages will show the "violation of use".
Note when using simple ring, a host license for each satellite is needed on each host. E.g. a simple ring with three satellites requires six A9K-NVSAT1-LIC licenses.
A variety of optics are supported on the ASR9000v, they may not be always the same as the ASR9000. Reference this link for the supported optics for ASR9000/9000v.
When using Tunable optics for the 9000v, pay attention to the following:
(*) note for the tunable optic on the IRL you need to set the wavelength the first time via the 9000v shell on insertion of the optic before shipping it to the destined location.
Handling of Unsupported Optics
For the 9000v ports we do not support the 'service unsupported-transceiver' or 'transceiver permit pid all' commands.
The satellite device simply flags an unsupported transceiver without disabling the port or taking any further action. As long as the pluggable is readable by the satellite the SFP may work, but there are no additional 'hacks' such as the hidden commands beyond what is shown as supported in the tables from the supported optic reference link.
The following software and hardware requirements exist for the ASR9000v. Although support started in XR4.2.1 My personal recommendation is to go with XR43 (latest) as many initial restrictions are lifted from the first release:
Minimum version is XR 4.2.1
Note: If the wrong port is used for ICL then the link will stay down on the 901. Once the correct ICL port is used and the 9K configured then a reload of the 901 will need to occur for the link to come up and the 901 become recognized as a satellite.
Generally speaking all features supported on physical GigE ports of ASR9K are also automatically supported on the GigE ports of the
satellite switch such as L2, L3, multicast, MPLS, BVI, OAM … (everything that works on a normal GigE).
–L1 features: applied on the satellite chassis
1) The following features are not supported on satellite ports in 5.1.1
*Need to update this*
2) When the ICL is a link bundle, there are some restrictions :
QoS can be applied on the ASR9000 host (runs on the NP where the satellite ports have their interface descriptors) or offloaded to the satellite
When you have oversubscription, that is more then the number of 1G ports compared to the ICL total speed there could be a potential issue. However there is an implicit trust model for all high priority traffic.
Automatic packet classification rules determine whether a packet is control packet (LACP, STP, CDP, CFM, ARP, OSPF etc), high priority data (VLAN COS 5,6,7, IP prec 5, 6, 7) or normal priority data and queued accordingly
For the downstream direction, that is 9000 host to the Satellite, the "standard" QOS rules and shaping are sufficient enough to warrant the delivery of high priority packets to the satellite ports. (e.g. inject to wire etc).
As the ICL link between the satellite and host may be oversubscribed by access interfaces, configuring QoS on the satellite itself is optimal for avoiding the lose of high priority traffic due to congestion. This feature was introduced in 5.1.1
3 steps to configuring QoS offload
INPUT access interface (CLI config) example:
class-map match-any my_class
match dscp 10
end-class-map
!
policy-map my_policy
class my_class
set precedence 1
!
end-policy-map
!
interface GigabitEthernet100/0/0/9
ipv4 address 10.1.1.1 255.255.255.0
nv
service-policy input my_policy
!
Traffic is hashed across members of this ICL LAG based on satellite access port number. No packet payload information (MAC SA/ DA or IP SA/ DA) used in hash calculation. This ensures that QoS applied on ASR9K for a particular satellite access port works correctly over the entire packet stream of that access port. Current hash rule is simple (port number modulo # of active ICLs)
Plug-and-play installation: No local config on satellite, no need to even telnet in!
It is recommended to use the auto-IP feature, no loopback or VRF need to be defined. A VRF **nVSatellite will be auto-defined and does not count towards the number of VRFs configured (for licensing purposes).
Optional config secret password for satellite login. Note that the username is 'root'
There are two options for ICL:
That is static pinning; designate some ports from the satellite to use a dedicated uplink.
Using a bundle ICL that provides for redundancy when one uplink fails.
All interfaces mapped to an ICL bundle:
ASR9000 TenG interface putting into bundle mode ON (No LACP support)
Define the bundle ethernet on the ASR9000 host, and designate which ports will be mapped to the bundle:
Because of the order and batching in which things get applied in XR there are some things that you need to know when it comes down to negating certain config which additions of others.
Examples of this are:
In such cases, failures are expected to be seen; generally speaking, failures are expected to be deterministic, and workarounds available
(re-apply the configuration in two commit batches)
Recommendation to users is to commit ICL configuration changes in separate commits to Satellite-Ether configuration changes
Starting in 5.1.1 many new features were added to expand upon the basic single host hub-and-spoke model. These features take more configuration than the base satellite configuration and will be discussed below.
Starting in 5.1.1 the ability for a satellite (hub-and-spoke) or a ring of satellites (simple ring) to be dual-homed to two hosts was added. (nV Edge acts as one logical router)
With this configuration one ASR9K host is the active and the other is standby. Data and control traffic from the satellite will flow to the active host, but both hosts will send and receive management traffic via the SDAC protocol. This is used to determine connectivity, detect failures, sync the configuration, etc.
The two hosts communicate management information via ICCP with a modified version of SDAC called ORBIT.
Supported Topologies:
Hub-and-spoke dual hosts
9000v with 10G ICL or bundle ICL
901 with 1G ICL
9000v (10G) or 901 (1G) using L2 fabric sub-interfaces
Satellites may be partitioned
Simple ring dual hosts
9000v with 10G ICL
901 with 1G ICL
Satellites may not be partitioned
Note: Partitioning is when you carve out certain access ports to be used by certain ICL interfaces
Current limitations:
Must be two single chassis, no clusters
Load balancing is active/standby per satellite, per access port planned
No user configuration sync between hosts
Configuration Differences:
The most notable changes when coming from a simple hub-and-spoke design is ICCP, and adding the satellite serial number.
Example
Router 1
redundancy
iccp
group 1
member
neighbor 172.18.0.2
!
nv satellite
system-mac <mac> (optional)
!
!
!
!
nv
satellite 100
type asr9000v
ipv4 address 10.0.0.100
redundancy
host-priority <priority> {optional)
!
serial-number <satellite serial>
!
vrf nv_mgmt
!
interface loopback 10
vrf nv_mgmt
ipv4 address 10.0.0.1
!
interface Loopback1000
ipv4 address 172.18.0.1 255.255.255.255
!
interface GigabitEthernet0/1/0/4
ipv4 address 192.168.0.1 255.255.255.0
!
interface ten 0/0/0/0
ipv4 point-to-point
ipv4 unnumbered loopback 10
nv
satellite-fabric-link [network satellite <> | satellite <>]
redundancy
iccp-group 1
remote-ports gig 0/0/0-43
!
!
!
mpls ldp
router-id 172.18.0.1
discovery targeted-hello accept
neighbor 172.18.0.2
!
!
!
router static
address-family ipv4 unicast
172.18.0.2/32 192.168.0.2
!
!
Starting in 5.1.1 we have the ability to support more than just simple hub-and-spoke. The ring topology allows for satellite chaining, cascading, and in general a more advanced satellite network.
Requirements and Limitations:
Configuration:
This is essentially the same as the dual hosts setup, but the network option must be used when entering 'satellite-fabirc-link'
This is treated as special ring and works the same way as simple ring.
The biggest difference is that in 5.1.1 cascading supports single host while simple ring does not.
Starting in 5.1.1 we have the ability to extend the ICL across an EVC. Normally an IRL is a L1 connection. This increases the flexibility of satellite by allowing for greater distances between the ASR9K host and the satellite device.
Requirements and limitations:
Configuration:
On Active-Host:
interface TenGigE0/1/0/23.200
encapsulation dot1q 200
!
nv
satellite-fabric-link satellite 200
redundancy
iccp-group 1
!
remote-ports GigabitEthernet 0/0/0-43
!
On Standby-Host:
interface TenGigE0/1/1/0.200
encapsulation dot1q 220
!
nv
satellite-fabric-link satellite 200
redundancy
iccp-group 1
!
remote-ports GigabitEthernet 0/0/0-43
!
Note: L2 cloud configuration not shown
'show nv satellite status'
Checking Version: The version of the software running on the satellite is being checked for compatibility with the running version of IOS-XR on the host
Configured Serial Number: (If configured) the serial number configured for the satellite, checked against that presented by the satellite during control protocol authentication
Configured Satellite Links: One entry for each of the configured satellite-fabric-links, headed by the interface name. The following information is present for each configured link:
Discovered Satellite Fabric Links: This section is only present for redundant satellite-fabric-links. This lists the interfaces that are members of the configured link, and the per-link discovery state.
Conflict: If the configured link is not conflicted, the satellite discovered over the link is presenting data that contradicts that found over a different satellite-fabric-link.
'show nv satellite protocol discovery'
Host IPv4 Address: The IPv4 address used for the host to communicate to this satellite. Should match the IPv4 address on all the satellite-fabric-links
For Bundle-Ether satellite-fabric-links, there are then 0 or more 'Discovered links' entries; for physical satellite-fabric-links, the same fields are present but just inline.
'show nv satellite protocol control'
Authenticating: The TCP session has been established, and the control protocol is checking the authentication information provided by the Satellite
Connected: The SDACP control protocol session to the satellite has been successfully brought up, and the feature channels can now be opened.
For each channel, the following fields are present:
Open(In Resync - Awaiting Client Resync End) The Feature Channel Owner (FCO) on the host has not finished sending data to the FCO on the Satellite. If this is the state then typically the triage should continue on the host by the owner. The owner of the Feature Channel should be contacted.
Open(In Resync - Awaiting Satellite Resync End) The FCO on the Host is awaiting information from the FCO on the Satellite. If this is the state then typically the triage should continue on the satellite.
Notes:
icpe_gco[1148]: %PKT_INFRA-ICPE_GCO-6-TRANSFER_DONE : Image transfer completed on Satellite 101
A few issues can cause this:
Conflict Messages
Examples:
BNG access over satellite is only qualified over bundle access and isn’t supported over bundle ICLs.
BNG access over ASR9k host and NCS5k satellite specifically is in the process of official qualification in 6.1.x. Please check with PM for exact qualified release.
Access bundles across satellites in an nV dual head solution are generally not recommended. The emphasis is not to bundle services across satellites in a dual head system as if they align to different hosts, the solution breaks without an explicit redundant path. An MCLAG over satellite access is a better solution there.
Bundle access over bundle fabric / ICL require 5.3.2 and above on ASR9k. For NCS5k satellite, bundle ICL including bundle over bundle is supported from 6.0.1 and nV dual head topologies are planned to be supported only from 6.1.1
MC-LAG over satellite access might be more convergence friendly and feature rich than nV dual head for BNG access from previous case studies. For non BNG access, nV dual head and MC-LAG are both possible options with any combinations of physical or bundle access and fabric.
In an MC-LAG with satellite access, the topology is just a regular MC-LAG system with the hosts syncing over ICCP but with satellite access as well. Note that the individual satellites aren’t dual homed/hosted here so there is no dual-host feature to sync over ICCP beyond just MC-LAG from CE.
As a deployment recommendation, unless ICL links (between satellite and host) are more prone to failure over access, MC-LAG might be preferable over nV dual head solution. However, if ICL links have higher failure probability and the links going down can affect BW in bundle ICL cases, then MC-LAG may not switch over unless the whole link goes down or access goes down.
Xander Thuijs CCIE#6775
Principal Engineer, ASR9000
Sam Milstead
Customer Support Engineer, IOS XR
Hi Mark,
9000v supports ring topology and satellite getting connected to another satellite is part of that.
Example from configuration Guide:
interface GigabitEthernet0/1/0/0
ipv4 point-to-point
ipv4 unnumbered Loopback10
nv
satellite-fabric-link network
redundancy
iccp-group 2
!
satellite 500
remote-ports GigabitEthernet 0/0/0-9
!
satellite 600
remote-ports GigabitEthernet 0/0/0-9
There are 2 changes that need to be modified in your interface configuration because of the limitations of the Simple Ring Topology.
1. Simple Ring Topology does not support Bundle config over satellite fabric links (ICL), so yours can only on a physical interface on Host
2. Satellite to Satellite connection can happen only through fabric links (ICL) and not on access links
Request to refer the configuration guide heading "Simple Ring Satellite nV Topology"
Thanks
Ramesh A
I have looked at the Simple Ring Satellite nV Topology stuff for release 5.3.3 which is what we are currently running in our network. I can see how to add the first satellite but not how to specify and interface on that Satellite to connect to the next satellite in the cascade. I could be reading it wrong as I am not very familiar with XR at all.
The topology we want to run is:
ASR9010 ---> Satellite 200 ----> Satellite 201
so long as each satellite is running a high enough version of code (they should be if they are new) they will do this automatically. A probe will be sent out any ICL links on the first satellite trying to discover another satellite, and so on and so forth until the entire ring is discovered.
Sam
HI Travis,
As Sam has mentioned the detection of satellite to satellite happens automatically as long as they are connected using default ICL ports. Explicit mention of the interface is not required.
Thanks
RameshA
Xander,
With nV support being removed in 6.0.1 for the 901 & 920 can you share an information on how to convert these devices back to layer 2 and remove the nV license?
Thanks
Tony
Hey Xander,
I have a question regarding MPLS over NV satellite.From what we've found MPLS should be supported over an NV satellite. However, we're seeing failover problems. Do you know if there are any limitations that we should be aware of?
We have a simple ring set with two ASr9000v homed to two ASR9010 hosts. L2/L3 interfaces seems to work great for failover. however we have noticed that if we have a PE router hanging off a satellite port with MPLS enabled we have to manually flap the port to restore l2vpn and l3vpn services.
On the connected PE router we'll see in the xconnect an error to next hop:
Last error: MPLS dataplane reported a fault to the nexthop
Any suggestions or recommendations would be appreciated.
Thanks,
Jon
hi jon,
I would expect this to work, but the problem can be as much on the PE that is connected to the satellite or on the satellite host.
what I think may be happening is that the PE off the satellite is having a label but after a ring failover, the other 9k host serving the ring is not in the know about the label and therefore chokes on this.
so few things to look at are:
- if the PE is directly connected to the 9k host is there a problem when there is a convergence (this is plain vanilla and should work under any condition).
- if the PE is connecting to the satellite, and has proper forwarding is the next hop label changing or retained on 9k host failover?
considering that the manual flap of the interface on the PE resolves the issue I am suspecting that the next hop label change is not done correctly on the PE OR that the 9khost is not advertising it properly.
the investigation would need to focus on that.
I will check around to see if there are known issues or known solutions for this also.
it may be good to have a tac case for this also to help with the investigation in case we are running into a sw limitation (=bug) that might need to be addressed. one and other depending on your current version of course.
cheers
xander
Hey Xander,
Thanks for the quick reply. hope things are going well!
The ASr9k host does not have any issues with directly connected PE routers (there are quite a few connected direct to 10G linecard ports).
The PE through the satellite does appear to have a label mismatch however we were unable to collect all the needed to pin point problem during the maintenance due to customer traffic being impacted. We have seen this behavior on ASR1k and ASR901 PE routers so far. For next step we'll set this up in a lab and open a TAC case to investigate.
Another detail we have seen this failover problem on hosts running 5.1.3 and 5.3.4. The ASr9000v satellites off 5.3.4 hosts weren't upgraded yet so not sure if that could be a factor (IOS: 532.101).
Thanks again,
Jon
hi jon,
i dont think the sat version is a factor on this one, since it sounds like (but confirm that with tac) that the label swap is not going nicely/smoothly. if that is the case we may be hitting a known limitation of the ring topology that Aleks whom I have been discussing this with was feeling to. If it is something else like a mac update or so, then there may be options.
confirming with our dev and test too to see what the original design was meant to carry this scenario.
cheers
xander
was discussing this with our satellite dev team earlier and this may work, but it wont be stateful. since the PE device will maintain igp peerings with host1 and separately with host 2 on failover.
what may be the case is that your manual shut forces a igp peer down and re-establishment could that be the case?
any case, the PE will need to tear down and reestablish its adj for this to work.
having said that the satellite's purpose was merely as an edge device (for CE connectivity as a PE) and in this model you're sort of using it as a P device...
xander
Thanks for the feedback. That aligns with our expectations for using a port on the satellite for MPLS. It's understandable the IGP and labels would not be stateful and need to re-establish on failover. This would be fine if we just didn't have to flap the port to fix. When it goes into this mismatch state PWE traffic ends up be black holed which is worse than this path just being down hard.
We're mocking this up in our lab and will open a TAC case to gather more details.
Thanks,
Jon
I am trying to put a 100Mbps shaper on a 9000nV satellite sub-interface to account for the speed step from 10Gbps to 1Gbps down to 100Mbps. The QoS configuration seems to apply fine and I'm trying to confirm that the QoS was actually applied by using the "show qos interface <int>" command. However, when I run this command, the results I get back seem to indicate that the QoS policy wasn't actually applied to the interface. Is there another way to confirm the QoS policies as applied to an 802.1Q sub-interface on an 9000nV satellite shelf?
interface GigabitEthernet100/0/0/18.282
bandwidth 100000
service-policy output prioritize_sub1ge_sites
ipv4 address <Removed>
encapsulation dot1q 282
!
!
policy-map prioritize_sub1ge_sites
class packets_with_ip_precedence_5
priority level 1
set cos 5
set dei 0
!
class packets_with_ip_precedence_6
priority level 1
set cos 6
set dei 0
!
class class-default
shape average 100 percent
!
end-policy-map
!
RP/0/RSP0/CPU0:<REMOVED>#show qos interface Gi100/0/0/18.282 output location 0/7/CPU0
Thu Nov 10 10:04:29.865 PDT
Interface: GigabitEthernet100_0_0_18.282 output
Bandwidth configured: 10000000 kbps Bandwidth programed: 0 kbps
ANCP user configured: 0 kbps ANCP programed in HW: 0 kbps
Port Shaper programed in HW: 0 kbps
Policy: prioritize_sub1ge_sites Total number of classes: 0
----------------------------------------------------------------------
RP/0/RSP0/CPU0:<REMOVED>#show nv satellite status
Thu Nov 10 10:13:34.597 PDT
Satellite 100
-------------
Status: Connected (Stable)
Type: asr9000v
Displayed device name: Sat100
IPv4 address: 10.0.0.2 (VRF: 9000nv_mgmt)
Serial Number: CAT1840U2EE
Remote version: Compatible (latest version)
ROMMON: 127.0 (Latest)
FPGA: 1.13 (Latest)
IOS: 533.100 (Latest)
Configured satellite fabric links:
Bundle-Ether100
---------------
Status: Satellite Ready
Remote ports: GigabitEthernet0/0/0-43
Discovered satellite fabric links:
TenGigE0/7/0/0: Satellite Ready; No conflict
TenGigE0/7/0/1: Satellite Ready; No conflict
Hi Sam,
Below is limit for 5.1.1 for simple-ring; is there improvement in 5.3.3 for these 4 items.
Thanks,
Mei
Hi,
does ASR9000v support using DWDM SFP+ as the uplink? so we can connect it directly as alien wavelength?
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:
With nV support being removed in 6.0.1 for the 901 & 920 can you share any
information on how to convert these devices back to layer 2 and remove the nV license?
Thanks
Tony