Following previous part 1 article of this IOS XR guide that presented basic examples for IOS XR on most CCNA level technologies, this post will continue and give the basics of FHRP, MPLS, BGP and some minor features like route redistribution to finalize this two article series. Again the aim is not to explain in detail the protocols or theory behind them, only to provide quickly searchable reference guide to quickly configure these protocols on IOS XR. This is the second and final part of this “Getting Started Example Guide”, next for IOS XR I will continue in a separate articles that will go to specific advanced topics independently.
Content of this article: 1. First Hop Redundancy Protocols on IOS XR - Hot Standby Router Protocol (HSRP) - Virtual Router Redundancy Protocol (VRRP) - Gateway Load-Balancing Protocol (GLBP) 2. Redistribution on IOS XR - Redistribution into IS-IS - Redistribution into OSPF 3. Basic MPLS configuration on IOS XR 4. Basic BGP configuration on IOS XR
First Hop Redundancy Protocols
Lets start with the most simple part. First Hop Redundancy Protocols are protocols that allows you to make your default gateway IPv4 virtual and redundant on two separate routers. In cisco routers, we have three of these protocols and for each a quick example is visible below. But before that lets quickly go via the IPv4 and IPv6 support on different platform.
FHRP Protocol Cisco IOS/IOS XE Software Cisco IOS XR Software HSRP IPv4, IPv6 (with version 2) IPv4 VRRP IPv4 IPv4, IPv6 GLBP IPv4, IPv6 Not supported
Hot Standby Router Protocol (HSRP)
HSRP is a cisco proprietary protocol for gateway IP redundancy. In the following picture, you have very simple topology with both IOS XR and IOS routers and their configuration.
Explanation is quite simple, HSRP routers broadcast their virtual-IP, priority and HSRP group ID on multicast IP 126.96.36.199 in UDP packets port 1985. With this broadcast, they locate each other and the router with highest priority wins and starts to actively serve the packets leaving vie default gateway. HSRP has hello interval of 3 seconds and hold down timer of 10 seconds.
The configuration is as follows on IOS:
interface Ethernet 0/0 ip address 192.168.101.10 255.255.255.0 standby 1 ip 192.168.101.1 standby 1 priority 105 standby 1 preempt standby 1 track Ethernet 0/1
Configuring HSRP you have to start with a unique ID called HSRP group that is a value “standby <ID>” from 1 to 255 and has to be unique in a broadcast domain of the given interface. If you want to have multiple groups on an interface you can make the commands unique based on this HSRP group. Second value is priority that is also a value from 1 to 255. By default the priority is 100 and higher value wins.
Preemption is by default disabled, this means that by default if your master fails, the backup router becomes a master. However when the master recovers, he will not assume the role of the new master until the current master fails despite the priority value. If you want the highest priority router to become master in any situation, you have to activate the preemption with the standby <ID> preempt command.
Last part is the ability to track another interface and/or tracking object. This is used for gateway routers in a situation when an outgoing uplink interface like Ethernet 0/1 fails on the current active master. In this situation the master is no longer the best router to be the gateway as he has no uplink. Therefore using tracking the current master can decrease its priority dynamically and allow another router to be the new master.
On IOS XR, it is a little bit different in a sense that the configuration commands have moved to a common “router hsrp” section in the configuration. But as you see, there is nothing new to explain compared to IOS configuration.
The configuration of HSRP on IOS XR is as follows:
interface GigabitEthernet 0/0/0/0 ip address 192.168.101.10 255.255.255.0 router hsrp interface GigabitEthernet 0/0/0/0 hsrp 1 ipv4 192.168.101.1 hsrp 1 priority 95 hsrp 1 preempt hsrp 1 track GigabitEthernet 0/0/0/1
Verification on IOS:
Router# show standby brief P indicates configured to preempt. | Interface Grp Pri P State Active Standby Virtual IP Gi0/0/1 1 105 P Active local 192.0.2.3 192.0.2.1
Verification on IOS XR
RP/0/RSP0/CPU0:Router# show hsrp Wed Aug 17 13:51:31.032 UTC P indicates configured to preempt. | Interface Grp Pri P State Active addr Standby addr Group addr Gi0/0/0/1 1 95 P Standby 192.0.2.2 local 192.0.2.1
Virtual Router Redundancy Protocol (VRRP)
The RFC standard protocol for default gateway redundancy. Again the initial example of VRRP deployment with both IOS and IOS XR routers. It is using multicast address of 188.8.131.52 when running in IPv4.
Explanation is again quite simple, VRRP routers broadcast their virtual-IP, priority and VRRP group ID on multicast IP 184.108.40.206. With this broadcast, they locate each other and the router with highest priority wins and starts to actively serve the packets leaving vie default gateway. VRRP has 1second advertisement timer and hold down timer below 4seconds.
The configuration is again very simple for both IOS and IOS XR as shown below.
Configuration of VRRP on IOS:
interface Ethernet 0/0 ip address 192.168.101.1 255.255.255.0 vrrp 1 ip 192.168.101.1 vrrp 1 track interface Ethernet 0/1
The configuration concept of VRRP is again very similar to the HSRP. You need to configure VRRP group ID in a range from 1 to 255 that is unique in the L3 broadcast domain. There is also priority to configure in range from 1 to 254 that is by default 100, but if the physical IP is the same on an interface as the Virtual IP, the router automatically assumes the role of permanent VRRP master with 255 priority (255 is reserved for this situation when you configure HSRP virtual IP the same as physical interface IP). This permanent VRRP master is called VRRP owner.
VRRP is by default in preemption mode but you can disable it with using “no vrrp 1 preempt” if needed. Interface and object tracking is supported in the same way as on HSRP.
Configuration of VRRP on IOS XR:
interface GigabitEthernet 0/0/0/0 ip address 192.168.101.10 255.255.255.0 router vrrp interface GigabitEthernet 0/0/0/0 address-family ipv4 vrrp 1 address 192.168.101.1 priority 95 track interface GigabitEthernet 0/0/0/0 10
On IOS XR, the configuration is moved to the router vrrp section and also for the support of IPv4 and IPv6 divided under the address-family sections.
On IOS, VRRP verification can be done with show vrrp brief:
Router# show vrrp brief Interface Grp Pri Time Own Pre State Master addr Group addr Ethernet0/0 1 95 3223 Y Backup 192.168.101.11 192.168.101.1
On IOS XR, VRRP verification can be done with show vrrp:
RP/0/RSP0/CPU0:Router# show vrrp Thu Aug 29 02:33:00.888 UTC IPv4 Virtual Routers: A indicates IP address owner | P indicates configured to preempt | | Interface vrID Prio A P State Master addr VRouter addr Gi0/0/0/0 1 105 P Master local 192.168.101.1
Gateway Load Balancing Protocol (GLBP)
This cisco proprietary protocol is actually my favorite protocol of all FHRP protocols simply because it does load-balancing for all the physical routers that make the GLBP group while all the hosts still think they use a single IP gateway. The trick is that there is still an active GLBP router selected based on priority, but there are not virtual MAC addresses and only the active GLBP router replies to ARP requests on the virtual IP with mac addresses of all the GLBP group members in round-robin fashion (although it is possible to configure each router with weight and with it statistically put more ARP responses to different routers in a group).
GLBP protocol use 220.127.116.11 as a multicast IP in IPv4 network and GLBP is using group ID as the other protocols but with range from 1 to 1023. Priority by default 100, with range 1 to 255. Hello timer 3, hold down timer 10 seconds. Preemption is not enabled by default.
However, GLBP is not supported on IOS XR, so the following example is for IOS routers only.
The configuration example of GLBP on IOS is as follows (router R1 perspective):
interface FastEthernet0/0 ip address 192.168.101.11 255.255.255.0 glbp 1 ip 192.168.101.1 glbp 1 priority 95 glbp 1 preempt
IPv6 example bonus:, if you like, here is a quick modification for IPv6 auto-configured version of GLBP on IOS:
interface fa0/0 ipv6 address 2002:8:101:1::/64 eui-64 glbp 1 ipv6 autoconfig glbp 1 preempt
For a single GLBP configured Virtual IP, you can see multiple lines of output in the show glbp brief. This shows you not only the VirtualIP, but also all the members of the group doing the forwarding.
R1#show glbp brief Interface Grp Fwd Pri State Address Active router Standby route Fa0/0 1 - 100 Standby 192.168.101.1 192.168.101.11 local Fa0/0 1 1 7 Listen 0007.b400.0101 192.168.101.11 - Fa0/0 1 2 7 Active 0007.b400.0102 local -
Often you encounter a network that for various (mostly historical) reasons have more than one routing protocol implemented, it is often needed to allow a single route to exist in both protocols. To achieve this, the solution is to redistribute a route from the protocols it was sourced in to the other protocols. Very importantly you have to take care of the differences of the two protocols to not create more problems (mostly loops) than benefit from redistribution.
Redistribution into IS-IS
First protocol we will mention is IS-IS (as my favorite). I will show you a very basic example how to configure redistribution. For those who know IOS redistribution, this will be well known only on IOS XR, the command has a bit different placement.
The redistribution command is inside the address-family ipv4 unicast and in our example, we give redistributed routes metric 20. However, by default the seed metric for redistributing to IS-IS in Cisco routers (IOS + IOS XR) is 0.
router isis 1 net 49.0000.0100.0200.0300.00 address-family ipv4 unicast redistribute ospf 1 metric 20 interface GigabitEthernet0/0/0/0 address-family ipv4 unicast ! router ospf 1 area 0 interface GigabitEthernet0/0/0/1
For reference, this is how the redistribution would look like on IOS:
router isis 1 redistribute ospf 1 metric 20
For quick verification, you can simply check the routing table as shown below, please not that IS-IS redistributed routes are not marked in any special way:
RP/0/RSP0/CPU0:IOSXR# show route Wed Jan 05 11:12:24.092 UTC Codes: C - connected, S - static, R - RIP, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, su - IS-IS summary null, * - candidate default U - per-user static route, o - ODR, L - local, G - DAGR A - access/subscriber, (!) - FRR Backup path Gateway of last resort is not set i L2 10.1.10.0/24 [115/20] via 192.168.101.11, 00:00:35, GigabitEthernet0/0/0/1 i L2 10.1.1.0/24 [115/30] via 192.168.102.10, 00:21:46, GigabitEthernet0/0/0/0
Redistribution into OSPF
When redistributing into OSPF, by default the metric is type E2*, default seed metric from IGP is 20 and from BGP is 1. Also IOS and IOS XE router by default redistribute only classfull networks (you have to use “subnets” keyword).
*E1 vs E2 types. E2 metric when given to external route will not be incremented when propagated in internal network after being given initial seed metric. E1 on the other hand is incremented in addition to the initial seed metric as any other OSPF route on every hop.
The configuration is not that different in comparison to older IOS redistribution, in the following example we will redistribute IS-IS to OSPF.
Cisco IOS and IOS XE (for reference):
router ospf 1 redistribute isis 1 subnets metric 30
Note that this command will redistribute routes (also classless subnets thanks to the “subnets” word) with default E2 (non-incrementing one) metric 30.
Cisco IOS XR:
router isis 1 net 49.0000.0100.0300.1001.00 interface GigabitEthernet0/0/0/0 address-family ipv4 unicast ! router ospf 1 redistribute isis 1 metric 30 area 0 interface GigabitEthernet0/0/0/1
Note that you do not have to use the “subnets” keyword on IOS XR to redistribute also classless networks.
Also on the verification front, the routing table looks very familiar on IOS XR:
RP/0/RSP0/CPU0:IOSXR# show route Wed Jan 6 13:02:20.923 UTC Codes: C - connected, S - static, R - RIP, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, su - IS-IS summary null, * - candidate default U - per-user static route, o - ODR, L - local, G - DAGR A - access/subscriber, (!) - FRR Backup path Gateway of last resort is not set O E2 10.1.10.0/24 [110/30] via 192.168.101.11, 00:00:19, GigabitEthernet0/0/0/0 O 10.1.1.0/24 [110/20] via 192.168.102.10, 00:15:06, GigabitEthernet0/0/0/1
Multiprotocol Label Switching (MPLS)
Now this one is a kicker. Actually this technology is like an elephant in a room that nobody mentions, but all know it is there. MPLS has become the major player in all bigger ISP networks with its marvelous benefits that it gives. I personally like to say that the benefits of MPLS are not in any speed or other things, but it did to networks the same that Virtualization did to computers. Also it had returned the long missed (since ATM times) Traffic Engineering back to the IP networks.
In this quick overview, I will not mention anything from MPLS theory, if there is someone reading this without any prior knowledge about MPLS, then I would ask him to stop on this point and go read some theory basics of MPLS before continuing here.
Let’s first give you my lab topology to have you orient in it.
On older IOS and IOS XE platforms, you simply enable MPLS globally with “mpls ip” in global configuration and then enable all the interfaces that you want to participate in the MPLS cloud with “mpls ip” under the configuration context of each interface. This will start for you the basic MPLS (take not that on very old IOS routers, this might activate older MPLS label distribution protocol called TDP).
mpls ip ! interface GigabitEthernet0/0 mpls ip
On newer IOS XR, it is a bit other way around when you put the interface under mpls ldp configuration context.
mpls ldp interface GigabitEthernet0/0/0/0 ! interface GigabitEthernet0/0/0/1
Well, once you activate MPLS and LDP protocol on two routers on their interconnecting interface, you should get LDP neighbourship comming up (you get SYSLOG message about this to the console). To verify your neighbours on IOS XR, you can execute show mpls ldp neighbor.
RP/0/RSP0/CPU0:IOSXR# show mpls ldp neighbor Peer LDP Identifier: 18.104.22.168:0 TCP connection: 22.214.171.124:23307 - 126.96.36.199:646 Graceful Restart: No Session Holdtime: 180 sec State: Oper; Msgs sent/rcvd: 27/26; Downstream-Unsolicited Up time: 00:06:28 LDP Discovery Sources: GigabitEthernet0/0/0/1 Addresses bound to this peer: 10.1.1.1 188.8.131.52
Secondly, you see if the other neighbors are sending you MPLS tag bindings. These are numerical labels used for forwarding and there is always your (as of from the perspective of every router) internal label generated for a particular prefix and also all your neighbor will send you their label for the same prefix. Of course you will send them your local prefix as well.
For example on the following example we see an internal label 21 for a prefix 10.1.1.0/24 and also the label 24 that your neighbor has assigned to the same prefix.
RP/0/RSP0/CPU0:IOSXR# show mpls ldp bindings <…output omitted…> 10.1.1.0/24, rev 24 Local binding: label: 23 Remote bindings: (2 peers) Peer Label ----------------- -------- 10.1.1.0:0 24 10.1.11.0:0 25
Note a very similar verification is possible on IOS routers. First the LIB:
IOSRouterR2#show mpls ldp bindings tib entry: 10.1.1.0/24, rev 3 local binding: tag: imp-null remote binding: tsr: 184.108.40.206:0, tag: 23
And also then you can have a look on the LFIB:
IOSRouterR1#show mpls forwarding-table Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 21 23 10.1.1.0/24 0 Ge0/1 220.127.116.11
Basic BGP configuration
Ok, CCNA level of BGP is absolutely minimal, what I will show in the following example is only to start the BGP process, establish and verify neighborship and propagate some local prefix. To be more precise, we will build a simple eBGP and iBGP sessions on both IPv4 and IPv6 used for neighborship, but configure the routers to use IPv4 neighborship to exchange only IPv4 prefixes and to use IPv6 neighborship to carry only IPv6 prefixes (because you can carry both IPv4 and IPv6 on any type of underlining neighborship).
Full topology with all configuration at glance below:
If you know the older IOS configuration of BGP, the IOS XR should be no problem for you. The only difference in basic configurations is that now you create address-families under neighbors and not neighbors under address-families like in IOS.
Now lets go through the configuration, first the IOS part:
router bgp 64512 no bgp default ipv4-unicast neighbor 2001:AC2:5:100:11::2 remote-as 2450 neighbor 18.104.22.168 remote-as 2450 ! address-family ipv4 network 10.1.10.0 mask 255.255.255.0 no neighbor 2001:AC2:5:100:11::2 activate neighbor 22.214.171.124 activate exit-address-family ! address-family ipv6 neighbor 2001:AC2:5:100:11::2 activate exit-address-family
The configuration is simple, you create two peers (the same neighbor router over IPv4 and IPv6) and activate corresponding address-family propagation only for IPv4 to the IPv4 neighbor and IPv6 only to the IPv6 neighbor.
You might notice there is something different here than you are probably used to and that is that I have disabled the default IPv4 prefix propagation in the default bgp context with no bgp default ipv4-unicast. This disables the default IPv4 prefix propagation and forces you to use IPv4 address-family if you want it. This helps to have much more control over BGP. Let me give you example of the exact same configuration (for IPv4 prefixes only) to show you what I mean.
The IOS XR part is more interesting in that the guys in Cisco reversed the order of configuration context. Instead of creating neighbors under address-families like on IOS, on IOS XR you add address-families under neighbor creation. Other than that, I believe there no more explanation needed to the config below. Additionally, notice that the network advertisement stayed the same with the network command but the format changed utilizing the /24 for mask.
router bgp 2450 address-family ipv4 unicast network 10.1.1.0/24 ! address-family ipv6 unicast ! neighbor 126.96.36.199 remote-as 64512 address-family ipv4 unicast ! neighbor 2001:AC2:5:100:11::1 remote-as 64512 address-family ipv6 unicast ! neighbor 10.2.2.2 remote-as 2450 update-source Loopback0 address-family ipv4 unicast ! neighbor 2001:ac5:10:2:2::2 remote-as 2450 update-source Loopback0 address-family ipv6 unicast
OPTIONAL: BGP authentication configuration
Under IOS, we go the usual way like this:
router bgp 64512 neighbor 188.8.131.52 remote-as 2450 neighbor 184.108.40.206 password BGP_password
On IOS XR, as with most thing you have to go under the neighbor context and add the password there:
router bgp 64500 neighbor 220.127.116.11 remote-as 64512 password clear BGP_password address-family ipv4 unicast
To verify that BGP is up and running you can check the BGP table to see the neighbors listed and the number of prefixes they are sending to you in the St/PfxRcd field. You can also notice the AS number for each neighbor.
RP/0/RSP0/CPU0:IOSXRPE1#sh bgp table ipv4 unicast Tue Jan 8 9:09:25.011 UTC Neighbor VRF Spk AS TblVer InQ OutQ St/PfxRcd 18.104.22.168 default 0 64512 12 0 0 1 10.2.2.2 default 0 2450 12 0 0 1
Also this is possible for the other address-families, but in IPv6 we do not yet have any prefixes propagated.
RP/0/RSP0/CPU0:IOSXRPE1#sh bgp table ipv6 unicast Tue Jan 8 9:10:12.149 UTC Neighbor VRF Spk AS TblVer InQ OutQ St/PfxRcd 2001:ac5:5:100:11::1 default 0 64512 12 0 0 0 2001:ac5:10:2:2::2 default 0 2450 12 0 0 0
Ok, I perfectly understand that this overview only scratched the surface of far more advanced topics as BGP and MPLS, but the intention here was not to go deep. More advanced things will come only when I get my hand on some more IOS XR routers (as I plan to start learning to move my CCIP certification to CCNP SP replacement). So I believe there will be some more BGP and MPLS articles coming to networkgeekstuff.com in the near future.