CCIE SP Study Guide
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

View only

access-list 100 permit ip host host
... is equivalent to ...
ip prefix-list 100 permit
ISIS route-leaking / BGP extended ACL syntax in IOS is pretty strange.
router isis 1
address-family ipv6 unicast
single-topology <<<<<<<<<<<<<
Required for ISIS to work in IPv4/IPv6 single-topology mode in XR. IOS defaults to single topology.Since the multi-protocol topology is essentially identical, it allows a single SPF calculation to apply to both protocol stacks at the same time, simplifying the database calculation and protocol overhead of IS-IS. In other words, for single topology IS-IS to work, each interface that runs IPv4 must also run IPv6, and each interface that runs IPv6 must also run IPv4. This is one of the design advantages of IS-IS over OSPF, as OSPFv2 and OSPFv3 are unrelated protocols used to route IPv4 and IPv6 respectively, while IS-IS can route both with a single calculation, arguably resulting in a more efficient design.

Note that by default, IS-IS instances in regular IOS run in Single Topology mode, while IOS XR IS-IS instances run in Multi Topology mode. These modes are not compatible with each other and must be configured to match, or to run in transition mode. In this example Single Topology is run on all devices since the IPv4 and IPv6 topology is on a 1:1 basis.
router isis
metric-style wide
address-family ipv6
Required configuration in IOS. XR defaults to multi-topology.In Multi Topology IS-IS, separate protocol stacks maintain separate database structures and use separate SPF runs, which means that one topology is independent of another. Multi Topology IS-IS is most useful in practical IPv4 to IPv6 migration scenarios, where IPv6 is slowly introduced to the already existing IPv4 core. During migration the IPv4 and IPv6 topologies are kept separate from a database calculation point of view inside of IS-IS. Once the migration is complete and IPv4 and IPv6 run on a 1:1 basis with each other, Single Topology IS-IS can be enabled, which means that both IPv4 and IPv6 topology share the same database and SPF run. Note that this design is only possible if IPv4 runs on all interfaces that IPv6 runs on and vice-versa, otherwise database inconsistencies can occur which can result in loss of reachability in the network.
interface Ethernet 1/0
no mpls ldp igp autoconfig

mpls ldp
interface Ethernet 1/0
igp auto-config disable
LDP IGP autoconfig can be selectively disabled per interface
mpls ldp neighbor password <password>Per-neighbor authentication
no mpls ip propagate-ttl forwarded forwarded keyword allows local traceroutes (e.g. on PE's) to continue to be propagated... the default behavior is to eliminate it for both forwarded and local traffic.
interface FastEthernet1/0
ip policy route-map VRF_SELECTION_WITH_PBR
ip vrf receive VPN_A
ip vrf receive VPN_B
ip vrf receive VPN_C
When using PBR route-map to selectively assign VRF don't forget to configure the interface address into the VRF select database with "ip vrf receive <VRF_NAME>"!!
ip route profileExcellent way to observe route churn in routing table.
address-family ipv4
bgp suppress-inactive
Prevents rib-failure routes from still being advertised to a BGP peer in IOS.
Note a key caveat of IOS XR here, that even though LDP is not used for label distribution, the command mpls ldp must be entered globally in order to allow the forwarding of MPLS labeled packets (TE tunnels!):

mpls ldp
(config)# interface Serial2/0
(config-if)# encapsulation frame-relay
(config)# connect FR Serial2/0 100 l2transport <<<<<<<<<<<
(config-fr-pw-switching)# xconnect 12 pw-class FR_TO_FR
Used for configuring xconnect on frame relay interfaces (like using frame-relay switching)
RP/0/7/CPU0:XR1(config)# interface POS0/7/0/0.100 l2transport
RP/0/7/CPU0:XR1(config-if)# pvc 100
IMPORTANT--for PW configuring the FR subinterface as l2transport on the PE towards the CE (and not point-to-point) is required! CE should be configured towards PE as point-to-point.
Don't forget DTE/DCE configurations for serial interfaces... yes, it's a stupid thing... but don't let yourself waste time on it!
(config)# frame-relay switchingRequired in IOS for interworking Frame Relay DO NOT FORGET THIS STUPID THING when intf-type is switched to DCE
address-family ipv4
mdt source Loopback0
interface all enable
Enabling PIM on all interfaces in XR is actually easy but weird. You can simply enable multicast routing on all interfaces using this configuration.
Although PIM can be enabled automatically on all interfaces under the multicast-routing context in XR, BSR/Auto-RP configuration is done under the "router pim" context.
router ospf 1
mpls traffic-eng router-id loopback0
area 0
mpls traffic-eng
Don't forget that with OSPF based MPLS TE the router-id is configured directly under the IGP process in XR, but actually enabling it needs to be done the area sub-config.
address-family ipv4
mdt source loopback0 <<<<<<<<
Bigtime gotcha here... without this MDT endpoint will not be advertised via BGP in XR*
IOS ... IOX:
show ip pim rp mapping == show pim range-list
show ip mroute == show pim topology
IOS and IOX equivalents for multicast
show ip route (RP address)
show ip rpf
Don't forget the basic commands for tracing multicast flows from a receiver.
router bgp 17819
vrf CSC
address-family ipv4 unicast
!!% 'BGP' detected the 'warning' condition 'The parent address family has not been initialized'

Interesting but makes sense, it just confused me while I was working on it. The "parent" address family is actually VPNv4! BGP needs to have the VPNv4 address family configured for VRF's to be configured with _any_ address family.
In XR 3.9 BGP+Label is the only PE-CE allowed method of exchanging labels.
IGP+LDP PE-CE not allowed in XR.
IGP+LDP PE-CE not allowed in XR.
Specifying the metric when redistributing PE-CE from IGP into BGP doesn't seem to actually change the BGP metric for the PE-CE links. This can lead to some confusion when redistributing back into RIP on remote XR PE routers (when suddenly the zero metric issue arises, and the CE's aren't being advertised 0 metric routes from the XR PE)
dr-priority 0 on upstream interface from test source (e.g. ping in some cases if the router generating the traffic was the DR it wouldn't send a join.Testing joining a group on the edge? Set DR priority 0 on upstream interface.
"speed nonegotiate" on switch side can bring the XR connection to life, alternatively autonegotion can be enabled on the XR interface.

RP/0/0/CPU0:XR1(config)#do show bgp vrf ABC neigh
Tue Jun 4 11:27:36.786 UTC

BGP neighbor is, vrf ABC
Remote AS 65001, local AS 26, external link
Remote router ID <<<<<<<<<<<<<<<<<<<<
In XR BGP attempts to obtain a router ID in the following ways (in order of preference):

1. Configured bgp router-id
2. Highest IPv4 address on a loopback interface in the system if in saved configuration.
3. Primary IPv4 address of the first loopback address that gets configured.

If none of these methods for obtaining a router ID succeeds, BGP does not have a router ID and cannot establish any peering sessions with BGP neighbors. In such an instance, an error message is entered in the system log, and the show bgp summary command displays a router ID of
Remote router ID in XR means no ID defined.
address-family ipv6
neighbor OTHER_PE activate
neighbor OTHER_PE send-label <<<<<<<<<<<<<<
6PE = No VPNv6, No VRF. Used as a mechanism to have MP-BGP advertise IPv6 prefixes along with a label and label switch it across an IPv6-free core (IPv4+Label).
In IPv6 address family configuration mode this (send-label) command enables binding and advertisement of aggregate labels when advertising IPv6 prefixes in BGP.send-label in AF IPv6 neighbor is for 6PE.
router isis 1
mpls traffic-eng multicast-intact <<<<<<<<<<<<<<<
The mpls traffic-eng multicast-intact command allows PIM to use the native hop-by-hop neighbors even though the unicast routing is using MPLS TE tunnels.

***The mpls traffic-eng multicast-intact command can only be used with "autoroute announce" functionality. rpf check each of the PE's to insure there no Null RPF neighbors.
XR :
address-family vpnv4 uni
retain route-target all <<<<<<

This is sneaky... if there is only an RD and _no_ route-target extended community then XR _still_ won't learn the prefix. The prefixes _must_ have RT's.This is different from IOS behavior--in IOS any MP-BGP prefix will be accepted on a RR regardless of the presence of an RT extended community.*
mpls traffic-eng passive-interface nbr-te-id nbr-if-addr the Inter-AS edge interfaces this "helper address" is key to allow for TE tunnels to operate.Only Inter-AS, not needed for merely Inter-Area.
Rabbit hole avoidance: always double-check that "mpls traffic-eng tun" is configured on every interface each step of the way.... you spent a lot of time working this Inter-AS part of the lab only to find that on the ABR-ABR interface you missed it.
Wow man... be really careful about using route-maps and matching ipv6 prefix-lists. You spent a long time trying to figure out why an outbound BGP policy was _sort_ of working and it ended up being because you were matching on a non-existent IPv4 prefix-list in the outbound route-map (you had created an IPv6 prefix-list, of course, but told it to match ip prefix-list on that named IPv6 prefix-list)
If you are sending a label via BGP IPv4 + Label and you have an outbound route-map applied, the route-map will strip the label unless you "set mpls-label" in each route-map sequence.I WAS CAUGHT BY THIS AGAIN TODAY... THIS IS A REALLY INSIDIOUS ONE, VERY HARD TO FIGURE OUT! ***LEARN TO ASSOCIATE NO LABEL ALLOCATION ON ASBR'S WITH ROUTE-MAPS!!! ***A mental red light should be going off if you see outbound route-maps on an edge router that are exchanging labels.
Tip (maybe?): After all of the base connectivity is complete it might be a good idea to whip up a fast new diagram for just the VPN stuff. It removes a lot of clutter.
I had one AS set up so each PE advertised it's own loopback into the IPv4 AF. At the XR based ASBR I tried to advertise these prefixes to the ASBR in the other AS as unicast-labeled and I was unable to learn the prefixes on the remote AS until the XR based ASBR originated the loopbacks of the other PE's in it's AS.

Is this normal behavior? *YES* Only the originator of the BGP route can allocate the label.
Basically always originate the prefixes you want labeled on the BGP ASBR's.
ISIS as a PE-CE routing protocol doesn't seem to redistribute the connected PE-CE interfaces into BGP by default when redistributing from ISIS into BGP. I'm not sure why, but I could only see those prefixes redistributed into BGP after being learned via ISIS by an alternate PE. This may take further testing to understand better.'
There needs to be a label exchange and forwarding end-to-end for transport: remember this, it's a really central concept.Remember: label exchange, final PE to final PE. Upstream interface also must be able to receive labeled packets.
show run vrf VRF_NAMEThis is called the MPLS VPN Show Running VRF feature. It actually makes it very easy to see all of the configuration present in the running config for a specific VRF.
mpls ldp neighbor password PASSWORDUse these statements rather than "mpls ldp password option 1 for ACL PASSWORD" if it makes sense to. It's a little simpler and more straightforward.
router ospf 1
mpls traffic-eng multicast-intact
Think of IPv4 Multicast SAFI in BGP as being a way to propagate mroute entries/modify RPF interface. For example, if you wanted to add an interface to an IIL you could peer with a router advertising the sources network, learn the NLRI for the source, and the interface towards the BGP peer would then be present in an mroute entry for that NLRI. You might have to manipulate AD to prefer it over IGP learned NLRI towards the source.

Confirm it with "show ip mroute" (look for Mbgp) and "show ip rpf"
Incoming interface: FastEthernet0/0, RPF nbr, Mbgp <<<<<<<

RPF information for ? (
RPF interface: FastEthernet0/0
RPF neighbor: ? (
RPF route/mask:
RPF type: multicast (bgp 65000) <<<<<<<<<<<<<<<<<
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base
Confirm working MDT tunnels by checking for the presence of PIM neighbors in the VRF to each PE
Be careful about careless "no neighbor" statements in the BGP AF config--this will wipe out the entire BGP neighbor config in BGP! Be sure to specify "no neighbor activate" in its entirety.Always unconfigure as specifically as possible.
Be _SURE_ to configure an MPLS TE router-id in the IGP--I was surprised that this was holding me up today!Always definite static router-id's.
redistribute isis ipTook me too many minutes to dig this up :) Must be tired... "redistribute isis ip" for leaking routes between levels in ISIS on IOS
When redistributing between levels in ISIS for the IPv6 AF... a "distribute-list" denotes an "ipv6 prefix-list" actually and _not_ an ipv6 access-list. This one caught me, and was confusing (is there something wrong with my ACL syntax?? is what I kept thinking)Always check the contextual help system to verify what type of list is needed.*
It doesn't make sense (if you think about it!) to use "next-hop-self" on VPNv4 iBGP neighbors in an Inter-AS configuration: by doing this you're basically forcing everything to get switched through the local RR rather than retain the next-hop of the PE for whoms VPNv4 you have learned from the RR.
Use route-maps to filter what you redistribute into your IGP from other AS's is a good idea.
Using that ping script is smart... you got something you may not have (forgot to configure the iBGP peers as route reflector clients on the RR)
Be careful in XR about creating the /32 static routes for IPv4+Label CEF resolution _in_ the proper VRF!
bgp recursion host
interface Serial0/0/0.100 l2transportI think this may have been what got you in the first lab attempt: when using subinterfaces for AToM in XR the l2transport option _must_ be appended to the interface definition statement itself (e.g. interface Serial0/0/0.100 l2transport) rather than "point-to-point". This is particularly easy to miss because, unlike the physical interface, "l2transport" is _not_ an option under the subinterface configuration.Always configure l2transport using an interface definition statement. This will work for the physical interfaces or for these subinterfaces as well.*
LSA type 5 does not support the down bit... by default the route should be tagged to the AS number when redistributed into MP-BGP. This is the whole point of the OSPF domain tag, actually.
show mpls traffic-eng topology | i "^IGP|Link"It's those little things that will get me... verify! Today you forgot that you had to specify the interfaces you wanted to enable "mpls traffic-eng" on in XR under that context. You did it in RSVP but not in "mpls traffic-eng" for some reason.Verify that all links that should be are active in the topology
Be really careful with the "address-family ipv4 labeled-unicast" and "address-family ipv6 labeled-unicast" configs in XR. I accidentily put configurations under "address-family ipv4 unicast" and "address-family ipv6 unicast" when I was testing out 6PE.
ip community-list expanded
ip extcommunity-list
Don't confuse an _expanded_ standard community list with an _extended_ community list! (this is relevant with partioned RR's and rr-groups... or anything that needs to match the route-target extended community, actually)
Prepending the last-as in a route-map works as long as there is an AS actually in the path. :) Doesn't work like you might think on the edge of an AS... seems that the prepending step occurs before the AS path gets updated with the current AS before the update gets sent to the eBGP peer.Explicitly set the AS number when prepending... don't trust last-as to work.
Really interesting... it might be easy to make the mistake of trying to configure a GRE tunnel between two endpoints in the same VPN across a provider--doesn't work on the PE! You must use a tunnel source and destination from the global routing table.
If you need to configure static mroute entries at tactical spots, don't forget that future tasks may require additional statements to fulfill the requirement. (e.g. MDT with ASM over a GRE tunnel between two AS's with a PE in each one.)
Just got caught using "match ip address NAME" instead of "match ip address prefix-list NAME" ... it's an easy mistake, be careful.
pseudowire-class L2TPV3
encapsulation l2tpv3
interworking ip
ip local interface Loopback0 <<<<<<<<<
You had to check the configuration guide (which was hidden in the WAN section) for L2TPv3 PW configuration. You need to explicitly configure the local interface within the pseudowire-class in order for the L2TPv3 PW to come up. This is actually the only real difference in the configuration steps for L2TPV3 versus MPLS. shows a nice warning message in the "show run interface" output indicating the problem. Just be sure to associate that with "local interface" mentally.*
pw-class FR_TO_ETH
encapsulation mpls
transport-mode ethernet
xconnect group GROUP1
p2p VLAN100
interface GigabitEthernet0/1/0/1.100
neighbor pw-id 100
pw-class FR_TO_ETH
interworking ipv4 <<<<<<<<<<<<<<<<<
"interworking ipv4" is configured under the p2p subconfig of the xconnect group in XR--just because you have the transport-mode defined in the pseudowire class doesn't mean you have interworking configured!If interworking is required, remember to specify interworking ipv4 as needed.
RPF failures can be easy to miss in a complex MDT setup.

This is such an important thing: Check for NULL IIL in the global mroute tables.

The real gotcha here, is that configuring "autoroute destination" merely creates a static route for the tunnel destination... this means that configuring the IGP to keep the multicast intact does _nothing_ and there remains an RPF failure.

ONLY if "autoroute announce" is used on the TE tunnel interface will configuring the IGP with "mpls traffic-eng multicast-intact" fix the RPF issue, otherwise a static mroute is necessary.
Verify each node:
show ip mroute | i ^\(|Null,

If able:
mpls traffic-eng multicast-intact

ip mroute <source> <outbound IF>
Always the small stuff... you should develop a better checklist of things to look for when things "just aren't working". This time it was multicast-routing not being enabled for the customer VRF on a PE. You spent a good 15-20 minutes trying to figure that out because the other PE was XR based and you had nothing to compare the IOS based PE against line for line.Systematically check all of the mroute tables on each involved node... if you find an empty one, guess what you forgot to enable?
More small stuff... you spent a good 10-15 minutes troubleshooting the CSC lab all because you mistakenly put the XR static /32 route into the global table instead of the VRF table on the "Core Carrier"
After updating the BGP timers you'll need to restart the BGP sessions in order for the timers to negotiate and become active.
MDT tunnels won't come up if "ip pim ssm default" is not configured and you have no RP defined. This is completely obvious but took you a couple of minutes to realize today.
Prefix-lists don't seem to work so well with Policy Based Routing. I could only get PBR based VRF selection to work properly using ACL's.
MPLS TE FRR Link Protection (NHOP) versus Node Protection (NNHOP) is really easy. The only difference is with Link Protection you are avoiding the next-hop link address and with Node Protection you are avoiding the TE ID (Loopback) address in the path list.
Using the next-hop self method for RTBH you should be careful about using a PE as the trigger router... the reason being is that the "next-hop-self" statement to the RR in your AS seems to have the final authority (over the route-map) on the next-hop address of the prefix you may be trying to trigger to be blackholed. It seems wiser to use communities and modify the next-hop on the blackholing routers.
interface Null0
no ip unreachables
I never realized you could configure the Null0 interface to prevent IP unreachable messages! Really cool from a RTBH perspective.