Ok, final post on IOS-XR before the workbook is published in its entirety.
 
So you want to secure your IOS-XR device using TACACS.
The first example I will use will be using the default VRF for TACACS authorization and the second will be using a different VRF. For these examples, the tacacs server is at IP 192.168.100.100 and the password is TacacsPassword
First up, we need to configure our source interface for TACACS, here we will use loopback0 and the default VRF.
RP/0/RSP0/CPU0:PE2(config)#tacacs source-interface Loopback0 vrf default
Now we can configure our TACACS server and Password
RP/0/RSP0/CPU0:PE2(config)#tacacs-server host 192.168.100.100
RP/0/RSP0/CPU0:PE2(config-tacacs-host)#key 0 TacacsPassword
RP/0/RSP0/CPU0:PE2(config-tacacs-host)#exit
RP/0/RSP0/CPU0:PE2(config)#
Time to create a local console authenticaion method, this way console does not rely on TACACS.
You may or may not want to do this, but I am showing it for these examples.
RP/0/RSP0/CPU0:PE2(config)#aaa authentication login console local
RP/0/RSP0/CPU0:PE2(config)#aaa authorization commands console none
Apply the console loging to the line console
RP/0/RSP0/CPU0:PE2(config)#line console
RP/0/RSP0/CPU0:PE2(config-line)#login authentication console
RP/0/RSP0/CPU0:PE2(config-line)#authorization commands console
RP/0/RSP0/CPU0:PE2(config-line)#exit
RP/0/RSP0/CPU0:PE2(config)#

One last IOS XR post and then it will be time to post the IOS XR workbook.
Ok, let’s quickly look at loading a configuration from the disk and overwriting an existing configuration.
I have copied a config to disk0a: called newconfig.txt.  What I want to do is install this configuration as the running config on the router.
1626        -rwx  204         Wed Oct 17 01:21:30 2012  newconfig.txt
So to start, lets delete the existing configuration
RP/0/RSP0/CPU0:R1(config)#commit replace
Wed Oct 17 01:21:43.406 UTC
This commit will replace or remove the entire running configuration. This
operation can be service affecting.
Do you wish to proceed? [no]: y
RP/0/RSP0/CPU0:ios(config)#
RP/0/RSP0/CPU0:ios(config)#exit
Ok, so now we are at an unconfigured device.  Now we can load the config on the disk to the running config.
RP/0/RSP0/CPU0:ios(config)#load disk0a:/newconfig.txt
Loading.
204 bytes parsed in 1 sec (203)bytes/sec

Next Hop Resolution Protocol comes in two fashions on the IOS XR.  The first is Cisco proprietary and called Hot-Standby Router Protocol or HSRP and the other is the industry standard called Virtual Router Redundancy Protocol or VRRP.
This is something that many customers use in order to maintain the availability of a default gateway on the network.  If your customer uses a static route to a next hop, you might be using this as well.
Like everything else with IOS XR, NHRP is handled a little differently.  With IOS, you configure your standby commands under the interfaces; in IOS XR you use ROUTER HSRP or Router VRRP.
For this lab we will use interface Te0/1/0/0 and a subnet of 150.1.12.0/24.
First up R1:
RP/0/RSP0/CPU0:R1(config)#int tenGigE 0/1/0/0         
RP/0/RSP0/CPU0:R1(config-if)#ip add 150.1.12.1/24
RP/0/RSP0/CPU0:R1(config-if)#no shut
RP/0/RSP0/CPU0:R1(config-if)#commit
RP/0/RSP0/CPU0:R1(config-if)#
Now R2:
RP/0/RSP0/CPU0:R2(config)#int tenGigE 0/1/0/0
RP/0/RSP0/CPU0:R2(config-if)#ip add 150.1.12.2/24
RP/0/RSP0/CPU0:R2(config-if)#no shut
RP/0/RSP0/CPU0:R2(config-if)#commit

 Ok, now it is time for some L2VPN.  Here we will use the same diagram as before, but instead of providing MPLS VPN between CE1 and CE2, we are going to create a L2VPN so that CE1 and CE2 think that they are directly connected to each other. This lab builds off the previous post, so the routers where already configured.

First up, CE1
CE1(config-if)#int f0/0
CE1(config-if)#ip add 10.1.34.3 255.255.255.0
CE1(config-if)#int l0
CE1(config-if)#ip add 10.1.3.3 255.255.255.255
CE1(config-if)#router ospf 1
CE1(config-router)#net 10.0.0.0 0.255.255.255 a 0
CE1(config-router)#
Now CE2
CE2(config-if)#ip add 10.1.34.4 255.255.255.0
CE2(config-if)#int l0
CE2(config-if)#ip add 10.4.4.4 255.255.255.255
CE2(config-if)#router ospf 1
CE2(config-router)#net 10.0.0.0 0.255.255.255 a 0
CE2(config-router)#

You may have noticed on my twitter feed that I have been interacting with some Junos pros over the past few months, they have been helping me with a small guide that I am working on.  Below is information on that guide:
 
I am currently working on a “workbook” I have subtitled “A Junos Guide by an IOS Guy” and I am intending to publish it throughout October and November as individual posts.  Once all the individual posts are published, the guide will be available in PDF format as a single download.  This is the same process I am doing with IOS XR  – all the IOS XR posts will be available as a single PDF download – just like I did for the Nexus 7000
It is my intention for this “workbook” to help those of us who know Cisco IOS to learn and understand Juniper Junos.  I will admit that I was initially intimidated by the look of the Junos configuration, but as time has gone on I have learned to understand it and actually like it.  As they say, the more you work with something, the more comfortable you feel with it.

Next up is MPLS VPN; actually VPNv4 routes are what these actually are since we are only passing IPv4 traffic in this example.
So we have this diagram below – CE1 and CE2 are the customer routers and both are running OSPF in Area 0.  They need to talk to each other but do not have a direct connection available, so they have contracted us to provide connectivity via MPLS between them.  What we will now do is build a pseudo MPLS network between PE1 and PE2, establish an iBGP peering, create the associated customer VRF and then peer with the customer via OSPF Area 0.

So, first up lets configure CE1 using an IP of 10.3.3.3/32 for the loopback and 10.1.13.3/24 for the link facing PE1.
CE1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

Ok, time for some MPLS!  For this lab I will be using the OSPF routing protocol first, then we can move to IS-IS next.  All we will be doing here is configuring LDP
First up, lets enabled LDP on all OSPF interfaces.  Normally you would do this under each interface, but here we will use the MPLS LDP AUTOCONFIG command.  This is a good command to use as it ensures that you do not miss configuring LDP on an interface.
RP/0/7/CPU0:R1#conf t
Sun Apr  1 18:58:04.084 UTC
RP/0/7/CPU0:R1(config)#router ospf LAB
Under the OSPF LAB process, we need to configure mpls ldp autoconfig and then commit it.
RP/0/7/CPU0:R1(config-ospf)#mpls ldp auto
RP/0/7/CPU0:R1(config-ospf)#commit
Sun Apr  1 18:58:12.277 UTC
RP/0/7/CPU0:R1(config-ospf)#exit
RP/0/7/CPU0:R1(config)#exit
Ok, now lets see what interfaces have LDP on them
RP/0/7/CPU0:R1#sh mpls ldp int
Sun Apr  1 18:58:18.902 UTC
MPLS LDP application must be enabled to use this command

Ok, time for some VRF lite basics and we can throw in some Dot1Q trunks to go with it.
First, let’s create our VRF called LAB
RP/0/7/CPU0:R1(config)#vrf LAB
Now we need to enable the address family for this VRF, there IPv4 Unicast
RP/0/7/CPU0:R1(config-vrf)#address-family ipv4 un
RP/0/7/CPU0:R1(config-vrf-af)#exit
Now we need to enable the IPv6 address family for this VRF
RP/0/7/CPU0:R1(config-vrf)#address-family ipv6 unicast
Now we can create our Dot1Q trunk to the other router:
RP/0/7/CPU0:R1(config-vrf-af)#int g0/3/0/3.100
Little different then IOS, but this actually makes more sense
RP/0/7/CPU0:R1(config-subif)#dot1q vlan 100
RP/0/7/CPU0:R1(config-subif)#ip add 150.1.21.1/24
RP/0/7/CPU0:R1(config-subif)#ipv6 add 2001:1:1:21::1/64
RP/0/7/CPU0:R1(config-subif)#vrf LAB

 
 
Ok, now that BGP has been covered, lets talk about filtering routes received from our neighbor.  Here I have created some additional Loopbacks on R2 that are being advertised to R1:
RP/0/7/CPU0:R1#sh ip route bgp
Fri Mar 30 13:13:36.797 UTC
B    200.100.200.100/32 [20/0] via 2.2.2.2, 00:00:42
B    200.200.200.200/32 [20/0] via 2.2.2.2, 13:45:00
B    200.200.200.203/32 [20/0] via 2.2.2.2, 00:00:42
B    200.200.200.204/32 [20/0] via 2.2.2.2, 00:00:42
B    200.200.200.205/32 [20/0] via 2.2.2.2, 00:00:42
B    200.200.200.206/32 [20/0] via 2.2.2.2, 00:00:42
B    200.200.200.207/32 [20/0] via 2.2.2.2, 00:00:42
B    200.200.200.208/32 [20/0] via 2.2.2.2, 00:00:42
B    200.200.200.209/32 [20/0] via 2.2.2.2, 00:00:42
B    200.200.200.210/32 [20/0] via 2.2.2.2, 00:00:42
RP/0/7/CPU0:R1#
As you can see, we are getting a bunch of 200.200.200.x/32 routes now as well as a 200.100.200.100/32 route.  For this exercise, lets filter our all the 200.200.200.x routes we are receiving from our neighbor.
Ok, lets create a prefix-set for the loopback we want to permit:
RP/0/7/CPU0:R1(config)#conf t
RP/0/7/CPU0:R1(config)#prefix-set R2Loopbacks

BGP, this is where it starts to get different with IOS XR.
First up, configuring an iBGP peering with R2’s 150.1.12.2 in AS1 and advertise our loopback interface.
RP/0/7/CPU0:R1(config)#
RP/0/7/CPU0:R1(config)#router bgp 1
Let’s define the network we want to advertise, under the address family:
RP/0/7/CPU0:R1(config-bgp)#address-family ipv4 unicast
RP/0/7/CPU0:R1(config-bgp-af)#net 1.1.1.1/32
RP/0/7/CPU0:R1(config-bgp-af)#exit
Now, we can configure the neighbor.  Notice all the commands for the neighbor are under the neighbor now – not next to the neighbor.
RP/0/7/CPU0:R1(config-bgp)#nei 150.1.12.2
RP/0/7/CPU0:R1(config-bgp-nbr)#remote-as 1
RP/0/7/CPU0:R1(config-bgp-nbr)#address-family ipv4 unicast
RP/0/7/CPU0:R1(config-bgp-nbr-af)#exit
RP/0/7/CPU0:R1(config-bgp-nbr)#comm
Thu Mar 29 22:47:05.147 UTC
RP/0/7/CPU0:R1(config-bgp)#exit
RP/0/7/CPU0:R1(config)#exit
Now, time to see if we have a neighbor established:
RP/0/7/CPU0:R1#sh bgp nei 150.1.12.2
Thu Mar 29 22:48:13.338 UTC