R2#traceroute mpls traffic-eng tunnel 0

Tracing MPLS TE Label Switched Path on Tunnel0, timeout is 2

seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output
interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC
mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no
label entry, 'P' - no rx intf label prot, 'p' - premature
termination of LSP,
'R' - transit router, 'I' - unknown upstream index,

'X' - unknown return code, 'x' - return Type escape sequence

to abort.

0 26.2.4.2 MRU 1500 L 1 26.2.4.4 MRU 1500 L 2 26.4.5.5 MRU

1500 L 3 26.5.6.6 MRU 1500 L 4 26.3.6.3 MRU 1504 ! 5
26.3.19.19 140 ms

IOS-XR

[Labels:
[Labels:
[Labels:
[Labels:
[Labels:

code 0

22 Exp: 0]
22 Exp: 0]
21 Exp: 0]
22 Exp: 0]
implicit-null Exp: 0] 112 ms

76 ms
80 ms
104 ms

GSR#traceroute mpls traffic-eng tunnel 0

Tracing MPLS TE Label Switched Path on tunnel-te0, timeout is

2 seconds

Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output
interface, 'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' -
FEC mismatch, 'M' - malformed request, 'm' - unsupported tlvs,
'N' - no rx label, 'P' - no rx intf label prot, 'p' -
premature termination of LSP, 'R' - transit router, 'I' -
unknown upstream index,
'X' - unknown return code, 'x' - return code 0

Type escape sequence to abort.

0 2.2.78.8 MRU 1500 [Labels: L 1 2.2.78.7 MRU 1500 [Labels: L

2 2.2.27.2 MRU 1504 [Labels: ! 3 2.2.29.9 9 ms

MPLStracerouteinIOS-XRrequires"mpls 217

22 Exp: 0]
23 Exp: 0] 41 ms implicit-null Exp: 0] 126 ms

oam"tobeenabled.

NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

setup/hold priorities

Every LSP/tunnel has a setup and a hold priority, each one having values from 0 (best) to 7
(worst).

setup priority
o used when the LSP is being established

hold priority
o used when the LSP is already established

IOS

interface Tunnel0
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 2.2.2.2
tunnel mpls traffic-eng priority 4 4
tunnel mpls traffic-eng path-option 1 dynamic

IOS-XR

interface tunnel-te0
ipv4 unnumbered Loopback0 priority 4 4
destination 2.2.2.2 path-option 1 dynamic
Preemption
When an LSP is set up across a path where resources have been exhausted, its setup priority
is compared to the hold priority of all the LSPs already using the resources, in order to
determine if the new LSP can preempt an existing LSP and use its resources.

Do not use a hold priority that is worse than the setup priority, otherwise you might end up
with continuous preemption (the software will probably prohibit you from doing so).

Using a high hold priority is recommended for stable environments.

When having primary and backup tunnels, it's good practice to assign better priorities to
primary tunnels.

IOS-XR supports soft-preemption, which tries to preempt tunnels with the least possible
disruption. You have to enable it under the tunnel and on every node.

LSP attributes

It provides the ability to configure values for several LSP-specific path-options for TE
tunnels. One or more TE tunnels can specify specific path-options by referencing an LSP
attribute list. You can configure LSP attributes lists with different sets of attributes for each
path-option

218 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Attributes that can be used:

  affinity (
 auto-bw )
 bandwidth
 lockdown (
 priority( )
 protection (
 record-route (

IOS

)
, IOS-XR)

)
)

IOS,

(IOS

IOS-XR

(IOS

IOS)

IOS

IOS

IOS

LSP attribute list values referenced by the path-option take precedence over the values
configured on the
tunnel interface.

mpls traffic-eng lsp attributes LSP-ATTR-1 bandwidth 22222

priority 6 6

interface Tunnel0
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 19.19.19.19
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 7 7
tunnel mpls traffic-eng bandwidth 50000
tunnel mpls traffic-eng path-option 1 explicit name R3-R4-R6-
R5

attributes LSP-ATTR-1

IOS-XR

mpls traffic-eng
attribute-set path-option LSP-ATTR-1

signalled-bandwidth 22222 !

interface tunnel-te0
ipv4 unnumbered Loopback0
signalled-bandwidth 50000
destination 2.2.2.2
path-option 1 dynamic attribute-set LSP-ATTR-1

IOS

R2#sh mpls traffic-eng lsp attributes LIST LSP-ATTR-1

bandwidth 22222
priority 6 6

219 NTS for CCIE SP Lab by chatasos

P2P TUNNELS/LSPs:

Name: R2_t0
19.19.19.19
Status:
Admin: up
connected
Oper: up

(Tunnel0) Destination:

Path: valid Signalling:

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

R2#sh mpls traffic-eng tunnels

path option 1, type explicit R3-R4-R6-R5 (Basis for Setup,

path weight 50)

Config Parameters:
Bandwidth: 22222 kbps (Global) Priority: 6 6 Affinity:

0x0/0xFFFF
Metric Type: TE (default)
AutoRoute announce: enabled LockDown: disabled Loadshare:
22222

bw-based
auto-bw: disabled

...

TE LSP reoptimization

Tunnel reoptimization is the signaling of an new LSP that is more optimal (i.e. with a lower
metric) than the current LSP a TE tunnel is using and the switching over of the tunnel's data
to use this new LSP.

The new more optimal TE LSP is always established and the data moved onto it before the
original LSP is torn down (using RSVP shared explicit reservation style), in order to ensure
that no data packets are lost during the transition to the new LSP.

The TE LSPs reoptimization process is triggered under the following circumstances:

 periodically (based on a timer)

 manually(usingthecommand"mpls traffic-eng reoptimize")
 after a network event (i.e. link-up)

Regardless of how reoptimization is triggered, the head-end router reoptimizes a

tunnel only if it can find a better path than the one the tunnel currently uses. If there is
no better path in the TE database (topology), then no new LSP is signaled and
reoptimization does not occur.
IfwhenapplyingtheLSPattributestoapath-optionyougetawarninglike"% Setup priority
is

inconsistent with popt x",thenyouhavetocheckthexpath-

optionforapossibleinconsistency.

220 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

You can use the "lockdown" keyword with any tunnel path-option if you want to disable
reoptimization for a specific path-option of a tunnel.

Links

IETF - RFC 4736

TE Tunnels for VPN

There is no need to have a single end-to-end LSP tunnel between two PEs. You can have:

 multipleTE tunnels (one after the other) between the PEs, using "stitching" on the
intermediate P routers
 a combination of TE tunnels plus LDP sessions

Then, traffic can be forwarded from the P to the end PE and have the VPN label
popped there without any issue.

Generally, for VPN traffic the following types of TE tunnels be used:

PE-to-PE tunnels
o high number of LSPs

o no extra LDP required P-to-P tunnels

o low number of LSPs

o LDP over IP Tunnel or LDP over TE Tunnel is required PE-to-P tunnels

o medium number of LSPs

o tLDP over TE Tunnel is required

TE Routing & Traffic Selection

You can route through the TE tunnel using one of the following:

static route (for the tunnel destination) o supported on inter-area tunnels

static route (for a loopback on the tail-end) o supported on inter-area tunnels

autoroute announce
o the tunnel destination is announced automatically into the IGP of the head-end only o not
supported on inter-area tunnels

autoroutedestination
221 NTS for CCIE SP Lab by chatasos
When doing PE-to-P TE tunnels you must be careful of the PHP happening one hop before
the P,

exposing the bottom VPN label to it. One solution is to create an extra layer of labels between
the PE and

the P (using a tLDP session across the tunnel) in order to avoid exposing the VPN label and
expose a

transport label instead.

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

o the tunnel destination is announced automatically as a static route

o supported on inter-area tunnels forwarding adjacency

o the TE link is advertised like a normal link into the IGP of all routers policy-based
routing (PBR)

o traffic is forwarded across a TE tunnel based on a route-map criteria

o supported on inter-area tunnels policy-based tunnel selection (PBTS)

o traffic is forwarded across TE tunnels based on a single EXP value per tunnel

o supported on inter-area tunnels class-based tunnel selection (CBTS)

o traffic is forwarded across TE tunnels based on one or more EXP values per tunnel o
supported on inter-area tunnels

MPLS L3VPN through MPLS TE Tunnel

If the BGP next-hop (for MPLS-VPN) is different from the MPLS-TE router-ID of the tail-
end (i.e. if this is notaPE-
PETEtunnel),thenyouneedtoenableLDPoverthetunnel(i.e.enable"mpls ip"ontheTE tunnel
interface).

static route

IOS

interface Tunnel0
tunnel destination x.x.x.x

ip route x.x.x.x 255.255.255.255 Tunnel0

IOS-XR

interface tunnel-te0 destination y.y.y.y

router static
address-family ipv4 unicast

y.y.y.y/32 tunnel-te0

You can also use a static route for a loopback on the tail-end, and then use that loopback for
BGP next-hop under a specific VRF.

IOS
PE-1

vrf definition VPN address-family ipv4

bgp next-hop Loopback100 exit-address-family

222 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

!
interface Loopback100

ip address 100.100.100.1 255.255.255.255 !

ip route 100.100.100.2 255.255.255.255 Tunnel0

PE-2

vrf definition VPN address-family ipv4

bgp next-hop Loopback100 exit-address-family

!
interface Loopback100

ip address 100.100.100.2 255.255.255.255 !

ip route 100.100.100.1 255.255.255.255 Tunnel0

autoroute announce

IOS

interface Tunnel0
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 2.2.2.2
tunnel mpls traffic-eng autoroute announce tunnel mpls
traffic-eng path-option 1 dynamic

R1#sh ip route 2.2.2.2 Routing entry for 2.2.2.2/32

Known via "ospf 1", distance 110, metric 4, type intra area
Last update from 2.2.2.2on Tunnel0, 00:03:39 ago
Routing Descriptor Blocks:
* 2.2.2.2, from 2.2.2.2, 00:03:39 ago, via Tunnel0

Route metric is 4, traffic share count is 1

IOS-XR

interface tunnel-te0
ipv4 unnumbered Loopback0 autoroute announce destination
2.2.2.2 path-option 1 dynamic

GSR#sh route 2.2.2.2

Routing entry for 2.2.0.9/32

Known via "isis 1", distance 115, metric 30, type level-1
Installed Jan 16 13:29:24.723 for 01:11:17
223 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Routing Descriptor Blocks

2.2.2.2, from 2.2.2.2, via tunnel-te0

Route metric is 30 No advertising protos.

autoroute destination

IOS

interface Tunnel0
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 2.2.2.2
tunnel mpls traffic-eng autoroute destination tunnel mpls
traffic-eng path-option 1 dynamic

R1#sh ip route 2.2.2.2 Routing entry for 2.2.2.2/32

Known via "static", distance 1, metric 0 (connected) Routing

Descriptor Blocks:
* directly connected, via Tunnel0

Route metric is 0, traffic share count is 1

IOS-XR

not supported

If there is another static route manually configured, then traffic is load-balanced (unless a
different metric is used).

Ifboth"autoroute announce"and"autoroute
destination"areconfigured,then"autoroute destination" becomes active, due to
the static route having precedence over IGP in the RIB.

forwarding adjacency

IOS

interface Tunnel0
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 10.0.0.1
tunnel mpls traffic-eng forwarding-adjacency tunnel mpls
traffic-eng path-option 1 dynamic

It's obvious that if you want to route other than the tunnel destination traffic through the
tunnel, the autoroute

options won't help you.

224 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

IOS-XR

interface tunnel-te0
ipv4 unnumbered Loopback0 destination 10.0.0.2 forwarding-
adjacency path-option 1 dynamic

LSP tunnel must be bidirectional.

If you don't set the IGP metric under the tunnel interface, the default IGP metric will be used
(which might not provide the expected results). In any case you have to be very careful of
loops.

Autoroute announce should not be used together with forwarding-adjacency.

Although a bidirectional tunnel is required, there is no actual IGP adjacency established over
the TE tunnel.

An easy way to verify the existence of the tunnel in the ISIS topology is to use the following
command:

IOS

R2#sh isis topology | i System|TE

System Id
R5
TE-Tunnel
R6
TE-Tunnel
XR1
TE-Tunnel

Policy-Based Routing (PBR)

IOS

Metric Next-Hop Interface SNPA 19 XR1 Tu0 *MPLS

19 XR1 Tu0 *MPLS 9 XR1 Tu0 *MPLS

interface FastEthernet1/0
ip policy route-map TO-TUNNEL-ROUTEMAP
!
route-map TO-TUNNEL-ROUTEMAP permit 10

set interface Tunnel0

PBR for VRF traffic is not supported. You can use static route + vrf bgp next-hop in order to
forward each

VRF to a different TE tunnel.

225 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

CBTS (Class-Based Tunnel Selection)

It's EXP-based tunnel selection between multiple tunnels to same destination.

CBTS does not allow load-balancing of a given EXP value in multiple tunnels.

CBTS is not supported with AToM and MPLS TE Automesh.

If the input QoS policy modifies the EXP value, CBTS uses the modified EXP value for its
tunnel selection. If the output QoS policy modifies the EXP value, CBTS uses the original
EXP value for its tunnel selection.

Tunnel Selection

All comparisons are made per tunnel prefix (static route, autoroute). Only tunnels with the
best metric are used for CBTS.

specific EXP is configured on a single tunnel and there is a single default EXP tunnel o
traffic with that EXP is forwarded into the specific EXP tunnel
o traffic with other EXPs is forwarded into the default EXP tunnel

specific EXP is configured on multiple tunnels and there is a single default EXP tunnel
o traffic with that EXP is forwarded into one of the specific EXP tunnels (based on lowest
EXP

and lowest tunnel ID)

o traffic with other EXPs is forwarded into the default EXP tunnel

specific EXPs are configured on multiple tunnels and there is no default EXP tunnel
o traffic with a specific EXP is forwarded into the specific EXP tunnel
o traffic with other EXPs is forwarded into the EXP tunnel with the lowest EXP value

specific EXP is not configured on any tunnel and there is a single default EXP tunnel o
traffic with any EXP is forwarded into the default EXP tunnel

specific EXP is not configured on any tunnel and there are multiple default EXP tunnels o
traffic with any EXP is forwarded (arbitrarily) into one of the default EXP tunnels

specific
EXP is not configured on any tunnel and there is no default EXP tunnel o traffic
with any EXP is load-balanced across all tunnels

Since static route has precedence over (dynamic) autoroute,

This is also applicable and on same-type tunnels (i.e. autoroute ones) with different metrics,
where only the one with the best metric is used by CBTS.
Configuration

 Tunnel master bundles tunnel members

 Tunnel selection (autoroute, etc.) configured on tunnel master
 Bundle members configured with EXP values to carry

IOS

interface Tunnel0
ip unnumbered Loopback0

and autoroute accordingly, then only the one with the static route is chosen for the CBTS,
regardless of the

if two tunnels for the same prefix use static route

EXP values configured in them.

226 NTS for CCIE SP Lab by chatasos

Exp

Members

Tunnel0
Tunnel1

Status

up (Active)
up (Active)

Actual

3 5
0 1 2 4 6

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

tunnel mode mpls traffic-eng

tunnel destination 2.2.2.2
tunnel mpls traffic-eng path-option 1 dynamic tunnel mpls
traffic-eng exp 3 5

!
interface Tunnel1
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 2.2.2.2
tunnel mpls traffic-eng path-option 1 dynamic tunnel mpls
traffic-eng exp default

!
interface Tunnel1000

ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 2.2.2.2
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng exp-bundle master
tunnel mpls traffic-eng exp-bundle member Tunnel0 tunnel mpls
traffic-eng exp-bundle member Tunnel1

IOS

R1#sh mpls traffic-eng exp Destination: 2.2.2.2

Master: Tunnel1000

Status: up
Conf Exp

3 5 Default

(D) : Destination is different

(NE): Exp values not configured on tunnel

IOS-XR

not supported
227

NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Policy-Based Tunnel Selection (PBTS)

It's EXP-based tunnel selection between multiple tunnels to same destination.

Similar to CBTS, but only one class per tunnel is supported and no tunnel-bundle is required.
PBTS has precedence over CBTS.
Configuration
 Tunnels configured via policy-class with one EXP value to carry
 Tunnel without policy-class acts as default

IOS

not supported

IOS-XR

interface tunnel-te0
ipv4 unnumbered Loopback0 destination 2.2.2.2 policy-
class 5 path-option 1 dynamic

!
interface tunnel-te1

ipv4 unnumbered Loopback0 destination 2.2.2.2 policy-

class default path-option 1 dynamic
228 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Advanced MPLS-TE
FRR (Fast ReRoute) extensions for RSVP-TE are defined in RFC 4090. Inter-Area MPLS TE
is described in RFC 4105.
Inter-AS MPLS TE is described in RFC 4216.

LSP Protection

path protection - long term

local protection (FRR) - short term
o link protection o node protection

When the new path is established and traffic is switched over to it, the backup path is torn
down.

PLR = Point of Local Repair MP = Merge Point

The constraints of the backup path are signaled by the head-end to the PLR using the Fast
Reroute Object (FRO) of RSVP.

many-to-one backup (facility backup)

o an extra label is pushed by the PLR
o MP advertises an implicit-null label (PHP)
o traffic arrives at the MP with the same label as the main path

one-to-one backup (detour backup)

o the top label is swapped by the PLR
o MP advertises a normal label (label swap)
o traffic arrives at the MP with a different label from the main path

Expect to see only the many-to-one backup being used.

The failure and the local restoration of a main path are signaled by the PLR to the head-end
using an RSVP Path-Error message (code="Notify", subcode="Tunnel locally repaired") and
an RRO flag.

FRR (Fast Reroute)

MPLS-TE/FRR is a mechanism for protecting MPLS TE LSPs from link and node failures by
locally repairing the LSPs at the point of failure. It allow traffic to continue to flow on the
LSPs, while their head- end routers attempt to establish new end-to-end LSPs to replace
them.
Backup tunnels are usually used for a short period of time, until the head-end recomputes and
signals a new

path.
229 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

FRR repairs locally the protected LSPs by rerouting them over backup tunnels that bypass
these failed links or nodes.

NHOP backup tunnels

o backup tunnels that bypass only a link of the LSP's path
o they provide link protection by rerouting the LSP's trafficto the next-hop o can be
specified by simply excluding the protected link (interface address)
NNHOP backup tunnels
o backup tunnels that bypass a node of the LSP's path
o they provide node (& link) protection by rerouting the LSP's traffic to the next-next-hop o
can be specified by simply excluding the protected node (loopback address)

FRR prefers NNHOP over NHOP backup tunnels, when both are available.

Configuration Steps

PE (head-end)
o enable FRR under the tunnel

PLR (point of local repair)

o configure a backup tunnel with a path that avoids the link/node to be protected o enable
the backup tunnel under the link to be protected
o enable RSVP hellos or BFD under the link to be protected (for faster detection)

PE (head-end)

IOS

interface Tunnel0
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 19.19.19.19
tunnel mpls traffic-eng path-option 1 explicit name X tunnel
mpls traffic-eng fast-reroute

IOS-XR

interface tunnel-te0
ipv4 unnumbered Loopback0 destination 19.19.19.19 fast-reroute
path-option 1 explicit name X

You also have the following options if you want to influence the backup tunnel selection on
the PLR:

IOS

R2(config-if)#tunnel mpls traffic-eng fast-reroute ? bw-

protect bandwidth protection desired node-protect node
protection desired
230 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

IOS-XR

CRS(config-if)#fast-reroute protect ?
bandwidth Enable bandwidth protection request node Enable node
protection request

IOS-XR by default tries to provide the best available protection, even if the above two
options aren't activated.

PLR (point of local repair)

IOS

interface Tunnel0
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 5.5.5.5
tunnel mpls traffic-eng path-option 1 explicit name AVOID-X

!
ip explicit-path name AVOID-X enable

exclude-address x.x.x.x !

interface FastEthernet0/0
mpls traffic-eng backup-path Tunnel0 ip rsvp signalling hello
IOS-XR

interface tunnel-te0
ipv4 unnumbered Loopback0 destination 5.5.5.5
path-option 1 explicit name AVOID-X

!
explicit-path name AVOID-X

index 1 exclude-address ipv4 unicast x.x.x.x !

mpls traffic-eng

interface TenGigE0/0/0/0 backup-path tunnel-te 0

Thesame"rsvp signalling
hello"type(RSVPhellosorBFD)mustbeconfiguredontheotherside

too for fast detection to take place.

IOS-XR supports only BFD for fast detection (< 1sec). RSVP hellos can be used for simple
reroute (detection

> 10sec) or GR.

231 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Verification

PE (head-end)

IOS

R2#sh mpls traffic-eng tunnels protection P2P TUNNELS:

R2_t0
LSP Head, Tunnel0, Admin: up, Oper: up
Src 2.2.2.2, Dest 19.19.19.19, Instance 46 Fast Reroute
Protection: Requested

Outbound: Unprotected: no backup tunnel assigned LSP

signalling info:

Original: out i/f: Fa0/0.23, label: 18, nhop: 20.2.3.3

nnhop: 4.4.4.4; nnhop Path Protection: None

PLR (point of local repair)

before the activation of the backup tunnel

IOS

R4#sh mpls traffic-eng tunnels backup R4_t0

LSP Head, Admin: up, Oper: up

Tun ID: 0, LSP ID: 3, Source: 4.4.4.4 Destination: 5.5.5.5
Fast Reroute Backup Provided:

rtr id: 4.4.4.4

Protected i/fs: Fa0/0.45

Protected LSPs/Sub-LSPs: 1, Active:
Backup BW: any pool unlimited; inuse: 0 kbps Backup flags: 0x0

R4#sh mpls traffic-eng fast-reroute database role middle P2P

LSP midpoint frr information:

LSP identifier
Status --------------------------- ------
2.2.2.2 0 [46]

Ready

In-label
--------
16

FRR intf/label --------------

Out intf/label -------------- Fa0/0.45:18 Tu0:18

232

NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

R4#sh mpls traffic-eng fast-reroute database role middle

detail FRR Database Summary:

Protected interfaces : 1 Protected LSPs/Sub-LSPs : 1 Backup

tunnels : 1 Active interfaces : 0

P2P LSPs:

Tun ID: 0, LSP ID: 46, Source: 2.2.2.2 Destination:

19.19.19.19

State

InLabel
OutLabel
FRR OutLabel

: Ready

:16
: Fa0/0.45:18 : Tu0:18

after the the activation of the backup tunnel

R4#sh mpls traffic-eng tunnels backup R4_t0

LSP Head, Admin: up, Oper: up
Tun ID: 0, LSP ID: 3, Source: 4.4.4.4 Destination: 5.5.5.5
Fast Reroute Backup Provided:

Protected i/fs: Fa0/0.45

Protected LSPs/Sub-LSPs: 1, Active: 1

Backup BW: any pool unlimited; inuse: 0 kbps Backup flags: 0x0

R4#sh mpls traffic-eng fast-reroute database role middle P2P

LSP midpoint frr information:

LSP identifier
Status --------------------------- ------

2.2.2.2 0 [46]

Active

In-label Out intf/label -------- -------------- 16 Fa0/0.45:18

FRR intf/label -------------- Tu0:18

R4#sh mpls traffic-eng fast-reroute database role middle

detail FRR Database Summary:

Protected interfaces : 1 Protected LSPs/Sub-LSPs : 1

Backup tunnels

Active interfaces

P2P LSPs:

: 1

: 1

233

NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Tun ID: 0, LSP ID: 46, Source: 2.2.2.2 Destination:
19.19.19.19

State

: Active

InLabel
OutLabel
FRR OutLabel : Tu0:18

: 16
: Fa0/0.45:18

When using MPLS-TE/FRR for node protection, a label_recording flag is included into the
SAO in order to

signal that the RRO should also include labels (because these labels are actually used by the
PLR for NNHOP

backup tunnels), although it's not shown in the tunnel config.

IOS

R2#sh mpls traffic-eng tunnels | b Resv RSVP Resv Info:

Record Route: 3.3.3.3(20) 4.4.4.4(20) 5.5.5.5(20)

19.19.19.19(0)

If you explicitly enable it in the config, then you get the address of the physical interfaces
too.

R2#sh mpls traffic-eng tunnels | b Resv RSVP Resv Info:

Record Route: 3.3.3.3(21) 20.3.4.3(21) 4.4.4.4(21)

20.4.5.4(21)

5.5.5.5(21) 20.5.19.5(21) 19.19.19.19(0) 20.5.19.19(0)

The path when using the backup tunnel is not reflected in the above output.
You can also use the following command on the PLR in order to verify the FRR operation.

IOS

R4#sh ip rsvp sender detail ...

Tun Dest: 19.19.19.19 Tun ID: 0 Ext Tun ID: 2.2.2.2

Tun Sender: 2.2.2.2 LSP ID: 25 ...

Fast-Reroute Backup info:

Inbound FRR: Not active
Outbound FRR: Ready -- backup tunnel selected

Backup Tunnel: Tu1 (label 19) Bkup Sender Template:

Tun Sender: 20.3.4.4 LSP ID: 25 Bkup FilerSpec:

Tun Sender: 20.3.4.4, LSP ID: 25

234

NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

or the following command on the head-end.

R2#sh ip rsvp reservation detail ...

Reservation:

Tun Dest: 19.19.19.19 Tun ID: 0 Ext Tun ID: 2.2.2.2 Tun
Sender: 2.2.2.2 LSP ID: 25
Next Hop: 20.2.3.3 on FastEthernet0/0.23
Label: 20 (outgoing)

Reservation Style is Shared-Explicit, QoS Service is

Controlled-Load Resv ID handle: 0A000415.
Created: 13:32:42 UTC Sat Jan 11 2014
Average Bitrate is 20M bits/sec, Maximum Burst is 1K bytes

Min Policed Unit: 0 bytes, Max Pkt Size: 1500 bytes RRO:

3.3.3.3/32, Flags:0x20 (No Local Protection, Node-id) Label

subobject: Flags 0x1, C-Type 1, Label 20

20.3.4.3/32, Flags:0x0 (No Local Protection) Label subobject:

Flags 0x1, C-Type 1, Label 20

4.4.4.4/32, Flags:0x25 (Local Prot Avail/Has BW/to NHOP, Node-

id) Label subobject: Flags 0x1, C-Type 1, Label 19
20.4.5.4/32, Flags:0x5 (Local Prot Avail/Has BW/to NHOP) Label
subobject: Flags 0x1, C-Type 1, Label 19

5.5.5.5/32, Flags:0x20 (No Local Protection, Node-id) Label

subobject: Flags 0x1, C-Type 1, Label 19

20.5.19.5/32, Flags:0x0 (No Local Protection) Label subobject:

Flags 0x1, C-Type 1, Label 19

19.19.19.19/32, Flags:0x20 (No Local Protection, Node-id)

Label subobject: Flags 0x1, C-Type 1, Label 0

20.5.19.19/32, Flags:0x0 (No Local Protection) Label

subobject: Flags 0x1, C-Type 1, Label 0

Status:
Policy: Accepted. Policy source(s): MPLS/TE

Then the backup tunnel gets activated, the output will change to:

IOS

R2#sh ip rsvp reservation detail ...

4.4.4.4/32, Flags:0x23 (Local Prot Avail/In Use/to NHOP, Node-

id) Label subobject: Flags 0x1, C-Type 1, Label 16

20.3.4.4/32, Flags:0x3 (Local Prot Avail/In Use/to NHOP) Label

subobject: Flags 0x1, C-Type 1, Label 16
235 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Path Protection
Apart from having link & node protection using FRR, you also have the option of enabling
path protection

end-to-end for a tunnel. You can have multiple backup path options per primary path option.
It's not as fast as FRR, but it's still faster than having a second path-option or relying on IGP,
because it pre-

calculates the whole backup path (like FRR).

It can be used with intra-area, inter-area and inter-AS scenarios.

IOS

interface Tunnel0
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 2.2.2
tunnel mpls traffic-eng path-option 1 explicit name PATH1
tunnel mpls traffic-eng path-option protect 1 explicit name
PATH1-BAK

R1#sh mpls traffic-eng tunnels protection

P2P TUNNELS:
R1_t0
LSP Head, Tunnel0, Admin: up, Oper: up Src 1.1.1.1, Dest
2.2.2.2, Instance 3 Fast Reroute Protection: None
Path Protection: Requested

You can also view the details about SRLGs:

R1#sh mpls traffic-eng tunnels tunnel0

Name: R1_t0 (Tunnel0) Destination: 2.2.2.2 Status:

Admin: up Oper: up Path: valid Signalling: connected

path option 1, type explicit PATH1 (Basis for Setup, path

weight 20)

Path Protection: 2 Common Link(s), 1 Common Node(s) Link

Sharing Detail:

P2P Links: 0 Multiacces Links: 2

Both interfaces: 1 interface:

0 interfaces:

2
0
0 (only media is shared)

path protect option 1, type explicit PATH1-BAK (Basis for

Protect, path weight 20)

Latest IOS software releases support enhanced path protection (up to 8 secondary path
options).

236 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

IOS-XR

interface tunnel-te0

path-protection

path-option 1 explicit name R2-R3-R4

path-option 2 dynamic !

interface tunnel-te1

path-protection
path-option 1 explicit name R2-R3-R4 protected-by 2 path-
option 2 explicit name R2-R5-R6

Path-protection is not supported on C12k platform for IOS-XR.

In IOS-XR you can either have explicit path as primary and dynamic as backup, or explicit
path as primary and backup. IOS-XR provides automatic path diversity.

Backup Tunnel Selection

The backup tunnel is configured on the PLR, under the physical interface to be protected.

IOS

interface X
mpls traffic-eng backup-path Tunnel0 mpls traffic-eng backup-
path Tunnel1

IOS-XR

mpls traffic-eng

interface X
backup-path tunnel-te 0 backup-path tunnel-te 1
You can have multiple backup tunnels protecting the same or different LSPs, each one
terminating on the

same destination or a different one.

237 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

The selection priority between multiple backup tunnels is based on the following table.

Preference Backup Tunnel Destination Bandwidth Pool Bandwidth Amount

1 (Best) Next-next hop Sub-pool or global-pool Limited

2 Next-next hop Limited

Any

3 Next-next hop Unlimited

Sub-pool or global-pool
4 Next-next hop Unlimited
 Any

5 Next-hop Sub-pool or global-pool Limited

6 Next-hop Limited
Any
Sub-pool or global-pool
7 Next-hop Unlimited

Any
8 (Worst) Next-hop Unlimited

The general idea is the following:

 NNHOP tunnels have priority over NHOP tunnels

 backup-bw tunnels have priority over no backup-bw tunnels
 specific pool tunnels have priority over any pool tunnels

After a backup tunnel has been chosen for an LSP, various conditions may change on
the network, that will cause the router to reevaluate this choice. This promotion can
happen immediately in case of a backup tunnel going up/down, or periodically every
5 mins. This time be changed by using the command "mpls traffic-eng
fast-reroute timers".Setitto0ifyouwanttodisablepromotionforLSPs.

backup protection algorithm

In the following example, main tunnel (that doesn't have any signaled bandwidth
configured) can use only backup tunnel #2.

main tunnel

interface Tunnel0

backup tunnel #1

interface Tunnel1
tunnel mpls traffic-eng backup-bw 30000

backup tunnel #2

interface Tunnel2
If the main tunnel doesn't have any bandwidth configured, then it can use only backup
tunnels that don't have

any backup-bandwidth configured.

If the main tunnel has a bandwidth configured, then it can use only backup tunnels that either
don't have any

backup-bandwidth configured or have sufficient backup-bandwidth configured.

238 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

In the following example, main tunnel (that has a bandwidth of 35M configured) can use only
backup tunnel #2 and #3.

main tunnel

interface Tunnel0
tunnel mpls traffic-eng bandwidth 35000

backup tunnel #1
interface Tunnel1
tunnel mpls traffic-eng backup-bw 30000

backup tunnel #2

interface Tunnel2

backup tunnel #3

interface Tunnel3
tunnel mpls traffic-eng backup-bw 40000

If you don't configure a global-pool or a sub-pool, then any pool is assumed.

When using global-pool or sub-pool in order to limit the type of backup-bandwidth (and not
the amount),

then you have to explicitly define as unlimited the backup-bandwidth, like below:

IOS

interface Tunnel1
tunnel mpls traffic-eng backup-bw global-pool unlimited tunnel
mpls traffic-eng backup-bw sub-pool unlimited

IOS-XR

interface tunnel-te1
backup-bw global-pool unlimited backup-bw sub-pool unlimited

If there are two or more backup tunnels with backup-bandwith configured that have sufficient
available backup-bandwith, then the one with the least amount of currently available backup
bandwidth is chosen, in order to keep the largest amount available for other LSPs (main
tunnels) with bigger needs.

If there are two or more backup tunnels with no backup-bandwith configured, then the one
with the least amount of currently used backup bandwidth is chosen, in order to distribute the
LSPs (main tunnels) as evenly as possible. If the LSP (main tunnel) doesn't have any
bandwidth configured, the backup tunnel with the fewest protecting LSPs is chosen.
Generally, the backup-bandwidth is assumed to be unlimited when it's not configured. Is this
case no

bandwidth protection is provided.

239 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

If you want to change the above backup protection preemption algorithm, you can use the
following command on the PLR:

IOS

R2(config)#mpls traffic-eng fast-reroute backup-prot-preempt ?

optimize-bw Reduce bandwidth wastage (default: minimize LSPs

preempted)

Keep in mind that backup tunnels can have their signaled-bandwidth configured, just like any
other tunnel, in order to have the LSRs on the backup path do the appropriate admission
control (in production networks this might not be recommended in order to avoid reservation
of resources for a tunnel rarely used). On the other hand, the backup-bandwidth is used solely
by the PLR (head-end of he backup tunnel) locally. Theoretically, both signaled-bandwidth
and backup-bandwidth should be the same for proper operation.
In general:

signaled-bandwidth on the main tunnel o xxx (global pool is assumed)

o sub-pool xxx

backup-bandwidth on the backup tunnel o xxx (any pool is assumed)

o global-pool xxx o sub-pool xxx

You need to enable RDM for RSVP if you are using sub-pools.

TE auto-bandwidth

TE auto-bandwidth samples the average output rate for each tunnel configured for automatic
bandwidth adjustment and periodically (i.e. once per day) adjusts the tunnel’s signaled-
bandwidth to be the largest sample for the tunnel since the last adjustment.

Auto-bandwidth basically performs the following steps:

 every X interval, traffic over a tunnel is measured

 every Y interval, the largest sample from the above measurement is collected
 if this sample value exceeds a Z threshold, then it's used to set the new tunnel
bandwidth

Configuration Steps


globally
o enable statistics collection & auto-bw adjustments (enabled by default)
o frequency: define the interval between tunnel bw statistics collection (5m by default)

per tunnel
o frequency: define the interval between auto-bw adjustments (24h by default)

240

NTS for CCIE SP Lab by chatasos

IOS

o o o
max-bw: define the max auto-bw allowed (no limit by default)
min-bw: define the min auto-bw allowed (no limit by default) adjustment-threshold: define
the delta threshold over which the new bw is actually signaled/used (10% by default)

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

mpls traffic-eng auto-bw timers frequency 60 !

interface Tunnel0

load-interval 30
tunnel mpls traffic-eng bandwidth 20
tunnel mpls traffic-eng auto-bw frequency 300 adjustment-
threshold 1

max-bw 100 min-bw 1

IOS-XR

mpls traffic-eng
auto-bw collect frequency 1

!
interface tunnel-te0

load-interval 30 signalled-bandwidth 20 auto-bw

bw-limit min 1 max 100 adjustment-threshold 1 application 5

IOS-XR auto-bw intervals are defined in mins, while IOS ones are defined in secs.

It's good practice to have: tunnel load-interval < global sampling frequency < tunnel adjust
frequency.

IOS

R2#sh mpls traffic-eng tunnels ...

Config Parameters:
Bandwidth: 20 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute announce: enabled LockDown: disabled Loadshare: 1

bw-based
auto-bw: (300/155) 7 Bandwidth Requested: 1

Adjustment Threshold: 1%
Samples Missed: 0 Samples Collected: 2
after the auto-bw adjustment interval timer expires, the largest sample (7) is now
requested/used

241 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

R2#sh mpls traffic-eng tunnels ...

Config Parameters:
Bandwidth: 20 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute announce: enabled LockDown: disabled Loadshare: 7

bw-based
auto-bw: (300/283) 0 Bandwidth Requested: 7

Adjustment Threshold: 1%
Samples Missed: 0 Samples Collected: 0

Don't forget to also configure the load-interval on the tunnel interface accordingly. Traffic
samples for tunnels that were down during the sampling period, are ignored.

Ifauto-bwisconfiguredforatunnel,the"tunnel mpls traffic-eng

bandwidth"commandsets only the initial tunnel bandwidth. Setting the initial bandwidth is
not required for auto-bw to work.

The latest requested/signaled bandwidth is automatically saved to the tunnel running config.

In latest software releases you can also set an overflow or underflow threshold in order to
make the bandwidth adjustment earlier than the configured interval (so you don't have to wait
for all the samples to be collected). That way you can set a large auto-bw adjustment
frequency and use these two thresholds in such a way that you can react quickly to traffic
changing conditions.

Auto-Tunnels

3 types:

backup auto-tunnels
o no need to configure manual backup tunnels
o no need to assign backup tunnels to a protected interface

primary one-hop auto-tunnels

o no need to configure tunnels to directly connected neighbors with FRR for protection
mesh-group auto-tunnels
o no need to configure tunnel to all interested PEs with FRR for protection

backup auto-tunnels
It must be configured on the PLR, like normal backup tunnels. After activation, dynamic
backup

NHOP/NNHOP tunnels are created automatically whenever an LSP requests FRR protection.
If there is a static configured backup tunnel for a specific interface, then backup auto-tunnels
won't be created

for this.

242 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

IOS

mpls traffic-eng auto-tunnel backup

IOS-XR (4.0.0)

mpls traffic-eng auto-tunnel backup

Extra options available:

IOS

R3(config)#mpls traffic-eng auto-tunnel backup ?

config
nhop-only
srlg
selection
timers

tunnel-num

Config commands to apply to all backup auto-tunnels

Automatically create n-hop backup tunnels only Shared Risk
Link Groups influence backup tunnel path

Configure timers for backup auto-tunnels

Configure tunnel I/F numbers for backup auto-tunnels

Youcanenable"debug mpls traffic-eng auto-tunnel backup

all"ifyouwanttoseethe actual cli commands used to create the backup auto-tunnels.

IOS

R3#debug mpls traffic-eng auto-tunnel backup all MPLS TE Auto-

Tunnel Backup all debugging is on

TE_AUTO_TUN: backup CLI command: interface tunnel65436

no logging event link-status
ip unnumbered Loopback0

tunnel destination 6.6.6.6 tunnel mode mpls traffic-eng end

TE_AUTO_TUN: CLI command:

ip explicit-path name __dynamic_tunnel65436
index 1 exclude-address 20.3.6.3

TE_AUTO_TUN: backup CLI command:

interface tunnel65436
tunnel mpls traffic-eng path-option 1 exp name
__dynamic_tunnel65436 end

TE_AUTO_TUN: backup CLI command: interface tunnel65437

no logging event link-status

243 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

ip unnumbered Loopback0 tunnel destination 5.5.5.5 tunnel mode

mpls traffic-eng end

TE_AUTO_TUN: CLI command:

ip explicit-path name __dynamic_tunnel65437

index 1 exclude-address 6.6.6.6

TE_AUTO_TUN: backup CLI command:

interface tunnel65437
tunnel mpls traffic-eng path-option 1 exp name
__dynamic_tunnel65437 end

R3#sh mpls traffic-eng tunnels backup R3_t65436

LSP Head, Admin: up, Oper: up

Tun ID: 65436, LSP ID: 1, Source: 3.3.3.3 Destination: 6.6.6.6
Fast Reroute Backup Provided:

Protected i/fs: Fa0/0.36

Protected LSPs/Sub-LSPs: 0, Active: 0
Backup BW: any pool unlimited; inuse: 0 kbps Backup flags: 0x0

R3_t65437
LSP Head, Admin: up, Oper: up
Tun ID: 65437, LSP ID: 1, Source: 3.3.3.3 Destination: 5.5.5.5
Fast Reroute Backup Provided:

Protected i/fs: Fa0/0.36

Protected LSPs/Sub-LSPs: 1, Active: 0
Backup BW: any pool unlimited; inuse: 0 kbps Backup flags: 0x0
primary one-hop auto-tunnels

It must be configured on every router you want to create a TE tunnel to all the TE-enabled
routers that are one hopaway.Eachauto-tunnelhas"autoroute announce"and"fast-
reroute"activatedbydefault, but you can add some extra configuration too.

That way you can create automatically multiple tunnels covering all possible paths in a
network.

IOS

mpls traffic-eng auto-tunnel primary onehop

244 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

IOS-XR

not supported

Extra options available:

IOS

R1(config)#mpls traffic-eng auto-tunnel primary ?

config
onehop
timers
tunnel-num Configure tunnel I/F numbers for primary auto-
tunnels

Config commands to apply to all primary auto-tunnels

Automatically create tunnel to all next-hops Configure timers
for backup auto-tunnels

Youcanenable"debug mpls traffic-eng auto-tunnel primary

all"ifyouwanttoseethe actual cli commands used to create the primary one-hop auto-
tunnels.

IOS
R1#debug mpls traffic-eng auto-tunnel primary all MPLS TE
Auto-Tunnel Primary all debugging is on

TE_AUTO_TUN: Found a new router id 2.2.2.2 off of

FastEthernet0/0 TE_AUTO_TUN: primary CLI command:
interface tunnel65336
no logging event link-status

ip unnumbered Loopback0 tunnel destination 2.2.2.2 tunnel mode

mpls traffic-eng end

TE_AUTO_TUN: primary CLI command: interface tunnel65336

tunnel mpls traffic-eng autoroute announce tunnel mpls
traffic-eng fast-reroute
end

TE_AUTO_TUN: CLI command:

ip explicit-path name __dynamic_tunnel65336

index 1 next-address 10.1.2.1

TE_AUTO_TUN: primary CLI command:

interface tunnel65336
tunnel mpls traffic-eng path-option 1 exp name
__dynamic_tunnel65336 end

TE_AUTO_TUN: Found Down Tunnel65336 to router id 2.2.2.2 out

FastEthernet0/0

245 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

auto-tunnel mesh groups

It must be configured on the PE routers. After activation, it creates a mesh of TE tunnels to

all the PE routers which are either configured for the same mesh-group (assuming OSPF is
used), or their TE Id is matched by an ACL. The address that are used in the ACL must exist
in the TE database in order to have the auto- tunnel created..

IOS

mpls traffic-eng auto-tunnel mesh

!
access-list 1 permit 20.20.20.20 access-list 1 permit
30.30.30.30 !
interface Auto-Template1

ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination access-list 1
tunnel mpls traffic-eng autoroute announce tunnel mpls
traffic-eng path-option 1 dynamic

The interface auto-template is configured like a normal TE tunnel.

You can also use explicit paths, which use the exclude-address keyword.

IOS-XR (4.1.1)

mpls traffic-eng

auto-tunnel mesh group 99

destination-list 1 !

ipv4 prefix-list 1
10 permit 20.20.20.20/32 20 permit 30.30.30.30/32

You cannot configure Inter-Area or Inter-AS tunnels for auto-tunnel mesh groups.

In IOS-XR there is no need to configure a dynamic path-option; it's enabled by default.

IOS

interface Auto-Template1 ip unnumbered Loopback0

You cannot configure a static route to route traffic over auto-tunnel mesh group TE tunnels.
You should use

only the autoroute for tunnel selection.

When using mesh-group numbers (instead of an ACL) to match the PEs, you have to enable
IGP flooding of

mesh information under the IGP of the PEs.

246 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

tunnel mode mpls traffic-eng

tunnel destination mesh-group 99
tunnel mpls traffic-eng autoroute announce tunnel mpls
traffic-eng path-option 1 dynamic

!
router ospf 1

mpls traffic-eng router-id Loopback0

mpls traffic-eng area 0
mpls traffic-eng mesh-group 99 Loopback0 area 0

R2#sh mpls traffic-eng topology | i mg Area mg-id's:

: mg-id 99 1.1.1.1 :

R2#sh mpls traffic-eng auto-tunnel mesh Auto-Template1:

Using mesh-group 99 to clone the following tunnel interfaces:

Destination
-----------

1.1.1.1
Mesh tunnel interface numbers: min 64336 max 65335

IS-IS does not support IGP distribution of mesh group information.You have to use ACLs in
this case.

You can also define manually the min/max tunnel numbers used.

SRLG (Shared Risk Link Groups)

When enabled it allows you to define links that belong to the same group, because they share
a risk (i.e two links using the same fiber path).

The idea is to have backup tunnels avoid using links in the same SRLG as the interfaces they
are protecting. Otherwise, when the protected link fails the backup tunnel will fail too.

Configuration

 assign interfaces to SRLGs

 enable backup auto-tunnels globally (IOS) or per interface (IOS-XR)
  configure backup auto-tunnels to avoid SRLGs (always or if possible)

Interface
---------

Tunnel64336
247 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

IOS

interface X
mpls traffic-eng srlg 1 mpls traffic-eng srlg 2

!
interface Y

mpls traffic-eng srlg 2

mpls traffic-eng srlg 3 !

mpls traffic-eng auto-tunnel backup

mpls traffic-eng auto-tunnel backup srlg exclude force

IOS-XR (4.1.0)

srlg

interface X value 1 value 2

!
interface Y

value 2
value 3 !

mpls traffic-eng

interface X

auto-tunnel backup exclude srlg preferred

You can have multiple SRLG values per interface.

IOS default is "preferred", while IOS-XR default is "force". Only backup auto-tunnels can be
used.

Links

IETF - RFC 4203 IETF - RFC 5307

248 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Inter-Area MPLS TE

Inter-Area MPLS TE Tunnels are not supported by the default configuration. Two solutions:

 per domain: ERO loose-hop expansion

 distributed: Path Computation Element (PCE)

ERO loose-hop expansion

A loosely routed explicit path must be defined for the tunnel LSP that identifies each
ABR the LSP should traverseusingthe"next-address
loose"command.Thehead-endrouterandtheABRsalongthe specified explicit path
expand automatically the loose hops, each one computing the strict path segment to
the next ABR or tunnel destination.

MPLS TE is configured as usually, with the following change:

You have to use loose next-hops on the TE Tunnels towards the ABRs

IOS

interface Tunnel0
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 4.4.4.4
tunnel mpls traffic-eng path-option 1 explicit name EXPPATH
!

ip explicit-path name EXPPATH enable next-address loose

2.2.2.2 next-address loose 3.3.3.3

IOS-XR

interface tunnel-te0
ipv4 unnumbered Loopback0 destination 4.4.4.4
path-option 1 explicit name EXPPATH

!
explicit-path name EXPPATH

index 1 next-address loose ipv4 unicast 2.2.2.2 index 2 next-

address loose ipv4 unicast 3.3.3.3

Youcanuse"debug mpls traffic-eng path"and"debug mpls traffic-eng

tunnels" debugs on the head-end and the ABRs to troubleshoot any issues.

Specifying the tunnel tail-end in a loosely routed path is optional. You need to define only the
ABRs as

next-address loose and each ABR will automatically find the strict next-address for the next
ABR or for the

final destination.
249 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

IOS

R1#debug mpls traffic-eng path ?

<0-65535>
api
dump
errors
lookup
spf
verify

Show debug output for this tunnel only Path calculation API
events
Path calculation detail info
Path calculation errors events

Path calculation lookup events Path calculation SPF events

Path calculation verify events

R1#debug mpls traffic-eng tunnels ?

auto-bw

errors

events fast-reroute labels path-protection reoptimize

signalling state

timers

MPLS Traffic Engineering MPLS Traffic Engineering MPLS Traffic

Engineering MPLS Traffic Engineering MPLS Traffic Engineering
MPLS Traffic Engineering MPLS Traffic Engineering MPLS Traffic
Engineering MPLS Traffic Engineering MPLS Traffic Engineering

tunnel auto-bw tunnel errors

tunnel system events tunnel fast reroute tunnel labels

tunnel path protection tunnel reoptimization tunnel signalling

tunnel state machine tunnel timers
As an alternative for an inter-area tunnel crossing different areas, you could configure a
sequence of intra-area tunnels, each one crossing one of the areas between source and
destination routers, in such a way that the traffic arriving on one tunnel is forwarded into the
next tunnel and so on.

OSPF

 An ABR has visibility into the TE topology of all areas where it's attached to.
 An area 0 router has visibility into the TE topology of area 0 only.
 An non-transit area router has visibility into the TE topology of that area only.

Always keep in mind that first you have to enable MPLS TE for all interested areas.

You can use the following abbreviations when filtering the output in order to quickly
verify the OSPF area & TE topology per router. Just compare the number of nodes
and links on the output vs the ones on the diagram.

IOS

R3#sh mpls traffic-eng top | i TE Id

IGP Id: 1.1.1.1, MPLS TE Id:1.1.1.1 Router Node (ospf 1
area 1) IGP Id: 2.2.2.2, MPLS TE Id:2.2.2.2 Router Node
(ospf 1 area 1) IGP Id: 3.3.3.3, MPLS TE Id:3.3.3.3
Router Node (ospf 1 area 0) IGP Id: 3.3.3.3, MPLS TE
Id:3.3.3.3 Router Node (ospf 1 area 1) IGP Id: 4.4.4.4,
MPLS TE Id:4.4.4.4 Router Node (ospf 1 area 0) IGP Id:
4.4.4.4, MPLS TE Id:4.4.4.4 Router Node (ospf 1 area 1)

250 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

IGP Id: 5.5.5.5, MPLS TE Id:5.5.5.5 Router Node (ospf 1 area
0) IGP Id: 6.6.6.6, MPLS TE Id:6.6.6.6 Router Node (ospf 1
area 0)

R1#sh mpls traffic-eng top | i TE Id|Address

IGP Id: 1.1.1.1, MPLS TE Id:1.1.1.1 Router frag_id 1, Intf

Address:10.1.2.1 IGP Id: 2.2.2.2, MPLS TE Id:2.2.2.2 Router
frag_id 9, Intf Address:20.2.3.2

frag_id 10, Intf Address:20.2.4.2

frag_id 2, Intf Address:10.1.2.2 IGP Id: 3.3.3.3, MPLS TE

Id:3.3.3.3 Router frag_id 5, Intf Address:20.2.3.3 IGP Id:
4.4.4.4, MPLS TE Id:4.4.4.4 Router frag_id 5, Intf
Address:20.2.4.4

ISIS

Node (ospf 1 area 1) Node (ospf 1 area 1)

Node (ospf 1 area 1) Node (ospf 1 area 1)

In case of ISIS & MPLS TE, the L1/L2 router is considered as the ABR.

 A L1 router has visibility into the TE topology of L1 only

 A L2 router has visibility into the TE topology of L2 only
 A L1/L2 router has visibility into the TE topology of both L1/L2

Always keep in mind that first you have to enable MPLS TE for all interested levels.
 You can use the following abbreviations when filtering the output in order to quickly
verify the ISIS L1/L2 and TE topology per router. Just compare the number of nodes
and links on the output vs the ones on the diagram.

IOS

R5#sh mpls traffic-eng top | i TE Id

IGP Id: 0000.0000.0002.00, MPLS TE Id:10.0.0.2 Router
Node (isis level- 1)
IGP Id: 0000.0000.0005.00, MPLS TE Id:10.0.0.5 Router
Node (isis level- 1)
IGP Id: 0000.0000.0005.00, MPLS TE Id:10.0.0.5 Router
Node (isis level- 2)
IGP Id: 0000.0000.0019.00, MPLS TE Id:10.0.0.19 Router
Node (isis level-2)
IGP Id: 0000.0000.0020.00, MPLS TE Id:10.0.0.20 Router
Node (isis level-1)
IGP Id: 0000.0000.0020.00, MPLS TE Id:10.0.0.20 Router
Node (isis level-2)

R5#sh mpls traffic-eng top | i TE Id|Address

IGP Id: 0000.0000.0002.00, MPLS TE Id:10.0.0.2 Router
Node (isis level- 1)

frag_id 0, Intf Address:10.0.220.2

251

NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

frag_id 0, Intf Address:10.0.25.2

IGP Id: 0000.0000.0005.00, MPLS TE Id:10.0.0.5 Router Node
(isis 1)

frag_id 0, Intf Address:10.0.25.5

IGP Id: 0000.0000.0005.00, MPLS TE Id:10.0.0.5 Router Node
(isis 2)

frag_id 0, Intf Address:10.0.195.5

frag_id 0, Intf Address:10.0.205.5

IGP Id: 0000.0000.0019.00, MPLS TE Id:10.0.0.19 Router Node
(isis level-2)
frag_id 0, Intf Address:10.0.195.19

frag_id 0, Intf Address:10.19.20.19, Nbr Intf

Address:10.19.20.20

IGP Id: 0000.0000.0020.00, MPLS TE Id:10.0.0.20 Router Node

(isis level-1)

frag_id 0, Intf Address:10.0.220.20

IGP Id: 0000.0000.0020.00, MPLS TE Id:10.0.0.20 Router Node
(isis level-2)

frag_id 0, Intf Address:10.0.205.20

frag_id 0, Intf Address:10.19.20.20, Nbr Intf

Address:10.19.20.19

IOS-XR

R2#sh mpls traffic-eng topology | i TE Id

IGP Id: 0000.0000.0002.00, MPLS TE Id:10.0.0.2 Router Node
(isis 1)
IGP Id: 0000.0000.0005.00, MPLS TE Id:10.0.0.5 Router Node
(isis 1)
IGP Id: 0000.0000.0020.00, MPLS TE Id:10.0.0.20 Router Node
(isis level-1)

R2#sh mpls traffic-eng topology | i TE Id|Address

IGP Id: 0000.0000.0002.00, MPLS TE Id:10.0.0.2 Router Node
(isis 1)

frag_id 0, Intf Address:10.0.220.2

frag_id 0, Intf Address:10.0.25.2

IGP Id: 0000.0000.0005.00, MPLS TE Id:10.0.0.5 Router Node
(isis 1)

frag_id 0, Intf Address:10.0.25.5

IGP Id: 0000.0000.0020.00, MPLS TE Id:10.0.0.20 Router Node
(isis level-1)

frag_id 0, Intf Address:10.0.220.20, Nbr Intf

Address:10.0.220.2

Links

level-
level-
level-
level-
level-

level-

IETF- RFC 4105

252 NTS for CCIE SP Lab by chatasos
chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Inter-AS MPLS TE

Inter-AS MPLS TE Tunnels are not supported by the default configuration. A loosely routed
explicit path must be defined for the tunnel LSP that identifies each ASBR the LSP should
traverse using the "next- address loose"command.Thehead-
endrouterandtheASBRsalongthespecifiedexplicitpathexpand automatically the loose hops,
each one computing the strict path segment to the next ASBR or tunnel destination.

MPLS TE is configured as usually, with the following two changes:

 You have to use loose next-hops on the TE Tunnels

 You have to define some manual TE parameters on the ASBRs for their neighbors
 ASBR Forced Link Flooding is the process that allows links to be installed (as point-
to-point) into the TE database, although no IGP is running on them. In order to
activate that functionality you just need to configure a link as passive for MPLS TE
and provide the neighbor's TE-Id and ip address.

OSPF
o uses opaque LSAs (Type 10) containing a single link TLV o only information about the
link that has changed is flooded

IS-IS
o uses Type 22 TLVs

o information about all links on a node is flooded

Head-end

IOS

interface Tunnel0
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 9.9.9.9
tunnel mpls traffic-eng path-option 1 explicit name R4-R5-
EXPPATH

!
ip explicit-path name R4-R5-EXPPATH enable

next-address loose R4 next-address loose R5

IOS-XR

interface tunnel-te0
ipv4 unnumbered Loopback0
destination 9.9.9.9
path-option 1 explicit name R4-R5-EXPPATH

There is no need for full communication (i.e. eBGP, static) to exist between the AS for an
Inter-AS LSP to

become functional, unless a backup LSP is required too.

253 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

explicit-path name R4-R5-EXPPATH

index 1 next-address loose ipv4 unicast R4 index 2 next-
address loose ipv4 unicast R%

ASBR #1

IOS

interface FastEthernet0/0
ip address 10.4.5.4 255.255.255.0
mpls traffic-eng tunnels
mpls traffic-eng passive-interface nbr-te-id 5.5.5.5 nbr-if-
addr

10.4.5.5
ip rsvp bandwidth

IOS-XR

PCE or verbatim option required

ASBR#2

IOS

interface FastEthernet0/0
ip address 10.4.5.5 255.255.255.0
mpls traffic-eng tunnels
mpls traffic-eng passive-interface nbr-te-id 4.4.4.4 nbr-if-
addr

10.4.5.4
ip rsvp bandwidth

IOS-XR

PCE or verbatim option required

You cannot configure IGP enabled interfaces as MPLS-TE passive interfaces.

You can configure multiple passive neighbors under the same interface. If there are multiple
neighbors and the

AS use different IGPs, then you need to also use the "nbr-igp-id" keyword.
The TE topology should include all MPLS TE enabled interfaces and for the inter-as links the
nbr-te-id should

be shown as "Nbr Intf Address", like in all p2p links.

IOS

R1#sh mpls traffic-eng topology | i Address ...

Don'tforgettoenable"mpls traffic-eng tunnels"and"ip rsvp

bandwidth"undertheinter-

as interfaces, like in intra-as MPLS TE scenarios.

frag_id 0, Intf Address:10.2.4.4

254

NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

frag_id 0, Intf Address:10.3.4.4

frag_id 0, Intf Address:10.4.5.4, Nbr Intf Address:5.5.5.5

The IGP metrics are set to max (shown as "invalid" for ISIS and "MaxLinkMetric" for
OSPF), because these routes aren't into RIB, but only into MPLS TE.

IOS sets the TE metric the same as the IGP metric, IOS-XR doesn't.

Configure a TE metric if you want to enable reoptimization for this tunnel.

IOS

R9#sh mpls traffic-eng top | i Addr|metric ...

frag_id 7, Intf Address:10.5.6.6

TE metric:1, IGP metric:1, attribute flags:0x0
frag_id 6, Intf Address:10.4.5.5, Nbr Intf Address:4.4.4.4 TE
metric:invalid, IGP metric:invalid, attribute flags:0x0

R1#sh mpls traffic-eng top | i Addr|metric ...

frag_id 0, Intf Address:10.3.4.4

TE metric:10, IGP metric:10, attribute flags:0x0
frag_id 0, Intf Address:10.4.5.4, Nbr Intf Address:5.5.5.5 TE
metric:MaxLinkMetric, IGP metric:MaxLinkMetric, attribute

flags:0x0

Use"sh ip ospf database opaque-area"and"sh isis database

verbose"toviewthe IGP details about the MPLS TE passive links.

You can also use the following commands on the ASBRs to verify the inter-as link.

IOS

R4#show mpls traffic-eng link-management igp-neighbors ...

Link ID:: Fa0/0.45
Neighbor ID: 5-5-5-5-0-0-0 (force, non-igp IP: 20.4.5.5) up,
Sources: Passive

...
Link ID:: Fa0/0.24

Neighbor ID: 0000.0000.0004.01 (area: isis level-2, IP:

0.0.0.0) up, Sources: IGP

R4#show mpls traffic-eng link-management advertisements | i

Address

Link IP Address:
Link IP Address:
20.3.4.4
20.4.5.4

255

NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Link IP Address: 20.4.6.4 Link IP Address: 20.2.4.4

When viewing the Explicit Route (under the RSVP Path information) of an Inter-AS TE
tunnel, loose hops that belong to other AS will be shown with a "*" next to them.

IOS

R1#sh mpls traffic-eng tunnels ...

RSVP Path Info:

My Address: 10.1.2.1
Explicit Route: 10.1.2.2 20.2.3.2 20.2.3.3 3.3.3.3

6.6.6.6*

FRR & backup tunnels

Local protection within a domain operates like intra-domain in the Inter-AS LSPs.

When using FRR on the primary Inter-AS tunnel and an Inter-AS backup tunnel for ASBR
link/node protection:


Whenyou'rehavingipconnectivityissues,itmightbegoodpracticetoenable"debug ip
icmp"and watch out for "host unreachable" messages.

Links



The explicit path of the backup tunnel must also use loose hops

The backup tunnel destination must be included in the RRO of the primary tunnel

You need to somehow (i.e. eBGP, static) create a route on the MP router (and all other intra-
as

routers towards the ASBR) for the backup tunnel's egress ip address, so the RESV messages
can be

sent from the MP (tail-end of the backup tunnel in one domain) to the PLR (head-end of the
backup

tunnel in the other domain)

IETF - RFC 4216 IETF - RFC 4920 IETF - RFC 4561
256 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

MPLS DiffServ-TE

DiffServ-TE allows bandwidth reservations on a per-class basis. 8 Class Types: CT0 - CT7
(CT0 and CT1 are currently used)

These 8 CTs can be combined with the 8 setup/hold priorities creating 64 possible
combinations (called TE classes), from where only 8 are actually used (TE0 - TE7). All
routers in a network must have a consistent configuration of all the TE classes.

IOS
mpls traffic-eng ds-te te-classes te-class 0 class-type 0
priority 0 te-class 1 class-type 1 priority 7

IOS-XR

mpls traffic-eng ds-te te-classes

te-class 0 class-type 0 priority 0 te-class 1 class-type 1

priority 7

CT0 is usually used for best effort or pre-DE-TE LSPs and is implicitly signaled CT1 is
usually used for special classes like voice and video and is explicitly signaled

Usually CTs map to scheduler queues for the appropriate QoS actions.

CSPF is enhanced to handle per-CT reservation requirements

IGP is enhanced to carry per-CT available bandwidth at different priorities
RSVP is enhanced to carry a new Class Type Object (CTO) in the PATH message

Bandwidth Constraint Models

BC (Bandwidth Constraint) = the percentage of a link's bandwidth that a CT can use

BC0 = global pool (for best-effort & DiffServ traffic) BC1 = sub-pool (for strict bandwidth
guarantee traffic)

The BC model determines the available bandwidth for each CT at each priority. Two BC
models:

MAM (Maximum Allocation Model)

o o o
RFC 4125
the link bandwidth is divided among the different CTs it completely isolates the different CTs

257

NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

o different priorities on different CTs do not have any effect

o bandwidth is wasted due to not being able to share unused bandwidth between CTs RDM
(Russian Dolls Model)

o RFC 4127
o CTs can share bandwidth on a link
o no isolation between CTs
o preemption (using priorities) is required to guarantee bandwidth to a CT o bandwidth is
utilized more efficiently between CTs

RDM is the default BC model, after enabling IETF DS-TE.

IOS

mpls traffic-eng ds-te mode ietf

IOS-XR

mpls traffic-eng ds-te mode ietf

The same mode should be used in all MPLS-TE routers.

IOS

R3#sh mpls traffic-eng top | i BC BC Model Id: RDM

BC Model Id: RDM

BC0 (max_reservable): 75000 (kbps)
BC0 (max_reservable_bw_global): 0 (kbps) BC1
(max_reservable_bw_sub): 0 (kbps)

IOS-XR

GSR#sh mpls traffic top | i BC My_BC_Model_Type: RDM

BC Model ID:RDM
BC0:50000 (kbps) BC1:0 (kbps) BC Model ID:RDM
BC0:50000 (kbps) BC1:0 (kbps) BC Model ID:RDM
BC0:50000 (kbps) BC1:0 (kbps)

Configuration Steps



sub-pool (BC1) tunnel

o choose a specific PHB for classifying the strict guarantee traffic
o limit the traffic before it enters the tunnel in order to avoid oversubscription
o mark the traffic with the right EXP while entering the tunnel
o map the EXP into the appropriate queue at each outgoing interface of every tunnel hop o
reserve the right percentage of the total sub-pool bandwidth on each outgoing link

global pool (BC0) tunnel



258 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

o o o o

choose a specific PHB for each class

mark each class with the right EXP while entering the tunnel
map each EXP into the appropriate queue at each outgoing interface of every tunnel hop
reserve the right percentage of the total global pool bandwidth on each outgoing link

IOS

interface Tunnel1
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 6.6.6.6
tunnel mpls traffic-eng priority 0 0
tunnel mpls traffic-eng bandwidth sub-pool 444
tunnel mpls traffic-eng path-option 1 explicit name R4-R5

!
interface FastEthernet0/0

mpls traffic-eng tunnels

ip rsvp bandwidth 99999 sub-pool 9999

After switching to IETF DS-TE the above configuration becomes:

IOS

interface Tunnel1
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 6.6.6.6
tunnel mpls traffic-eng priority 0 0
tunnel mpls traffic-eng bandwidth 444 class-type 1
tunnel mpls traffic-eng path-option 1 explicit name R4-R5

!
interface FastEthernet0/0

mpls traffic-eng tunnels

ip rsvp bandwidth rdm bc0 99999 bc1 9999

IOS-XR supports either sub-pool or class-type configuration by default.

Links


IETF - RFC 3564 IETF - RFC 4124 IETF - RFC 3270
259 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

P2MP LSPs

 One ingress router

 Many egress routers
 Replication (one=>many) happens at branch routers (ingress router can be a branch
router too)
 The path of the P2MP LSP is determined by the branch routers
 All sub-LSPs of the same P2MP LSP employ the same constraints/policies
  Traffic is unidirectional, like in P2P LSPs

Two options in control plane:

LDP
o no TE support

o LSP is initiated by the egress routers

o Egress routers advertise each one a label for the P2MP FEC towards the branch router
o Branch routers advertise a single label for the P2MP FEC (for multiple received labels
from

egress routers) toward the ingress router

o Ingress routers need to keep state only for the directly connected routers

RSVP
o TE support

o LSP is initiated by the ingress router

o Sub-LSPs (like normal LSPs) are created from the ingress router towards each egress
router
o Each sub-LSP has its own PATH/RESV messages, which contain the P2MP Session
Object (so

that all intermediate routers know the parent LSP where these sub-LSPs belong to)
o Ingress router sends a PATH message (hop-by-hop) to each egress router (towards the
branch

router)
o Branch routers send multiple PATH messages (one for each sub-LSP) towards the multiple

egress routers
o Egress routers receive the PATH messages and each one sends a RESV message towards
the

branch router
o Branch routers receive multiple RESV messages (one for each sub-LSP) from each egress

router (of a different branch), each one with a different label

o Branch routers send multiple RESV messages (one for each sub-LSP) towards the ingress

router, each one with the same label (since they belong to the same parent P2MP LSP).
o Ingress router receives multiple RESV messages with the same label from each branch
router o Ingress routers need to keep state for all egress routers (due to sub-LSPs)

P2MP TE

Limitations
  Inter-area and inter-as topologies are not supported, only intra-as
 Node and path protection are not supported, only link protection
 PIM Sparse is not supported, only SSM
 Many OAM features are not supported
 Multiple path-options per destination are not supported, one one path-option per
destination
 PHP is not supported on the tail-end, explicit-null or a normal label must be used
 Only one backup auto-tunnel is created, to be used for link-protection

260 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Multicast

 Head-end router and tail-end routers exchange PIM messages with the locally
attached CEs
 MPLS core doesn't need to run PIM
 PIM doesn't need to be enabled across the MPLS TE tunnel

You can use dynamic paths or explicit paths.

The following apply to all sub-LSPs of the same P2MP LSP:

 andwidth parameters
 hold/setup priorities
 administrative weight
 attributes/affinity
Because a sub-LSP cannot be represented as a regular interface on the tail-end router,
a special LSP virtual interface (LSPVIF) is automatically created. The LSPVIF
represents the originating interface for all IP multicast traffic arriving to the P2MP TE
tail-end router. This LSPVIF interface is used for the RPF check.

MPLS-TE should be configured and working between all routers being involved in
the P2MP LSPs.

head-end (IOS)
ip multicast-routing !
ip pim ssm default
!
interface Tunnel0

ip unnumbered Loopback0

ip pim passive
ip igmp static-group 232.20.20.20 source 7.7.7.7
ip igmp static-group 232.19.19.19 source 7.7.7.7
ip igmp static-group 232.8.8.8 source 7.7.7.7
ip igmp static-group 232.2.2.2 source 7.7.7.7
tunnel mode mpls traffic-eng point-to-multipoint
tunnel destination list mpls traffic-eng name TAIL-END-
ACL

!
mpls traffic-eng destination list name TAIL-END-ACL

ip 2.2.2.2 path-option 1 dynamic

ip 19.19.19.19 path-option 1 dynamic ip 20.20.20.20 path-
option 1 dynamic

For every multicast group you'll need a static igmp under the TE tunnel.

Path-option per sub-LSP can be either dynamic or explicit.

If you configure expicit paths that lead to multiple sub-LSPs

entering a middle router through different interfaces but exiting through a common interface,
then the sub-

LSP won't be established (remerge event).

261 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

mid-point (IOS)
just normal MPLE-TE config, no multicast required support of signaling extensions is
required

tail-end (IOS)
ip multicast-routing
ip multicast mpls traffic-eng
!
ip pim ssm default
!
ip mroute 7.7.7.7 255.255.255.255 1.1.1.1

In IOS-XR, the interface "tunnel-mte" is used for P2MP LSPs.

head-end (IOS-XR) multicast-routing

address-family ipv4 interface tunnel-mte0

enable

router igmp
interface tunnel-mte0

static-group 232.2.2.2 7.7.7.7 static-group 232.8.8.8 7.7.7.7

static-group 232.19.19.19 7.7.7.7 static-group 232.20.20.20
7.7.7.7

!
interface tunnel-mte0

ipv4 unnumbered Loopback0 destination 1.1.1.1

path-option 1 dynamic !

destination 2.2.2.2 path-option 1 dynamic

!
destination 19.19.19.19

path-option 1 dynamic

mid-point (IOS-XR)
just normal MPLE-TE config, no multicast required support of signaling extensions is
required

In order to avoid failing on the RPF check on the tail-end router, you must configure a static
mroute for the

multicast source pointing to the head-end router.

262 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

tail-end (IOS-XR) multicast-routing

address-family ipv4

core-tree-protocol rsvp-te static-rpf 7.7.7.7 32 mpls 1.1.1.1

IOS-XR 4.2 is required for P2MP LSPs. IOS-XR on C12k doesn't support P2MP LSPs.

IOS-XR doesn't support pings on loopbacks belonging to VRFs under a mVPN topology. Use
a physical interface instead.

"multicast-intact" might be required if P2MP and P2P LSPs are created between two
nodes.

It is assumed that all routers outside the MPLS-TE core are using multicast as usual. So the
head-end is having a normal PIM connectivity to the source and the tail-ends are having
normal PIM connectivity to the receivers.

Verification

Keep all possible loggings enabled in order to aid in troubleshooting.

IOS

mpls traffic-eng logging lsp path-errors

mpls traffic-eng logging lsp reservation-errors mpls traffic-
eng logging lsp preemption
mpls traffic-eng logging lsp setups
mpls traffic-eng logging lsp teardowns
mpls traffic-eng logging tunnel path change

When the tail-end router creates the LSPVIF interface, you'll get the following log:

%MPLS_TE-5-LSP: Sub-LSP 1.1.1.1[1:3]->2.2.2.2_0: UP

%LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif0,
changed state to up

head-end (IOS)
R1#sh mpls traffic-eng tunnels

P2P TUNNELS/LSPs: P2MP TUNNELS:

ForP2MPTEFRRprotection,the"ip routing protocol purge

interface"commandis
recommended on every penultimate hop router. Otherwise, the traffic can be lost for a few
seconds during a

FRR cutover event.

263 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Tunnel0 (p2mp), Admin: up, Oper: up Name: R1_t0

Tunnel0 Destinations Information:

Destination
2.2.2.2
19.19.19.19
20.20.20.20
State SLSP UpTime
Up 01:47:12
Up 01:47:28
Up 01:48:35

Summary: Destinations: 3 [Up: 3, Proceeding: 0, Down: 0 ]

[destination list name: TAIL-TE-ACL]

History:
Tunnel:
Time since created: 1 hours, 51 minutes Time since path
change: 1 hours, 48 minutes Number of LSP IDs (Tun_Instances)
used: 1

Current LSP: [ID: 1]

Uptime: 1 hours, 48 minutes

Tunnel0 LSP Information:

Configured LSP
Bandwidth: 0
0x0/0xFFFF
Metric Type:

Parameters:
kbps (Global) Priority: 7 7 Affinity:

TE (default)

Session Information
Source: 1.1.1.1, TunID: 0

LSPs
ID: 1 (Current), Path-Set ID: 0xA2000001

Sub-LSPs: 3, Up: 3, Proceeding: 0, Down: 0 Total LSPs: 1

P2MP SUB-LSPS:

LSP: Source: 1.1.1.1, TunID: 0, LSPID: 1 P2MP ID: 0, Subgroup

Originator: 1.1.1.1 Name: R1_t0
Bandwidth: 0, Global Pool

Sub-LSP to 20.20.20.20, P2MP Subgroup ID: 1, Role: head Path-

Set ID: 0xA2000001
OutLabel : FastEthernet0/0.13, 29
Next Hop : 12.1.3.3

Explicit Route: 12.1.3.3 12.3.4.4 12.4.20.20 20.20.20.20

Record Route (Path): NONE
Record Route (Resv): NONE

264 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Sub-LSP to 19.19.19.19, P2MP Subgroup ID: 2, Role: head Path-
Set ID: 0xA2000001
OutLabel : FastEthernet0/0.13, 29
Next Hop : 12.1.3.3

Explicit Route: 12.1.3.3 12.3.5.5 12.5.6.6 12.6.19.19

19.19.19.19

Record Route (Path): NONE Record Route (Resv): NONE

Sub-LSP to 2.2.2.2, P2MP Subgroup ID: 3, Role: head Path-Set

ID: 0xA2000001
OutLabel : FastEthernet0/0.13, 29
Next Hop : 12.1.3.3

Explicit Route: 12.1.3.3 12.3.5.5 12.5.6.6 12.2.6.2 2.2.2.2

Record Route (Path): NONE Record Route (Resv): NONE

head-end (IOS)
R1#show mpls traffic-eng tunnels brief Signalling Summary:

LSP Tunnels Process: Passive LSP Listener: RSVP Process:

Forwarding:

Periodic reoptimization: seconds

Periodic FRR Promotion:

Periodic auto-bw collection: seconds

running
running
running
enabled
every 3600 seconds, next in 3463

P2P TUNNELS/LSPs:
Displayed 0 (of 0) heads, 0 (of 0) midpoints, 0 (of 0) tails

P2MP TUNNELS:

DEST INTERFACE STATE/PROT UP/CFG

Tunnel0 up/up 3/3 Displayed 1 (of 1) P2MP heads

P2MP SUB-LSPS:
SOURCE TUNID LSPID DESTINATION 1.1.1.1 0 1 20.20.20.20
Fa0/0.13
1.1.1.1 0 1 19.19.19.19 Fa0/0.13
1.1.1.1 0 1
Fa0/0.13

2.2.2.2

Not Running
every 300 seconds, next in 163

CURRENT

TUNID 0

LSPID 1

SUBID STATE UP IF 1 Up head

2 Up head 3 Up head

DOWN IF

265

NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Displayed 3 P2MP sub-LSPs:

3 (of 3) heads, 0 (of 0) midpoints, 0 (of 0) tails

head-end (IOS)
R1#show mpls traffic-eng forwarding path-set brief Sub-LSP
Identifier
src_lspid[subid]->dst_tunid
PSID
---------------------------
-
1.1.1.1_1[1]->20.20.20.20_0
A2000001
1.1.1.1_1[2]->19.19.19.19_0
A2000001
1.1.1.1_1[3]->2.2.2.2_0
A2000001

InLabel Next Hop I/F ------- ------------- ------ --- none

12.1.3.3 Fa0/0. none 12.1.3.3 Fa0/0. none 12.1.3.3 Fa0/0.
head-end (IOS)
R1#show mpls traffic-eng forwarding path-set detail

LSP: Source: 1.1.1.1, TunID: 0, LSPID: 1 Destination:

20.20.20.20, P2MP Subgroup ID: 1

Path Set ID: 0xA200000

OutLabel : FastEthernet0/0.13, 29 Next Hop : 12.1.3.3

LSP: Source: 1.1.1.1, TunID: 0, LSPID: 1 Destination:

19.19.19.19, P2MP Subgroup ID: 2

Path Set ID: 0xA200000

OutLabel : FastEthernet0/0.13, 29 Next Hop : 12.1.3.3

LSP: Source: 1.1.1.1, TunID: 0, LSPID: 1 Destination: 2.2.2.2,

P2MP Subgroup ID: 3

Path Set ID: 0xA200000

OutLabel : FastEthernet0/0.13, 29 Next Hop : 12.1.3.3

The same commands can also be used on all the intermediate routers.

head-end (IOS)
R1#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected,

L - Local, P - Pruned, R - RP-bit set, F - Register flag,

266 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

T - SPT-bit set, J - Join SPT, M - MSDP created entry, E -

Extranet,

X - Proxy Join Timer Running, A - Candidate for MSDP

Advertisement,

U - URD, I - Received Source Specific Host Report,

Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group, V -
RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert
winner Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(7.7.7.7, 232.20.20.20), 01:03:22/stopped, flags: sTI Incoming

interface: Serial2/0.100, RPF nbr 192.168.78.7 Outgoing
interface list:

Tunnel0, Forward/Sparse-Dense, 01:03:22/00:02:59

(7.7.7.7, 232.2.2.2), 01:17:17/stopped, flags: sTI Incoming

interface: Serial2/0.100, RPF nbr 192.168.78.7 Outgoing
interface list:

Tunnel0, Forward/Sparse-Dense, 01:17:17/00:02:59

(7.7.7.7, 232.19.19.19), 01:17:11/stopped, flags: sTI Incoming

interface: Serial2/0.100, RPF nbr 192.168.78.7 Outgoing
interface list:

Tunnel0, Forward/Sparse-Dense, 01:17:11/00:02:59

(7.7.7.7, 232.8.8.8), 01:17:27/stopped, flags: sTI Incoming

interface: Serial2/0.100, RPF nbr 192.168.78.7 Outgoing
interface list:

Tunnel0, Forward/Sparse-Dense, 01:17:27/00:02:59

mid-point (IOS) R3#sh mpls Local

23

forwarding-table | i 1.1.1.1|Prefix

Outgoing Prefix

Pop Label 1.1.1.1/32

Bytes Label
41241
2684
2684
Outgoing
Fa0/0.13
Fa0/0.34
Fa0/0.35
Next Hop
12.1.3.1
12.3.4.4
12.3.5.5
29 29 1.1.1.1 0 [1] 16 1.1.1.1 0 [1]

On every mid-point router you should see more than one label for the same TE LSP, each one
pointing to a

different outgoing interface.

mid-point (IOS) R3#sh mpls

traffic-eng tunnels

P2P TUNNELS/LSPs: P2MP TUNNELS:

267

NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

P2MP SUB-LSPS:

LSP: Source: 1.1.1.1, TunID: 0, LSPID: 1 P2MP ID: 0, Subgroup

Originator: 1.1.1.1 Name: R1_t0
Bandwidth: 0, Global Pool

Sub-LSP to 20.20.20.20, P2MP Subgroup ID: 1, Role: midpoint

Path-Set ID: 0x84000001
InLabel : FastEthernet0/0.13, 29
Prev Hop : 12.1.3.1

OutLabel : FastEthernet0/0.34, 29
Next Hop : 12.3.4.4
Explicit Route: 12.3.4.4 12.4.20.20 20.20.20.20 Record Route
(Path): NONE
Record Route (Resv): NONE

Sub-LSP to 19.19.19.19, P2MP Subgroup ID: 2, Role: midpoint

Path-Set ID: 0x84000001
InLabel : FastEthernet0/0.13, 29
Prev Hop : 12.1.3.1

OutLabel : FastEthernet0/0.35, 16
Next Hop : 12.3.5.5
Explicit Route: 12.3.5.5 12.5.6.6 12.6.19.19 19.19.19.19
Record Route (Path): NONE
Record Route (Resv): NONE

Sub-LSP to 2.2.2.2, P2MP Subgroup ID: 3, Role: midpoint Path-

Set ID: 0x84000001
InLabel : FastEthernet0/0.13, 29
Prev Hop : 12.1.3.1

OutLabel : FastEthernet0/0.35, 16

Next Hop : 12.3.5.5

Explicit Route: 12.3.5.5 12.5.6.6 12.2.6.2 2.2.2.2 Record
Route (Path): NONE
Record Route (Resv): NONE

Sub-LSPs following the same branch (egress interface) will use the same label.

tail-end (IOS)
R2#sh ip mroute
IP Multicast Routing Table

Flags: D -
Connected,
L -
T -

Dense, S - Sparse, B - Bidir Group, s - SSM Group, C -

Local, P - Pruned, R - RP-bit set, F - Register flag, SPT-bit

set, J - Join SPT, M - MSDP created entry, E -

Proxy Join Timer Running, A - Candidate for MSDP

Advertisement,

Extranet, X -

268 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

U - URD, I - Received Source Specific Host Report,

Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group, V -
RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert
winner Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(7.7.7.7, 232.2.2.2), 00:28:39/stopped, flags: sLTI

Incoming interface: Lspvif0, RPF nbr 1.1.1.1, Mroute

Outgoing interface list:

FastEthernet1/0, Forward/Sparse-Dense, 00:28:39/00:01:20

tail-end (IOS)
R2#sh mpls traffic-eng tunnels

P2P TUNNELS/LSPs: P2MP TUNNELS: P2MP SUB-LSPS:

LSP: Source: 1.1.1.1, TunID: 0, LSPID: 1 P2MP ID: 0, Subgroup

Originator: 1.1.1.1 Name: R1_t0
Bandwidth: 0, Global Pool

Sub-LSP to 2.2.2.2, P2MP Subgroup ID: 3, Role: tail Path-Set

ID: 0x40000001
InLabel : FastEthernet0/0.26, 33
Prev Hop : 12.2.6.6

OutLabel : -
Explicit Route: NONE
Record Route (Path): NONE Record Route (Resv): NONE

Links



IETF - RFC 4461 IETF - RFC 4875 IETF - RFC 6388

269 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Multicast
PIM-DM (Protocol Independent Multicast- Dense Mode) is defined in RFC 3973. PIM-SM
(PIM - Sparse Mode) is defined in RFC 4601.
PIM-SSM (PIM - Source Specific Multicast) is defined in RFC 4607.
BSR (BootStrap Router) for PIM is defined in RFC 5059.

Multicast Ranges

Multicast range:

 224.0.0.0/8
 FF00::/8

Important ranges (IANA):

 Link-local range (TTL=1)

o 224.0.0.0/24

o FFx2::/16

 SSM range:

o 232.0.0.0/8

o FF3x::/32 (FF3x::8000:0000 - FF3x::FFFF:FFFF)

 GLOP range: 233.0.0.0/8

 Admin-scope range: 239.0.0.0/8
Link-local addresses are not constrained by IGMP snooping. The same also applies to
x.0.0.x or x.128.0.x

(due to 32:1 mcast=>eth mapping).

GLOP range

GLOP addressing is defined in RFC 3180.

Every 16bit ASN has its own GLOP 233.X.Y.0/24 range.
i.e. for AS 12345, one hex=>dec and two dec=>hex conversions need to be made.

12345 => 0x3039

0x30 => 48 (X)
0x39 => 57 (Y)

AS 12345 = > 233.48.57.0/24

Organizations with a 32-bit ASN may apply for space in AD-HOC Block III
(233.252.0.0 - 233.255.255.255) also known as Extended GLOP (EGLOP), or
consider using IPv6 multicast addresses.
270 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Multicast Routing Protocols

Main functionalities:

 setup multicast forwarding state

 exchange information about the multicast forwarding state Protocols

 DVMRP
 PIM-DM
 PIM-SM

Expect to see only PIM-SM being used in most networks.

IOS

ip multicast-routing

IOS-XR

multicast-routing

Enabling multicast-routing on an interface in IOS-XR will enable PIM and IGMP

automatically. There is no needtoconfigurethe"router
pim"command(unlesssomethingextraisrequired,likeMDTorRP),since the PIM mode
it's automatically determined by the group range.

IOS-XR
GSR#sh pim group-map
Fri Jun 9 06:11:08.463 UTC

IP PIM Group Mapping Table

(* indicates group mappings being used) (+ indicates BSR group
mappings active in

MRIB)

RP address

0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0

Group Range

224.0.1.39/32* 224.0.1.40/32* 224.0.0.0/24* 232.0.0.0/8*

224.0.0.0/4* Null,0.0.0.0

Proto Client

DM perm
DM perm
NO perm
SSM config
SM static

Groups

0 1 0 1 0

Info

RPF:

NTS for CCIE SP Lab by chatasos

Each multicast group can be one of sparse, dense, bidir, ssm. Each interface can be many
modes, each one

depending on the egress multicast group.

In IOS-XR, the router itself is also listed as a pim neighbor with a "*". 271
chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

PIM-SM RP

Group-to-RP mappings can be created using:

 Static group-to-RP mapping

 Auto-RP

o uses dense-mode (configure "sparse-dense-mode" or "sparse-mode" & "ip pim

auto-rp listener")

o uses 224.0.1.39 for RP announcements (from RP to MA)

o uses 224.0.1.40 for MA announcements (from MA to all PIM routers)
o the priority of each RP cannot be defined (the RP with the higher ip address wins)
o the interval/scope of Auto-RP announcements can be defined
o use "ip multicast boundary ACL in/out filter-autorp" to filter Auto-
RP

announcements entering/leaving your network PIM BSR (bootstrap router)

o uses sparse-mode (configure "no ip pim dm-fallback" in dense environments) o

uses 224.0.0.13 for BSR announcements (from BSR to all PIM routers)
o unicast for RP announcements (from RP to BSR router)
o the priority of each RP can be defined

o the interval/scope of BSR announcements cannot be defined

o use "ip pim bsr-border" to filter BSR announcements from entering/leaving your

network

On hub-n-spoke networks, when auto-rp announcements must pass between the spokes, you
cannot use nbma- mode, because this works only in sparse mode (and announcements are in
dense). You have to use BSR or create a pim-enabled tunnel between the spokes.

Static RP and BSR are the most common ways to configure a Group-to-RP mapping. Static
RP

IOS

interface Loopback0 ip pim sparse-mode

!
ip pim rp-address 1.1.1.1
IOS-XR

router pim

address-family ipv4 rp-address 1.1.1.1 interface Loopback0

enable

For PIM-SM to work properly, all routers in a domain must know and agree on the active RP
for each

multicast group (Group-to-RP mappings).

272 NTS for CCIE SP Lab by chatasos

Auto-RP

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

IOS

interface Loopback0 ip pim sparse-mode

!
ip pim send-rp-announce Loopback0 scope 10 ip pim send-rp-
discovery Loopback0 scope 10

IOS-XR

router pim

address-family ipv4
auto-rp mapping-agent Loopback0 scope 10 auto-rp candidate-rp
Loopback0 scope 10 interface Loopback0

enable

In IOS-XR, Auto-RP is not supported for VRFs.

In IOS, you can use an ACL to filter the auto-rp groups.

Auto-RP requires either sparse-dense mode or sparse mode and auto-rp listener (by default
enabled in IOS- XR).
BSR

IOS

interface Loopback0 ip pim sparse-mode

!
ip pim bsr-candidate Loopback0 ip pim rp-candidate Loopback0

IOS-XR

router pim

address-family ipv4 interface Loopback0

enable !

bsr candidate-bsr 1.1.1.1 bsr candidate-rp 1.1.1.1

When static RP is configured together with Auto-RP or BSR for the same PR mappings,
Auto-RP/BSR created mappings take precedence, unless "override" is configured with the
static rp-address.

273 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

PIM-SSM

PIM-SSM uses PIM-SM + IGMPv3/MLDv2. Summary

 Receivers report interest for a particular source using IGMv3

 PIM routers do RPF lookups for the source and join upstream towards the source
 An SPT is created between the source and the receivers
 Multicast traffic starts to flow from source to the receivers on the SPT

Detailed analysis

1. Receiver

1. sends an IGMPv3 Report (S,G) to the LAN

2. Receiver DR
1. receives the IGMP Report (S,G) from the Receiver
2. adds the incoming IGMP interface to OIL for (S,G)
3. performs RPF lookup for source S
 4. sends a PIM Join (S,G) to the upstream router out of the RPF interface
3. Upstream Routers (from Receiver DR towards the Source)
1. add the incoming PIM interface to OIL for (S,G)
2. perform RPF lookup for source S
3. send a PIM Join (S,G) to the next upstream router out of the RPF interface (*)
4. ...

(*) This propagation of PIM Join messages our of the RPF interface continues until the
source DR is reached or an upstream router has already multicast forwarding state for this
group.

IOS

ip pim ssm default

interface X

ip pim sparse-mode

IOS-XR

multicast-routing

address-family ipv4 interface X

enable

SSM is enabled by default on IOS-XR for 232.0.0.0/8.

In IOS-XR, interfaces enabled under multicast-routing run PIM sparse-mode by default.

274 NTS for CCIE SP Lab by chatasos
chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

PIM-SM

Summary

 A receiver asks for multicast data and an RPT (*,G) is built from the receiver DR
to the RP
 When the source transmits the multicast data, first packets are sent encapsulated
into PIM Register

messages by the source DR to the RP and then an SPT (S,G) is built from the RP to
the source

 When the multicast data reaches the receiver, there is a new SPT (S,G) built from
the receiver DR

directly to the source

 Receiver DR sends a prune message to the RP to stop the initial RPT

Detailed analysis

Phase #1 (Receiver asks for multicast data) 1. Receiver

1. sends an (*,G) IGMP Report to the LAN

2. Receiver DR Router
1. receives the (*,G) IGMP Report from the Receiver
2. adds the incoming IGMP interface to OIL for (*,G)
 3. performs RPF lookup for RP
4. sends a (*,G) PIM Join to the upstream router out of the RPF interface
3. Upstream Routers (from Receiver DR towards the RP)
1. receive the (*,G) PIM Join from the downstream router
2. add the incoming PIM interface to OIL for (*,G)
3. perform RPF lookup for RP
4. send a (*,G) PIM Join to the next upstream router out of the RPF interface (*)

Phase #2 (Source sends multicast data and Receiver receives it through the RP)

1. Source S

1. starts sending native multicast data (S,G) to the LAN

2. Source DR Router

1. receives native multicast data from the source

2. adds the incoming multicast data interface to IIF
3. encapsulates multicast data in PIM Register messages
4. sends the PIM Register messages to the RP as unicast packets

3. RP (with active RPT)

1. receives and decapsulates the PIM Register messages
2. sends the decapsulated native multicast data to the receiver down the RPT
4. Receiver

1. receives the native multicast data through the RP

5. RP (with active RPT)

1. performs RPF lookup for source S
2. sends a (S,G) PIM Join to the upstream router (towards source) out of the RPF
interface
6. Upstream Routers (from RP towards the Source)
1. 2. 3. 4.

7. Source

receive the (S,G) PIM Join

add the incoming PIM interface to OIL for (S,G)
perform RPF lookup for source S
send a (S,G) PIM Join to the next upstream router (towards source) out of the RPF interface
(*) DR Router

275

NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

 1. receives the (S,G) PIM Join
2. starts sending native multicast data to the RP

8. RP (with active RPT)

1. receives duplicate multicast data (encapsulated from Source DR and native from
source/upstream)

2. sends a PIM Register-Stop message to the Source DR

9. Source DR Router

1. receives the PIM Register-Stop message from the RP

2. stops sending PIM Register messages with encapsulated multicast data to the RP

10. RP (with active RPT)

1. receives only native multicast data

2. sends the native multicast data to the receivers down the RPT

11. Receiver

1. receives the native multicast data through the RP

Phase #3 (Receiver receives the multicast data directly from the Source)

1. Receiver DR Router
1. receives multicast data (S,G) from source S through the RP
2. performs RPF lookup for source S
3. sends a (S,G) PIM Join to the upstream router out of the RPF interface
2. Upstream Routers (from Receiver DR towards the Source DR)
1. receive the (S,G) PIM Join from the downstream router
2. add the incoming PIM interface to OIL for (S,G)
3. perform RPF lookup for source S
4. send a (S,G) PIM Join to the next upstream router out of the RPF interface (*)
 3. Source
1. receives the (S,G) PIM Join from the downstream router
2. starts sending native multicast data to the Receiver DR Router
4. Receiver DR Router
1. receives duplicate multicast data (from source DR through SPT and from RP
through RPT)
2. sends a PIM Prune (S,G,RPT) to the upstream router out of the RPF interface
5. Upstream Routers (from Receiver DR towards the RP)
1. receive the PIM Prune (S,G,RPT)
2. remove the incoming PIM interface from OIL for (*,G)
3. if OIL is null, send a PIM Prune (S,G) to the upstream router out of the RPF
interface
6. RP
1. receives the PIM Prune (S,G)
2. removes the incoming PIM interface from OIL for (*,G)
3. if OIL is null, sends a PIM Prune (S,G) to the upstream router out of the RPF
interface
7. Source
1. receives the PIM Prune (S,G)
2. removes the incoming PIM interface from OIL for (S,G)

(*) This propagation of PIM Join messages our of the RPF interface continues until the RP or
the Source DR is reached or an upstream router has already multicast forwarding state for this
group.

PIM Prune messages might not be sent, if there is another active multicast state for the same
group in the router.

DR Router

DR
276 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

The Source DR periodically sends a PIM Null-Register message (without any multicast data
inside) to the RP, in order to inform it that the source is still active.

IOS

interface X

ip pim sparse-mode

IOS-XR

multicast-routing

address-family ipv4 interface X

enable

OIL = Outgoing Interface List IIF = Incoming Interface

In the shortest path tree (SPT), the root of the tree is the source. In the shared path tree (RPT),
the root of the tree is the RP.

PIM Joins are sent to 224.0.0.13.

The threshold for switching from the RPT to SPT is 0 by default, which means once the
Receiver DR receives the first multicast packet and learns the source, it sends a (S,G) PIM
Join towards the source. When is starts receiving multicast data from the SPT, it sends a PIM
Prune for traffic received via the RPT towards the RP.

PIM Bidir

PIM Bidir is significantly simpler in operation than PIM-SM.

It eliminates the maintenance of (S,G) entries (only (*,G) are kept) and there's no data driven
events hence packets never need to be signaled and preserved (much more scalable for many-
to-many applications).

Bidir PIM uses the Designated Forwarder (DF) election mechanism (based on routing
protocol cost to the RP) to elect a single router on each link, which becomes responsible for
the following tasks:

picking up packets from the link and forwarding them upstream towards the RP
forwarding downstream multicast packets from the RP onto the link
When configuring both sparse and bidir groups, you need to explicitly define them, because
everything

excluded from bidir is dense by default.

277 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

IOS

ip pim bidir-enable
ip pim rp-address 1.1.1.1 bidir

IOS-XR

router pim address-family ipv4

rp-address 1.1.1.1 bidir

In some IOS-XR releases you might need to define the mcast bidir range of group addresses.

IOS

R2#sh ip pim rp map

PIM Group-to-RP Mappings
Group(s): 224.0.0.0/4, Static, Bidir Mode RP: 1.1.1.1 (?)

IOS-XR

GSR#sh pim group-map

Tue Feb 4 13:57:55.368 UTC

IP PIM Group Mapping Table

(* indicates group mappings being used) (+ indicates BSR group
mappings active in

MRIB)

RP address Info
0.0.0.0
0.0.0.0
0.0.0.0
0.0.0.0
1.1.1.1 RPF:

0.0.0.0 RPF:

Group Range

224.0.1.39/32*
224.0.1.40/32*
224.0.0.0/24*
232.0.0.0/8*
224.0.0.0/4* Gi0/2/1/2.28,2.2.28.2 224.0.0.0/4 SM static
Null,0.0.0.0

Proto Client

Groups

0 1 0 0 1

DM perm DM perm NO perm SSM config BD config

You will see only (*,G) entries for the bidir groups, no (S,G) entries.

PIM Register Tunnels

Inlatestsoftwarereleases,PIMusestunnelinterfacesforRPRegistercommunication.Youcanuse"s
h ip pim
tunnel"inordertoverifythePIMconnectivity,eitherinsideoroutsideavrf.Ifnotunnelexistsbut
should exist, then there is probably something wrong.
278 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

IOS

R1#sh ip pim tunnel

Tunnel0

Type : PIM Encap RP : 10.0.0.1* Source: 10.0.0.1

Tunnel1*
 Type : PIM Decap
RP : 10.0.0.1*
Source: -

R1#sh ip pim vrf VPN tunnel Tunnel1

Type : PIM Encap RP : 10.0.0.1 Source: 10.1.7.1

R1#sh int tun1 | i protocol/transport Tunnel

protocol/transport PIM/IPv4

IOS-XR

GSR#sh pim tunnel info all Fri Jun 9 06:04:51.319 UTC

Interface

Encapstunnel0
Decapstunnel0

RP Address

10.0.0.1
0.0.0.0
Source Address

10.0.0.1 -

The router acting as RP should have at least two PIM tunnels: one for Encapsulation (usually
src=RP) and another one for Decapsulation. All other PIM routers should have only one for
Encapsulation (src=local PIM address, dst=RP).

IGMP

You can use the following as multicast receiver.

IOS

interface X
ip igmp join-group 224.1.1.1

IOS-XR

router igmp
interface X

join-group 232.1.1.1 192.168.1.1

279 NTS for CCIE SP Lab by chatasos
chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

PIM (sparse) is also required on the interface where IGMP is enabled.

"ip igmp static-group

x.x.x.x"canalsobeused,ifwewanttoavoidhavingthemulticasttraffic being processed by the
router.

IGMP (v3) for SSM requires to also define the source of multicast traffic.

In IOS, when using multicast ping to test connectivity, the multicast packets go out through
all multicast enabled interfaces by default (regardless of the source ip/interface chosen in
CLI). If you want to send it out through a specific interface then you need to use extended
ping and choose a specific interface in the "Interface" option.

IOS

R1#ping
Protocol [ip]:
Target IP address: 232.1.1.1 Repeat count [1]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y Interface [All]: FastEthernet0/0 Time
to live [255]:
Source address: 1.1.1.1

280 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Advanced Multicast
RPF (Reverse Path Forwarding)

In an RPF check, the router looks in a routing table to determine its RPF interface, which is
the interface closest to the root (the source or the RP). The RPF interface is also the incoming
interface for the multicast data. RPF checks happen in the control-plane (PIM, MSDP) and in
the data-plane (multicast data).

The routing table used for RPF checks can be the global unicast routing table or a separate
multicast routing table. In any case, the RPF table contains only unicast routes (the multicast
source or the RP).

MP-BGP and M-ISIS can be used to create separate unicast and multicast routing tables.

MP-BGP updates can include IPv4 multicast RPF routes along with IPv4 unicast routes,
totally separated (different path attributes) from each other.

Youcanuse"sh ip mroute count"tocheckforincreasingRPFcounts. Fixing RPF issues

If you have IP connectivity over a TE tunnel and require PIM connectivity too, then extra
care must be taked. Since you cannot activate PIM on a TE tunnel, you must somehow fix the
possible RPF issue on the head- end. The same must be done in every other case where
unicast and multicast forwarding do not agree.

Solutions

 static mroute
 multicast BGP
 multicast topology in IS-IS
 mpls traffic-eng multicast-intact (for IGP routes)

Youcanusethecommand"sh ip rpf"inordertoverifyRPFissues.

Before

IOS

R2#sh ip rpf 19.19.19.19 failed, no route exists

IOS-XR

GSR#sh pim rpf 2.2.2.2 Table: IPv4-Unicast-default *

2.2.2.2/32 [115/30]
via Null with rpf neighbor 0.0.0.0
281 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

InIOS-XR,thecommand"sh pim
rpf"providesanoutputonlyiftheaddressprovidedisalreadyusedas amulticastsource.Use"sh
pim rpf hash"tocheckinadvance.

After fixing the RPF issue:

IOS

R2#sh ip rpf 19.19.19.19

RPF information for ? (19.19.19.19)

RPF interface: FastEthernet1/0.24 RPF neighbor: ? (26.2.4.4)

RPF route/mask: 19.19.19.19/32 RPF type: unicast (isis)

Doing distance-preferred lookups across tables

RPF topology: ipv4 multicast base, originated from ipv4
unicast base

IOS-XR

GSR#sh pim rpf 2.2.2.2

Table: IPv4-Multicast-default * 2.2.2.2/32 [115/30]

via GigabitEthernet0/1/0/1 with rpf neighbor 26.3.19.3 static

mroute
IOS

ip mroute 2.2.2.2 255.255.255.255 Tunnel0

IOS-XR

multicast-routing

address-family ipv4
static-rpf 2.2.2.2 32 tunnel-te0 3.3.3.3

multicast-intact

When enabled on an IGP, the IGP automatically publishes to the RIB a parallel (or alternate)
set of equal-cost next-hops for all IPv4 destinations learned through LS advertisements, for
use solely by PIM. These next-hops are called mcast-intact next-hops. The mcast-intact next-
hops have the following characteristics:

 They are guaranteed not to contain any IGP shortcuts (like TE tunnels).
 They are not used for unicast routing, but are used only by PIM to look up an IPv4
next-hop to a PIM

source.

 They are not published to the FIB.

 When multicast-intact is enabled on an IGP, all IPv4 destinations that were learned
through link-state

advertisements are published with a set of equal-cost mcast-intact next-hops to the

RIB. This attribute applies even when the native next-hops have no IGP shortcuts.

282 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

IOS

router ospf 1

mpls traffic-eng multicast-intact

router isis 1

mpls traffic-eng multicast-intact

IOS-XR

router ospf 1
mpls traffic-eng multicast-intact

!
router isis 1

address-family ipv4 unicast

mpls traffic-eng multicast-intact

Multicast-intact doesn't work with TE forwarding-adjacency, use multicast BGP or static

mroute.

multicast-intact vs static mroute in TE tunnels

 use multicast-intact to accept multicast traffic coming from outside a TE tunnel,

when the unicast route is pointing inside the TE tunnel
 use static mroute to accept multicast traffic coming from inside a TE tunnel, when
the unicast route is pointing outside the TE tunnel

IS-IS Multicast Topology

Multicast topology for ISIS allows the configuration of a separate IS-IS multicast
topology for IPv4 or IPv6 routing, which runs a separate SPF.

IS-IS multicast inserts routes from the IS-IS multicast topology into the multicast-
unicast table in the RIB for the corresponding address family. Since PIM uses this
table, PIM uses routes from the multicast topology instead of routes from the unicast
topology.

Multicast BGP

The multicast BGP database can be used by a a multicast routing protocol (i.e. PIM)
to perform RPF lookups for multicast-capable sources. Thus, packets can be sent and
accepted based on the multicast topology and not on the unicast topology.

This is an easy way to change the multicast routing without affecting unicast too.
Static mroutes can also be used.

IOS

router bgp 65000

no bgp default ipv4-unicast neighbor 7.7.7.7 remote-as
65000 !
283 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

address-family ipv4 multicast neighbor 7.7.7.7 activate

network 192.168.7.0

exit-address-family

IOS-XR

router bgp 65000 address-family ipv4 multicast

network 192.168.7.0/24 !

neighbor 7.7.7.7

address-family ipv4 multicast

IOS

R8#sh ip rpf 192.168.7.0

RPF information for ? (192.168.7.0)

RPF interface: FastEthernet0/0 RPF neighbor: ? (192.168.78.7)

RPF route/mask: 192.168.7.0/24 RPF type: mbgp

RPF recursion count: 0

Doing distance-preferred lookups across tables
Changing of BGP distance might be needed on the remote peer, if an IGP already provides a
better route.

When you enable the multicast address-family under BGP, then these prefixes take
precedence over the prefixes learned in the BGP unicast address-family; only the BGP
prefixes learned in the multicast address- familyareusedforanymulticastrouting.Use"show
route ipv4 multicast"inIOS-XRtodisplay the ipv4 multicast routes.

MSDP & Anycast RP

MSDP provides a way to connect multiple PIM-SM domains, so that RPs can exchange
information about

active multicast sources. It uses

MSDP sessions are formed between the RPs of various PIM domains, which are called
MSDP peers.

MSDP is also used between Anycast RPs within a single PIM domain to synchronize
information about the active sources being served by each Anycast-RP peer. Anycast RPs
will each have the same IP address configured on a Loopback interface (making this the
Anycast address) and will MSDP peer with each other using a separate loopback interface.

You might need to also advertise a specific next-hop for the RPF route, if the default next-
hop doesn't satisfy

the RPF needs (recursive lookup might not be supported).

284 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

With Anycast RP, RP failover depends only on IGP convergence

MSDP RPs send SA (Source-Active) messages in order to notify each other of active
multicast sources.

An MSDP RP sends an SA message to its peers each time it receives a PIM Register or Null-
Register message from a Source DR about a new/active source. MSDP SA messages include
the same multicast data that is also encapsulated in PIM Register or Null-Register messages.

IOS

interface Loopback99
ip address 99.99.99.99 255.255.255.255

!
interface Loopback0

ip address 2.2.2.2 255.255.255.255 !

ip msdp peer 1.1.1.1 connect-source Loopback0 ip msdp

originator-id Loopback0
!
ip pim rp-address 99.99.99.99

IOS-XR
interface Loopback99
ipv4 address 99.99.99.99 255.255.255.255

!
interface Loopback0

ipv4 address 1.1.1.1 255.255.255.255 !

router msdp originator-id Loopback0 peer 2.2.2.2

connect-source Loopback0 !

router pim address-family ipv4

rp-address 99.99.99.99

The address on the interface used as anycast RP must be advertised into an IGP (preferably as
external route to be able to play easily with the metric).

When using anycast IPv4 addresses in Loopbacks, it's good practice to hardcode all the
protocol router-ids

manually in order to avoid using the anycast address as router-id for a protocol.

In some software releases originator-id might not be required, but it's always good practice to
configure it

(especially in anycast topologies).

285 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

In current releases, when running Inter-AS MSDP, the peer/source IPs must agree with the
BGP update source on each neighbor.
If MDT is using a non-loopback interface due to eBGP with directly connected neighbor, you
might get the message "%MDT-4-LBSRC:

VRF ABC: MDT X uses source address x.x.x.x from a non-loopback

interface". Besideschangingtheupdate-sourceoftheeBGPpeering,youcanalsousethe"bgp
next-hop loopback X"commandundertheappropriatevrf.

Use "default-peer" in IOS-XR when the peer address isn't in BGP.

If there is a single MSDP peer, then no RPF check takes place about the originator-id.

Links

 IETF - RFC 3618

 IETF - RFC 4611

Multicast Filtering

Setting an interface to PIM v1 at the border of a PIM domain prevents v2 Bootstrap

messages from leaking to the neighboring PIM domain.

Use"ip pim
passive"underaninterfaceifyouwanttoblocktheforwardingofPIMcontrolplane
traffic; only IGMP traffic will pass.

BSR filtering

IOS

interface X

ip pim bsr-border

IOS-XR

router pim

address-family ipv4 interface X

bsr-border

Auto-RP filtering

IOS-XR

multicast-routing address-family ipv4

If you also have a BGP peering session with an MSDP peer, you should use the same IP
address for MSDP (peer/connect-source) as you do for BGP (update-source).

If there are multiple

MSDP peers, then you can put them under a mesh-group in order to disable the RPF check on
them.
286 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

interface TenGigE0/2/0/0 boundary MCAST-ACL

!
ipv4 access-list MCAST-ACL

deny host 224.0.1.39 deny host 224.0.1.40 permit any

IGMP filtering

IOS
interface X
ip igmp access-group IGMP-ACL

! match (*,G)

ip access-list extended IGMP-ACL permit ip host 0.0.0.0 host

GROUP

! match (S,G) and (*,G)

ip access-list extended IGMP-ACL permit ip any host GROUP

Multicast Admission Control

Global or per VRF

o o o

limit the number of mroutes that can be added to the global table

ip multicast route-limit MAX-MROUTES THRESHOLD limit the number of

mroutes that can be added to a particular MVRF table

ip multicast vrf MVRF route-limit MAX-MROUTES THRESHOLD limit

the number of mroute states created from IGMP membership reports

ip igmp limit MAX-IGMPS Per interface

o limit the number of mroute states

ip multicast limit MCAST-ACL MAX-MROUTES

o limit the number of mroutes states created from IGMP membership reports ip igmp
limit MAX-IGMPS

Per neighbor
o Limits the number of SA messages allowed in the SA cache from an MSDP peer

ip msdp sa-limit MSDP-PEER MAX-SA-MESSAGES Check "Multicast

Filtering" above for the format of MCAST-ACL.

287 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Rate-limit
The"ip multicast rate-limit"interfacecommandisnotsupportedanymore.
You need to use the the MQC syntax to define multicast traffic and then police it accordingly.

Multicast Fast Convergence

 tune PIM hellos (queries)

 tune RPF check interval/backoff
 MoFRR

Multicast-only FRR

The basic idea of MoFRR is to send a secondary PIM join from the receiver toward
the source on a backup path to a different upstream interface. The network then
receives two copies of the multicast stream over two separate and redundant paths
through the network, but the redundant packets are discarded at topology merge
points due to RPF checks. When the primary path fails, it can switch over to the
backup path instantly without issuing a new PIM join.

Actually MoFRR is pre-building an alternate multicast tree in order to achieve faster

convergence.

RIB-based MoFRR
o Supported on CRS and XR12000 series routers o Based on routing convergence

Flow-based MoFRR
o Supported ASR9k

o Based on packet count per 30ms

IOS (15.2)
ip multicast rpf mofrr MOFRR-SG-ACL !
ip access-list standard MOFRR-SG-ACL

permit 10.10.10.0 0.0.0.255

IOS > 15.2 is required for MoFRR.

IOS-XR

router pim address-family ipv4

mofrr rib MOFRR-SG-ACL !

288 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

ipv4 access-list MOFRR-SG-ACL

10 permit ipv4 host 1.1.1.1 host 239.3.3.3

Links

IETF - draft-ietf-rtgwg-mofrr

Troubleshooting

Enable"debug ip mfib fs"and"debug ip mfib

ps"onthereceiver,andthensendsomepings from a source to an igmp join group on the receiver
to check the results.

IPv6 Multicast

IOS

ipv6 multicast-routing

IOS-XR

multicast-routing address-family ipv6

interface all enable

In IOS, all IPv6 interfaces are PIM enabled by default after enabling ipv6 multicast-routing.
IPv6 RP definition

IOS

ipv6 pim bsr candidate bsr 2002:2:2::2 ipv6 pim bsr candidate
rp 2002:2:2::2 !
ipv6 pim rp-address 2002:2:2::2

IOS-XR

router pim address-family ipv6

rp-address 2002:2:2::2
bsr candidate-rp 2002:2:2::2 bsr candidate-bsr 2002:2:2::2
289 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

MLD

IOS

ipv6 multicast-routing !interface Loopback0

ipv6 mld join-group FF99::99

IOS-XR

multicast-routing address-family ipv6

interface all enable !

router mld
interface Loopback0

join-group ff99::99 MLDv2 is used by default.

Verification

R2#sh ipv6 mroute

Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,

C - Connected, L - Local, I - Received Source Specific Host

Report,

P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit

set,

J - Join SPT Timers: Uptime/Expires

Interface state: Interface, State

(*, FF99::99), 00:00:08/00:03:21, RP 2002:2:2::2, flags: S

Incoming interface: Tunnel4
RPF nbr: 2002:2:2::2
Immediate Outgoing interface list:

Ethernet0/2, Forward, 00:00:08/00:03:21

R2#ping FF99::99
Output Interface: Ethernet0/2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FF99::99, timeout is 2
seconds: Packet sent with a source address of 2002:2:2:27::2

Reply to request 0 received from 2002:2:2::7, 60 ms

Reply to request 1 received from 2002:2:2::7, 0 ms
Reply to request 2 received from 2002:2:2::7, 4 ms
Reply to request 3 received from 2002:2:2::7, 4 ms
Reply to request 4 received from 2002:2:2::7, 0 ms
Success rate is 100 percent (5/5), round-trip min/avg/max =
0/13/60 ms 5 multicast replies and 0 errors.
290 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Almost everything cli-wise is similar to IPv4.

Static mroutes

IOS

ipv6 route 2002:2:2::2/128 Tunnel0 multicast

IOS-XR

multicast-routing

address-family ipv6
static-rpf 2002:2:2::2 128 tunnel-te0 2002:3::1

NSF

IOS-XR

router pim
nsf lifetime 30

!
router igmp

nsf lifetime 30
!
router mld
nsf lifetime 30

Generally, configure the IGMP NSF and PIM NSF lifetime values to be equal or larger than
the query or join query interval, but less than the holdtime

Multipath

Whenthe'ip multicast
multipath'commandisconfigured,themulticastloadsplittingwillbebased on the source
address of the stream. PIM Joins will be distributed over the different ECMP links based on a
hash of the source address.

Multicast multipath must be enabled on the receiver side of the ECMP path.

IOS
ip multicast multipath
By default, if ECMP paths are available, the RPF for multicast traffic will be based on the
highest IP address

(aka highest PIM neighbor).

291 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

IOS
R2#sh ip rpf 19.19.19.19
RPF information for ? (19.19.19.19)

RPF interface: FastEthernet0/0.24 RPF neighbor: ? (20.2.4.4)

RPF route/mask: 19.19.19.19/32 RPF type: unicast (ospf 1)

Doing distance-preferred lookups across tables

Multicast Multipath enabled.
RPF topology: ipv4 multicast base, originated from ipv4
unicast base

By default only the source address is used in the calculation. Better load-splitting can be
achieved by using the "s-g-hash next-hop-based"options.

; that is, the chosen RPF neighbor does not depend on whether or not PIM hello messages are
received from that neighbor; it only depends on the presence or absence of an equal-cost
route entry.

If using BGP and multicast, then you must also enable multipath on BGP.

IOS

ip route 192.168.1.1 255.255.255.255 20.2.3.3

ip route 192.168.1.1 255.255.255.255 20.2.4.4
!
ip mroute 19.19.19.19 255.255.255.255 192.168.1.1

In the above example, multicast load-balancing occurs between 20.2.3.3 and 20.2.4.4 for
source 19.19.19.19 (192.168.1.1 is the dummy address used).

Use"sh ip multicast rpf tracked"toverifythemultiplerpfpaths.

When the ip multicast multipath command is enabled, the presence of PIM hello message
from neighbors is

not considered

If using static mroutes, then you need to somehow create two (or more) different static
mroutes because only

one is accepted. You can use a dummy ip address and two (or more) static ip routes in order
to achieve this.
292 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Multicast VPN
Multicast VPN is defined in RFC 6513 and RFC 6514. Cisco's Multicast VPN is defined in
RFC 6037.

Two solutions:

PIM/GRE mVPN or draft-rosen (RFC 6037)

o PIM adjacencies between PEs to exchange mVPN routing information o unique multicast
address per VPN
o per-VPN PIM adjacencies between PEs and CEs
o per-VPN MDT (GRE) tunnels between PEs
o data MDT tunnels for optimization

BGP/MPLS mVPN or NG mVPN

o BGP peerings between PEs to exchange mVPN routing information o PIM messages are
carried in BGP
o BGP autodiscovery for inter-PE tunnels
o MPLS P2MP inclusive tunnels between PEs
o selective tunnels for optimization

Only the PIM/GRE mVPN model (Cisco's original implementation) is described below.

MVPN

MVPN combines multicast with MPLS VPN. PE routers establish virtual PIM neighborships
with other PE routers that are connected to the same VPN.

The VPN-specific multicast routing and forwarding database is referred to as MVRF.

A MDT (multicast distribution tree) tunnel interface is an interface that MVRF uses to access
the multicast

domain. MDT tunnels are point-to-multipoint.

Multicast packets are sent from the CE to the ingress PE and then encapsulated and
transmitted across the core (over the MDT tunnel). At the egress PE, the encapsulated packets
are decapsulated and then sent to the receiving CE.

When sending customer VRF traffic, PEs encapsulate the traffic in their own (S,G) state,
where the G is the MDT group address, and the S is the MDT source for the PE. By joining
the (S,G) MDT of its PE neighbors, a PE router is able to receive the encapsulated multicast
traffic for that VRF.

All VPN packets passing through the provider network are viewed as native multicast packets
and are routed based on the routing information in the core network.
293 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

To support MVPN, PE routers only need to support native multicast routing.

RTs should be configured so that the receiver VRF has unicast reachability to prefixes in the
source VRF.

Data MDT

MVPN also supports optimized VPN traffic forwarding for high-bandwidth applications that
have sparsely distributed receivers.

A dedicated multicast group can be used to encapsulate packets from a specific source and an
optimized MDT can be created to send traffic only to PE routers connected to interested
receivers.

A unique group per vrf should be used on the PEs.

Configuration

IOS

ip multicast-routing !
ip pim ssm default
!

interface Loopback0 ip pim sparse-mode

!
interface X

ip pim sparse-mode !

ip multicast-routing vrf VPN !

vrf definition VPN

address-family ipv4
mdt default x.x.x.x
mdt data x.x.x.x y.y.y.y

exit-address-family !

router bgp 100

address-family ipv4 mdt neighbor x.x.x.x activate

exit-address-family

IOS-XR

multicast-routing address-family ipv4

interface Loopback0 enable

294 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

mdt source Loopback0 !

vrf VPN address-family ipv4

mdt default ipv4 x.x.x.x mdt data y.y.y.y/24 interface all

enable

!
router bgp 100

address-family ipv4 mdt

!
neighbor x.x.x.x

address-family ipv4 mdt

"mdt source"isrequiredinIOS-XR(itcanbeconfiguredundertheVRFifit'sspecificforit).
Sparse mode must be activated on all physical interfaces where multicast will be passing
through (global or

VRF ones) and on the loopback interface used for the BGP VPNv4 peerings.
The RP setup of the CEs must agree with the VRF RP setup on the PEs. In case you manually
define the

RP (static RP) on the CEs, then this must be done on the PEs too (inside the vrf).

Verification

 There should be (S,G) entries for each BGP neighbor, where S=BGP loopback and
G=MDT default address
 There should be a bidirectional PIM adjacency across a tunnel between the PEs,
but inside each PE's VRF
 If an RP is used on a CE, then each remote CE should know this RP
 Sources/Receivers from any site should be viewable on the RP
 There should be an MDT data (S,G) entry for each pair of customer (S,G) entries

Verification (using only a default mdt) MDT default (S,G) entries

IOS
 R5#sh ip mroute sum
IP Multicast Routing Table

Flags: D -
Connected,
L -
T -

Dense, S - Sparse, B - Bidir Group, s - SSM Group, C -

Local, P - Pruned, R - RP-bit set, F - Register flag, SPT-bit

set, J - Join SPT, M - MSDP created entry, E -

295
NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP

Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group, V -
RD & Vector, v - Vector

Outgoing interface flags: H - Hardware switched, A - Assert

winner Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.255.255.1), 00:34:36/stopped, RP 10.0.0.1, OIF count:

1, flags: SJCFZ

( ), 00:24:11/00:02:18, OIF count: 1, flags: JTZ ( ),

00:34:35/00:02:54, OIF count: 1, flags: FT

R5#sh ip mroute 239.255.255.1 IP Multicast Routing Table

10.0.0.6, 239.255.255.1
10.0.0.5, 239.255.255.1

Dense, S - Sparse, B - Bidir Group, s - SSM Group, C -

Local, P - Pruned, R - RP-bit set, F - Register flag, SPT-bit

set, J - Join SPT, M - MSDP created entry, E -

Proxy Join Timer Running, A - Candidate for MSDP

Advertisement,

Flags: D -
Connected,
L -
T -

U - URD, I - Received Source Specific Host Report,

Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group, V -
RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert
winner Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.255.255.1), 00:46:12/stopped, RP 10.0.0.1, flags:

SJCFZ Incoming interface: FastEthernet0/0.15, RPF nbr 10.1.5.1
Outgoing interface list:

MVRF VPN, Forward/Sparse, 00:46:12/00:01:46

(10.0.0.6, 239.255.255.1), 00:35:47/00:02:28, flags: JTZ

Incoming interface: FastEthernet0/0.57, RPF nbr 10.5.7.7
Outgoing interface list:

MVRF VPN, Forward/Sparse, 00:35:47/00:01:46

(10.0.0.5, 239.255.255.1), 00:46:12/00:03:19, flags: FT

Incoming interface: Loopback0, RPF nbr 0.0.0.0 Outgoing
interface list:

FastEthernet0/0.57, Forward/Sparse, 00:35:46/00:03:11

Extranet, X -

296 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

R5#sh bgp ipv4 mdt all 10.0.0.6/32

BGP routing table entry for 100:1:10.0.0.6/32 version 2 Paths:
(1 available, best #1, table IPv4-MDT-BGP-Table)

Not advertised to any peer Local

10.0.0.6 from 10.0.0.1 (10.0.0.1)

Origin incomplete, metric 0, localpref 100, valid, internal,
best Originator: 10.0.0.6, Cluster list: 10.0.0.1, 10.0.0.20,
MDT group address: 239.255.255.1

R5#sh ip pim mdt

* implies mdt is the default MDT MDT Group/Num Interface
Source

* 239.255.255.1 Tunnel1 Loopback0

R5#sh ip pim mdt bgp
MDT (Route Distinguisher + IPv4)

MDT group 239.255.255.1 100:1:10.0.0.6

Verification (using a default and a data mdt)

IOS

R2#sh ip mroute
IP Multicast Routing Table

VRF VPN

Router ID
10.0.0.1
Next Hop
10.0.0.6
MDT default (S,G) entries

MDT data (S,G) entries

Flags: D -
Connected,
L -
T -

U - URD, I - Received Source Specific Host Report,

Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group, V -
RD & Vector, v - Vector

Dense, S - Sparse, B - Bidir Group, s - SSM Group, C -

Local, P - Pruned, R - RP-bit set, F - Register flag, SPT-bit

set, J - Join SPT, M - MSDP created entry, E -

Proxy Join Timer Running, A - Candidate for MSDP

Advertisement,

Extranet, X -

Outgoing interface flags: H - Hardware switched, A - Assert

winner Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(2.2.2.2, 232.0.0.1), 00:08:53/00:03:27, flags: sT Incoming

interface: Loopback0, RPF nbr 0.0.0.0
297 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Outgoing interface list:

FastEthernet0/0.24, Forward/Sparse, 00:08:53/00:03:27

(19.19.19.19, 232.0.0.1), 00:50:48/stopped, flags: sTIZ

Incoming interface: FastEthernet0/0.24, RPF nbr 20.2.4.4
Outgoing interface list:

MVRF VPN, Forward/Sparse, 00:50:48/00:00:11

(19.19.19.19, 232.0.1.0), 00:08:23/00:00:12, flags: sTIZ

Incoming interface: FastEthernet0/0.24, RPF nbr 20.2.4.4
Outgoing interface list:

MVRF VPN, Forward/Sparse, 00:02:47/00:00:12

(19.19.19.19, 232.0.1.1), 00:01:59/00:01:00, flags: sTIZ

Incoming interface: FastEthernet0/0.24, RPF nbr 20.2.4.4
Outgoing interface list:

MVRF VPN, Forward/Sparse, 00:01:59/00:01:00 R2#sh ip pim mdt

* implies mdt is the default MDT

MDT Group/Num Interface Source VRF

Tunnel0 Loopback0 VPN Tunnel0 Loopback0 VPN Tunnel0 Loopback0

VPN

232.0.0.1
232.0.1.0
232.0.1.1

R2#sh ip pim mdt bgp

MDT (Route Distinguisher + IPv4) Router ID

MDT group 232.0.0.1

100:1:19.19.19.19 19.19.19.19

19.19.19.19
In both scenarios, you can also verify the mGRE tunnels by looking at the tunnel interface
itself.

IOS

R5#sh int tun1 | i protocol/transport Tunnel

protocol/transport multi-GRE/IP

Next Hop

When all PIM adjacencies come up, as PIM neighbors in a VRF you should see all the other
MDT PEs though a tunnel and all the local connected CEs through a physical interface.

IOS

R5#sh ip pim vrf VPN nei

PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default
DR Priority,

P - Proxy Capable, S - State Refresh Capable, G - GenID

Capable Neighbor Interface Uptime/Expires Ver DR Address

298 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Prio/Mode
192.168.59.9 FastEthernet0/0.59 SG
10.0.0.6 Tunnel1
SPG

PIM inside a VRF Tunnel

IOS

interface Tunnel1
ip vrf forwarding VPN-A
ip address 99.99.99.1 255.255.255.0 ip pim sparse-mode
tunnel source 10.0.0.1
tunnel destination 10.0.0.2
tunnel vrf VPN-B

!
interface Tunnel1
ip vrf forwarding VPN-A
ip address 99.99.99.2 255.255.255.0 ip pim sparse-mode
tunnel source 10.0.0.2
tunnel destination 10.0.0.1
tunnel vrf VPN-B

00:00:22/00:01:22 v2 00:25:52/00:01:27 v2

1 / DR 1 / DR

"ip vrf
forwarding"definesthevrfunderwhichthetunnel(99.99.99.0/24)operates;aboveit'sVPN- A.

"tunnel
vrf"definesthevrfwhichisusedtobuildthetunnel(from10.0.0.1to10.0.0.2);aboveit'sVPN- B. If
the tunnel source and destination are in the global routing table, then you don't need to define
their vrf withthe"tunnel vrf X"command.

Extranet

An extranet site can have either the multicast source or the receivers (otherwise multicast
happens intra-as). The Source PE has the multicast source behind a directly connected CE
through the Source MVRF
The Receiver PE has one or more receivers behind a directly connected CE through the
Receiver MVRF

In order to achieve multicast connectivity between the Source and Receiver PEs, you must
have the same
default MDT group in the source and receiver MVRF.

299 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Two solutions:

Configure the Receiver MVRF on the Source PE router

o you need each receiver MVRF copied on the Source PE router

Configure the Source MVRF on the Receiver PE routers

o you need the Source MVRF copied on all interested Receiver PE routers

In both cases, the receiver MVRF (wherever placed) must import the source MVRF's RT.

Only PIM-SM and PIM-SSM are supported.

The multicast source and the RP must reside in the same site of the MVPN, behind the same
PE router.

Receiver MVRF on the Source PE

Source PE (IOS)
ip vrf VPN1-S-MVRF

rd 100:1
route-target export 100:1 route-target import 100:1 mdt
default 232.1.1.1

!
ip vrf VPN2-R-MVRF

rd 100:2
route-target export 100:2 route-target import 100:2 route-
target import 100:1 mdt default 232.2.2.2
!
ip multicast-routing ip multicast-routing ip multicast-routing

Receiver PE (IOS)
ip vrf VPN2-R-MVRF

rd 100:2
route-target export route-target import route-target import
mdt default 232.2.2.2

!
ip multicast-routing
ip multicast-routing vrf VPN2-R-MVRF

vrf VPN1-S-MVRF vrf VPN2-R-MVRF

100:2
100:2
100:1

300 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Source MVRF on the Receiver PE

Source PE (IOS)
ip vrf VPN1-S-MVRF
rd 100:1
route-target export 100:1 route-target import 100:1 mdt
default 232.1.1.1

!
ip multicast-routing ip multicast-routing

Receiver PE (IOS)
ip vrf VPN1-S-MVRF

rd 100:1
route-target export route-target import mdt default 232.1.1.1

!
ip vrf VPN2-R-MVRF

rd 100:2
route-target export 100:2 route-target import 100:2 route-
target import 100:1 mdt default 232.2.2.2

!
ip multicast-routing
ip multicast-routing vrf VPN1-S-MVRF ip multicast-routing vrf
VPN2-R-MVRF

What matters most in both cases when doing the MVRF replication, is to have the same MDT
on a MVRF on the Source PE and on a MVRF on the Receiver PE (excluding the Source
MVRF).

Fixing RPF

There are two options: static mroute between VRFs

Receiver PE (IOS)
ip mroute vrf VPN2-R-MVRF 192.168.1.1 255.255.255.255
fallback-lookup vrf VPN1-S-MVRF

group-based VRF selection Receiver PE (IOS)

vrf VPN1-S-MVRF

100:1 100:1

301 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

ip multicast vrf VPN2-R-MVRF rpf select vrf VPN1-S-MVRF group-

list 1 ip multicast vrf VPN2-R-MVRF rpf select vrf VPN3-S-MVRF
group-list 3 !
access-list 1 permit 231.0.0.0 0.255.255.255

access-list 3 permit 233.0.0.0 0.255.255.255

Inter-AS MVPN

To establish a Multicast VPN between two ASes, a MDT-default tunnel must be setup
between the involved PE routers. The appropriate MDT-default group is configured on the
PE router and is unique for each VPN.

All three (A,B,C) inter-as options are supported. For option A nothing extra is required since
every AS is completely isolated from the others.
In order to solve the various RPF issues imposed by the limited visibility of PEs between
different ASes, each VPNv4 route carries a new transitive attribute (the BGP connector
attribute) that defines the route's originator.

Inside a common AS, the BGP connector attribute is the same as the next hop. Between ASes
the BGP connector attribute stores (in case of ipv4 mdt) the ip address of the PE router that
originated the VPNv4 prefix and is preserved even after the next hop attribute is rewritten by
ASBRs.

The BGP connector attribute also helps ASBRs and receiver PEs insert the RPF vector
needed to build the inter-AS MDT for source PEs in remote ASes.

The RPF proxy vector is a PIM TLV that contains the ip address of the router that will be
used as proxy for RPF checks (helping in the forwarding of PIM Joins between ASes).

A new PIM hello option has also been introduced along with the PIM RPF Vector extension
to determine if the upstream router is capable of parsing the new TLV. An RPF Vector is
included in PIM messages only when all PIM neighbors on an RPF interface support it.

The RPF proxy (usually the ASBR) removes the vector for the PIM Join message when it
sees itself in it.

BGP connector attribute

o used in RPF checks inside a VRF

RPF proxy
o used in RPF checks in the core

Configuration Steps


Option

Option

o o o

A
no MDT sessions between ASes is required
intra-as MDT sessions are configured as usual
B
intra-as MDT sessions between PEs, ASBRs and RRs inter-as MDT session between ASBRs
RPF proxy vector on all PEs for their VRFs
302

NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

o RPF proxy vector on all Ps and ASBRs o next-hop-self on the MDT ASBRs

Option
o intra-as MDT sessions between PEs and RRs o inter-as MDT sessions between RRs
o RPF proxy vector on all PEs for their VRFs o RPF proxy vector on all Ps and ASBRs
o next-hop-unchanged on the MDT RRs

MSDP will be required if using an RP on both ASes. Prefer to use SSM in the core of both
ASes. Links

IETF - RFC 5496

C
303 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

BFD
BFD (Bidirectional Forwarding Detection) is defined in RFC 5880. BFD for one-hop
IPv4/IPv6 is defined in RFC 5881.
BFD for multi-hop is defined in RFC 5883.
BFD for MPLS LSPs is defined in RFC 5884.

Common BFD applications

 Control plane liveliness detection

  Tunnel endpoint liveliness detection
 Trigger mechanism for IP/MPLS FRR
 MPLS date plane failure detection

BFD advantages

 failure detection in sub-sec

 generic/consistent failure detection mechanism for all protocols
 less CPU intensive if distributed to the data plane

BFD modes

Asynchronous mode
o continuous and periodic BFD packets

Demand mode
o BFD packets only after a demand

BFD echo (where a stream of echo packets is sent and received) is the most common function
for both modes.

Cisco supports the asynchronous mode and the echo function by default.

BFD payload control packets are encapsulated in UDP packets

 destination port 3784

 source port 49152

Echo packets are also encapsulated in UDP packets

 destination port 3785

 source port 3785

BFD control packets are always sent as unicast packets to the BFD peer.

The encapsulation of BFD Control packets for multihop application in IPv4 and IPv6
is identical to that above, except that the UDP destination port is 4784.
304 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Each system reports in the BFD Control packet how rapidly it would like to transmit BFD
packets, as well as how rapidly it is prepared to receive them. This allows either system to
determine the max packet rate (minimum interval) in both directions.

To establish a BFD neighbor in IOS-XR, BFD must either be configured under an IGP or as a
static route.

BFD Configuration

BFD can be configured:

  under an interface for a specific protocol (IOS)
 under the protocol process for a specific interface (IOS-XR)
 under the protocol process for all interfaces ( )
 under the protocol process for all neighbors (
 under the protocol process for a specific neighbor ( )

In all cases, BFD timers (interval, min_rx, multiplier) must be defined under the
relevant interfaces too. BFD and BGP in IOS-XR is the exception, as show below.

echo mode for the entire router, or for an individual interface.

BFDcanbecombinedwith"carrier-delay 0"forquickerprotocolreaction.

InIOS-XR,"bfd fast-detect"isrequiredinordertostarttheBFDprocess.
BFD might cause crashes and malfunctions when enabled on GNS3 emulated routers.

IOS

IOS-XR

IOS,

IOS-XR

IfyouareusingBFDwithuRPFonaparticularinterface,thenyouneedtousethe"echo disable"

command to disable the echo mode on that interface, otherwise echo packets are rejected.

You can disable

Instead of running BFD at the link-level, you can also run BFD at the LSP level (aka across
the LSP), something that offers faster detection in case of path protection.

BFD & BGP

IOS

interface X
bfd interval 300 min_rx 300 multiplier 3

!
router bgp 100

neighbor 2.2.2.2 fall-over bfd

IOS-XR

router bgp 100 neighbor 2.2.2.2 bfd fast-detect

305 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

bfd multiplier 3
bfd minimum-interval 300

In IOS-XR, BFD parameters (multiplier, min-interval) can be configured for all BGP
neighbors (under the BGP process) or for a specific BGP neighbor. BFD activation is always
per neighbor.

It is generally not recommended to use BFD for iBGP, when the underlying IGP is already
doing so.
BFD & ISIS

IOS

interface X
bfd interval 150 min_rx 150 multiplier 3 isis bfd

or

IOS

router isis 1
bfd all-interfaces

!
interface X

bfd disable

IOS-XR

router isis 1
interface X

bfd minimum-interval 150 bfd multiplier 3

bfd fast-detect ipv4

BFD & OSPF

IOS

interface X
bfd interval 150 min_rx 150 multiplier 3 ip ospf bfd

or
306 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

IOS

router ospf 1
bfd all-interfaces

!
interface X

bfd disable

IOS-XR

router ospf 1
area 0
interface X

bfd minimum-interval 150 bfd multiplier 3

bfd fast-detect ipv4

BFD parameters can also be configured directly under the ospf process.
BFD establishes sessions from a neighbor to a DR or BDR, only when the neighbor state is
full.

BFD does not establish sessions between DR-Other neighbors (for example, when their
OSPF states are both 2-way)
BFD & RSVP-TE/FRR

IOS

ip rsvp signalling hello bfd

!
interface X

bfd interval 300 min_rx 300 multiplier 3 ip rsvp signalling

hello bfd

IOS-XR

mpls traffic-eng

interface TenGigE0/0/0/0

bfd fast-detect

!
bfd minimum-interval 150 bfd multiplier 3

IOS relates the BFD configuration to RSVP configuration, while IOS-XR relates it to MPLS
TE configuration.
307 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

IOS

R3#sh bfd neighbors detail

NeighAddr LD/RD RH/RS State Int 12.3.4.4 1/1 Up Up Fa0/0.34

Session state is UP and using echo function with 300 ms
interval. OurAddr: 12.3.4.3
Local Diag: 0, Demand mode: 0, Poll bit: 0
MinTxInt: 1000000, MinRxInt: 1000000, Multiplier: 3
Received MinRxInt: 1000000, Received Multiplier: 3
Holddown (hits): 0(0), Hello (hits): 1000(17)
Rx Count: 15, Rx Interval (ms) min/max/avg: 1/996/834 last:
312 ms ago Tx Count: 18, Tx Interval (ms) min/max/avg:
1/1000/845 last: 344 ms ago Elapsed time watermarks: 0 0
(last: 0)
Registered protocols: CEF TE/FRR
Uptime: 00:00:11

Last packet:

Version: 1
State bit: Up
Poll bit: 0
Multiplier: 3
My Discr.: 1
Min tx interval: 1000000 Min Echo interval: 300000

- Diagnostic: 0
- Demand bit: 0
- Final bit: 0
- Length: 24

- Your Discr.: 1
- Min rx interval: 1000000

BFD & IPv6

BFD for IPv6 (BFDv6) is not supported in IOS-XR < 4.1.

BFDv6 supports both global and link-local IPv6 addresses for neighbor session creation.
BFDv6 sessions select automatically source addresses to match the neighbor address types.
Each type of IPv6 address on the local router must be paired with the same type on the peer
router.

You can have an IPv6 static route (2001:DB8::/64) pointing to a peer router associated with a
BFD neighbor (2001::1). In order to remove this IPv6 static route from the RIB if the BFD
neighbor goes down, you must associate the static route with the BFD neighbor

IOS

ipv6 route 2001:DB8::/64 Ethernet0/0 2001::1 ipv6 route static

bfd Ethernet0/0 2001::1

In BFD associated mode (default), an IPv6 static route is automatically associated with an
IPv6 BFD neighbor, if the static route next-hop matches exactly the static BFD neighbor. If
you want to avoid this, you can configure the static route as "unassociated".

308 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

QoS
Congestion Management
o WFQ (Weighted Fair Queuing)

fair-queue
o CQ (Custom Queuing)

custom-queue o PQ (Priority Queuing)

priority-queue
o CBWFQ (Class-Based WFQ)

MQC&bandwidth
o LLQ (Low Latency Queuing)

MQC&priority Congestion Avoidance

o Tail-Drop
default

o WRED (Weighted Random Early Detection) random-detect

o Class-Based WRED
MQC&random-detect

Don't forget the set the interface "max-reserved-bandwidth" if more than 75% is
required.
Weighted Fair Queuing

 configure congestion threshold

 configure dynamic queues
 configure reservable queues

IOS

interface Serial2/0 fair-queue 512 256 128

IOS

R2#sh queueing fair

Current fair queue configuration:

Interface
Serial2/0
Discard
threshold
512
Dynamic
queues
256
Reserved
queues
128

Link Priority queues queues

8 1

309

NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

R2#sh queueing int s2/0

Interface Serial2/0 queueing strategy: fair

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output

drops: 0 Queueing strategy: weighted fair
Output queue: 0/1000/512/0 (size/max total/threshold/drops)

Conversations 0/0/256 (active/max active/max total) Reserved

Conversations 0/0 (allocated/max allocated) Available
Bandwidth 1158 kilobits/sec

Custom Queuing

 assign packets/protocols to the 16 queues

 configure custom queue parameters
 assign custom queue to interface

Not applicable to subinterfaces.

IOS

queue-list 1 protocol ip 0 list 100 queue-list 1 protocol

ipv6 1 queue-list 1 protocol pppoe 2 queue-list 1 default
3

!
queue-list 1 queue 0 byte-count 5000 limit 500 queue-list
 1 queue 1 byte-count 2500 limit 250 queue-list 1 queue 2
byte-count 1500 limit 150 queue-list 1 queue 3 byte-count
1500 limit 50 !
interface FastEthernet0/0

custom-queue-list 1

IOS

R4#sh queueing custom

Current custom queue configuration:

List 1
1
1
1 1 1 1 1

Queue 3
2
1

2 0 1 2 3

Args
default
protocol ip
protocol ipv6
protocol pppoe-sessi byte-count 5000 limit 500 byte-count 2500
limit 250 limit 150
limit 50

list 100

310

NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

R4#sh queueing int fa0/0

Interface FastEthernet0/0 queueing strategy: custom

Output queue utilization (queue/count)

0/680 1/0 2/48085 3/1 4/0 5/0 6/0 7/0 8/0 9/0 10/0 11/0 12/0
13/0 14/0 15/0 16/0

Priority Queuing

 assign packets/protocols to the 4 priority queues

 configure priority queue parameters
 assign priority queues to interface

Not applicable to subinterfaces.

IOS

priority-list 1 protocol ip high list 100 priority-list 1

protocol ipv6 medium priority-list 1 protocol pppoe
normal priority-list 1 default low
 !
priority-list 1 queue-limit 500 250 150 50 !interface
FastEthernet0/0

priority-group 1

IOS

R4#sh queueing priority

Current DLCI priority queue configuration: Current
priority queue configuration:

List Queue
1 low
1 normal
1 medium
1 normal
1 high

Args
default
protocol ip
protocol ipv6 protocol pppoe-sessi limit 500

list 100

1 medium limit 250 1 normal limit 150 1 low limit 50

R4#sh queueing int fa0/0

Interface FastEthernet0/0 queueing strategy: priority

Output queue utilization (queue/count) high/2349 medium/0

normal/48090 low/2

311

NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

WRED

 choose between dscp and precedence WRED

 configure dscp/prec parameters

IOS

interface Serial2/0 random-detect dscp-based

IOS

R2#sh queueing int s2/0

Interface Serial2/0 queueing strategy: random early
detection (WRED)

Exp-weight-constant: 9 (1/512) Mean queue depth: 0

dscp

11. af11  0/0

12. af12  0/0
13. af13  0/0

21. af21  0/0

22. af22  0/0
23. af23  0/0

31. af31  0/0

32. af32  0/0
33. af33  0/0

41. af41  0/0

42. af42  0/0
43. af43  0/0

1. cs1  0/0
2. cs2  0/0
3. cs3  0/0
4. cs4  0/0
5. cs5  0/0
6. cs6  0/0
7. cs7  0/0

ef 0/0
rsvp 0/0

default 0/0

Random drop
pkts/bytes
Tail drop
pkts/bytes

0/0 33 0/0 28 0/0 24 0/0 33 0/0 28 0/0 24 0/0 33 0/0 28 0/0 24

0/0 33 0/0 28 0/0 24 0/0 22 0/0 24 0/0 26 0/0 28 0/0 31 0/0 33
0/0 35 0/0 37 0/0 37

0/0 20

Minimum Maximum Mark thresh thresh prob

40 1/10
40 1/10
40 1/10
40 1/10
40 1/10
 40 1/10
40 1/10
40 1/10
40 1/10
40 1/10
40 1/10
40 1/10
40 1/10
40 1/10
40 1/10
40 1/10
40 1/10
40 1/10
40 1/10
40 1/10
40 1/10
40 1/10

If WRED is used for a used-defined class, then bandwidth reservation must be made too.

If WRED is used for the default class, then either bandwidth reservation of fair-queue must
be used too.

312 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Other
These topics are not considered critical because they aren't usually used as a base for
something else, but they can easily give you some points if configured correctly.

Having a general idea is probably enough, as long as you know where to look in the
documentation for the details.

MAC accounting

Use it to collect statistics about traffic per mac address.

IOS

interface FastEthernet0/0
ip accounting mac-address input ip accounting mac-address
output
IOS-XR

interface TenGigE0/2/0/0 mac-accounting ingress mac-accounting

egress

IP/precedence accounting

Use it to collect statistics about traffic per ip address or per ip precedence.

IOS

R3(config-subif)#ip accounting ?
access-violations Account for IP packets violating access
lists on
this

output-packets precedence <cr>

IOS

interface
Account for IP packets output on this interface Count packets
by IP precedence on this interface

R3(config)#ip ?
Global IP configuration subcommands: ...

accounting-list Select hosts for which IP accounting

information is

313 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

kept
accounting-threshold Sets the maximum number of accounting
entries

accounting-transits Sets the maximum number of transit entries

...

carrier-delay
For fast convergence use low (or 0) timers, especially for the down timer.
For cpu optimization (after routing instability due to small interface flaps) use higher timers.

i.e. if there is a backup circuit available:

IOS

interface FastEthernet0/0 carrier-delay msec 50

IOS-XR

interface TenGigE0/2/0/0 carrier-delay down 0 up 3000

IP event dampening

It's a mechanism to suppress the effects of excessive interface flapping events on routing
protocols and routing tables.

Parameters:






half-life period
o the penalty is reduced by half after each half-life period (assuming the interface has
stopped

flapping)
o default: 5 sec

reuse threshold
o when the penalty drops to the reuse threshold, the route is unsuppressed o default: 1000
penalties

suppress threshold
o when the accumulated penalty reaches the suppress threshold, the interface is placed in the

dampened state and the route is suppressed o default: 2000 penalties

max suppress

o o

the maximum amount of time an interface can remain dampened when a penalty is assigned
to it
default: 4 x half-life sec

314

NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

restart penalty
o initial penalty applied to an interface when it comes up after a router reload o default:
2000 penalties

In Cisco software, default penalty is 1000.

IOS

interface FastEthernet0/0 dampening 30 2000 5000 60

R3#sh interfaces dampening FastEthernet0/0

Flaps Penalty Supp ReuseTm Restart

HalfL

ReuseV

SuppV

MaxSTm MaxP

0 0 FALSE 0 30 2000 5000 60 8000 0

IOS-XR

interface TenGigE0/2/0/0 dampening 1 2000 5000 2

IOS-XR half-life and max-suppress values are in mins, while in IOS they are in secs.

Use"debug dampening interface"toverifythedampeningprocedure.

preconfigure interfaces

If you don't have the actual linecards and/or interfaces, you can use preconfiguration in order
to create interfaces in advance, which is a nice way of testing configurations.

IOS-XR

CRS(config)#int preconfigure pos ?

R/S/I/P Preconfig interface in Rack/Slot/Instance/Port format

Type-7 passwords

You can use a key-chain to recover a type 7 password.

315 NTS for CCIE SP Lab by chatasos

NAT

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

"sh ip nat translations"showstranslationforbothglobalroutingtableandVRFs.

Youcanuse"ip nat inside"onaninterfaceevenwhenthetrafficpassingthroughitislabeled.

IP SLA

IP SLA uses active traffic monitoring for measuring network performance. The information
collected includes data about:

 response time
 one-way latency
 jitter
 packet loss
 voice quality scoring
 network resource availability
 application performance
 server response time

Configuration Steps

 Enable the IP SLAs responder (if required)

 Configure the required IP SLAs operation type
 Configure any options available for the specified IP SLAs operation type
 Configure threshold conditions (if required)
 Schedule the operation to run
 Collect the statistics

You can use the following command to find the supported operation types to use for
SLA:

IOS

R1#sh ip sla application

IP Service Level Agreement Technologies

Version: Round Trip Time MIB 2.2.0, Infrastructure

Engine-II

Supported Operation Types:

802.1agEcho VLAN, EVC, Port, 802.1agJitter VLAN, EVC,
Port dhcp, dns, echo, ftp, http, jitter, lspGroup,
lspPing lspPingPseudowire, lspTrace, , pathEcho,
pathJitter tcpConnect, udpEcho
Supported Features:
IPSLAs Event Publisher
316

NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Common parameters:

frequency (sec)
o the rate at which a specified IP SLAs operation repeats

request-data-size (bytes)
o the protocol data size in the payload of an IP SLAs operation's request packet

threshold (msec)
o the upper threshold value for calculating network monitoring statistics

timeout (msec)
o the amount of time an IP SLAs operation waits for a response from its request packet

It's obvious that if you set the timeout < threshold, then you'll never get over-threshold
statistics.

Configuration

IOS

ip sla 1
icmp-echo 2.2.2.2 timeout 40 threshold 20 frequency 30
ip sla schedule 1 life 600 start-time now Verification

IOS

R1#sh ip sla statistics detail

Round Trip Time (RTT) for Type of operation: icmp-echo

Latest RTT: 20 ms

Index 1

Latest operation start time: *13:25:14.311 UTC Sun Jan 26 2014

Latest operation return code: OK
Over thresholds occurred: FALSE
Number of successes: 1

Number of failures: 0
Operation time to live: 588 sec
Operational state of entry: Active
Last time this entry was reset: *13:25:14.307 UTC Sun Jan 26
2014

R1#sh ip sla statistics detail

Round Trip Time (RTT) for Index 1 Type of operation: icmp-echo

Latest RTT: NoConnection/Busy/Timeout

Latest operation start time: *13:25:44.311 UTC Sun Jan 26 2014

Latest operation return code: Timeout
Over thresholds occurred: FALSE
317 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Number of successes: 1
Number of failures: 1
Operation time to live: 549 sec
Operational state of entry: Active
Last time this entry was reset: *13:25:14.307 UTC Sun Jan 26
2014

R1#sh ip sla statistics detail

Round Trip Time (RTT) for Index 1 Type of operation: icmp-echo

Latest RTT: 24 ms

Latest operation start time: *13:26:44.311 UTC Sun Jan 26 2014

Latest operation return code: Over threshold
Over thresholds occurred: TRUE
Number of successes: 1

Number of failures: 3
Operation time to live: 505 sec
Operational state of entry: Active
Last time this entry was reset: *13:25:14.307 UTC Sun Jan 26
2014

If you want to change the parameters of an already running sla operation, you have to remove
its schedule first

and then change it.

If you want to change the type of an already existing sla operation, you have to remove it
completely and start

over.
IP SLA Responder

The IP SLA Responder listens on a specific port (UDP 1967) for control protocol messages
sent by a IP SLAs operation. Upon receipt of the control message, the responder will enable
the specified UDP or TCP port for the specified duration.

It can help avoid measuring the processing delay and provide larger accuracy, because it
allows the target device to take two time stamps both when the packet arrives on the interface
at interrupt level and again just as it is leaving, eliminating the processing time.

One-way jitter measurements do not require clock

synchronization.

To capture one-way delay measurements, NTP must be enabled on both the source router and
target router

and their clocks need to be synchronized to the same clock source (with the ability to
configure a clock

tolerance for operations with microsecond precision).

318 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Configuration

R1

IOS

ip sla 2
udp-jitter 2.2.2.2 4444 timeout 2000
frequency 30

ip sla schedule 2 life 300 start-time now

R2

IOS

ip sla responder

Verification

IOS

R1#sh ip sla statistics detail

Round Trip Time (RTT) for Type of operation: jitter Latest

RTT: 22 ms

Index 2
Latest operation start time: *13:41:02.579 UTC Sun Jan 26 2014
Latest operation return code: OK
RTT Values

Latency

Number Of RTT: 10
RTT Min/Avg/Max: 5/22/37 ms
one-way time milliseconds
Number of Latency one-way Samples: 0
Source to Destination Latency one way Min/Avg/Max: 0/0/0 ms
Destination to Source Latency one way Min/Avg/Max: 0/0/0 ms
Source to Destination Latency one way Sum/Sum2: 0/0
Destination to Source Latency one way Sum/Sum2: 0/0

Jitter time milliseconds

Number of SD Jitter Samples: 9

Number of DS Jitter Samples: 9

Source to Destination Jitter Min/Avg/Max: 1/10/24 ms
Destination to Source Jitter Min/Avg/Max: 0/5/20 ms
Source to destination positive jitter Min/Avg/Max: 3/10/24 ms
Source to destination positive jitter Number/Sum/Sum2:
3/31/601 Source to destination negative jitter Min/Avg/Max:
1/9/16 ms Source to destination negative jitter
Number/Sum/Sum2: 6/55/699 Destination to Source positive
jitter Min/Avg/Max: 1/6/20 ms Destination to Source positive
jitter Number/Sum/Sum2: 4/25/411 Destination to Source
negative jitter Min/Avg/Max: 1/5/13 ms Destination to Source
negative jitter Number/Sum/Sum2: 4/20/190 Interarrival
jitterout: 0 Interarrival jitterin: 0
319

NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Over thresholds occurred: FALSE Packet Loss Values

Loss Source to Destination: 0 Source: 0

Out Of Sequence: 0 Tail Drop: 0

Packet Skipped: 0 Voice Score Values

Loss Destination to Packet Late Arrival: 0

Calculated Planning Impairment Factor (ICPIF): 0

Mean Opinion Score (MOS): 0 Number of successes: 3

Number of failures: 0
Operation time to live: 214 sec
Operational state of entry: Active
Last time this entry was reset: *13:40:02.531 UTC Sun Jan 26
2014

IOS

R2#sh ip sla responder

IP SLAs Responder is: Enabled
Number of control message received: 4 Number of errors: 0
Recent sources:

169.254.12.1 [13:41:32.131 UTC Sun Jan 26 2014] 169.254.12.1

[13:41:02.159 UTC Sun Jan 26 2014] 169.254.12.1 [13:40:32.143
UTC Sun Jan 26 2014] 169.254.12.1 [13:40:02.123 UTC Sun Jan 26
2014]

Recent error sources:

IP SLA for MPLS VPN

No major difference exists, you just need to define the VRF to be used for connectivity. Also
it's good practice

to also define the source address of the operation.

Configuration
IOS

ip sla 3
path-echo 10.0.0.2 source-ip 10.0.0.1 vrf VPN
frequency 30

ip sla schedule 3 life 300 start-time now Verification

IOS

R1#sh ip sla statistics detail

Round Trip Time (RTT) for Index 3

320

NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Type of operation: path-echo Latest RTT: 60 ms

Latest operation start time: *14:01:35.903 UTC Sun Jan 26 2014

Latest operation return code: OK
Over thresholds occurred: FALSE
Number of successes: 10

Number of failures: 0
Operation time to live: 0
Operational state of entry: Inactive
Last time this entry was reset: *13:57:05.899 UTC Sun Jan 26
2014

You can always use the following command to verify your IP SLA setup and view the default
values of all parameters not explicitly configured:

IOS

R1#sh ip sla configuration 3

IP SLAs, Infrastructure Engine-II.

Entry number: 3
Owner:
Tag:
Type of operation to perform: path-echo
Target address/Source address: 10.0.0.2/10.0.0.1 Request size
(ARR data portion): 28

Operation timeout (milliseconds): 5000 Type Of Service

parameters: 0x0
Verify data: No
Loose Source Routing: Disabled

Vrf Name: VPN

LSR Path:
Schedule:

Operation frequency (seconds): 30

Next Scheduled Start Time: Start Time already passed Group
Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): 300
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active

Threshold (milliseconds): 5000 Distribution Statistics:

Number of statistic hours kept: 2

Number of statistic paths kept: 5
Number of statistic hops kept: 16
Number of statistic distribution buckets kept: 1 Statistic
distribution interval (milliseconds): 20

History Statistics:
Number of history Lives kept: 0 Number of history Buckets
kept: 15
321 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Number of history Samples kept: 16 History Filter Type: None

Netflow

Netflow can help in:

 network application and user monitoring

 network analysis and planning
 security analysis, accounting and billing
 traffic engineering
 data warehousing and data mining

Netflow key fields:

 Source IP address
 Destination IP address
 Source port number
 Destination port number
 Layer 3 protocol type
 Type of service (ToS)
 Input logical interface

Netflow versions

v1

o initial version v5

o adds support for ASN and flow sequence numbers v7

o special version for old C6k releases v8

o adds support for aggregation caches v9

o adds support for new fields and record types using templates

o adds support for IPv6, multicast, MPLS and BGP next hop v10

o aka IPFIX
v1, v5, v9 are the most common ones.

IPFIX (an IETF standard) is based on netflow v9.

IOS

interface FastEthernet0/0.34

ip flow ingress
ip flow egress
322 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

IOS

R3#sh ip cache flow

IP packet size distribution (20 total packets):

1-32 64 96 128 160 192 224 256 288

320 352 384 416 448 .000 .000 .000 .000 .000

480 .000

.550 .200 .000 .250 .000 .000 .000 .000 .000

512 544 576 1024 1536 2048 2560 3072 3584

4096 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000

IP Flow Switching Cache, 4456704 bytes 4 active, 65532

inactive, 14 added 219 ager polls, 0 flow alloc failures
Active flows timeout in 30 minutes Inactive flows timeout in
15 seconds

IP Sub Flow Cache, 533256 bytes

0 active, 16384 inactive, 0 added, 0 added to flow 0 alloc
failures, 0 force free
1 chunk, 1 chunk added
last clearing of statistics never
4608 .000

Protocol Total Flows Idle(Sec)

-------- Flows /Sec /Flow

TCP-BGP 1 0.0 15.0

UDP-other 8 0.0 15.3

ICMP 1 0.0 15.8

Packets
/Flow
2
1
5
Bytes Packets
/Pkt /Sec
Active(Sec)
/Flow
SrcIf
Pkts
Total:
15.4
SrcIf
Pkts
Fa0/0.37
829F
Fa0/0.37
829E
Fa0/0.37
829D
Fa0/0.34
00B3

SrcIPaddress DstIf 100.01

DstIPaddress
54 0.0 1.9

1 1 1 2

SrcIPaddress
34.3.7.7
34.3.7.7
34.3.7.7
169.254.34.4
DstIf
Fa0/0.34*
Fa0/0.34*
Fa0/0.34*
Local
DstIPaddress
46.0.0.8
46.0.0.8
46.0.0.8
169.254.34.3
Pr SrcP DstP
11 C013
11 C012
11 C011

06 5415

49 0.0 11.7

28 0.0 0.0 100 0.0 8.0

Pr SrcP DstP

323

NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

When using netflow v9, you can include the BGP next-hop with either the peer-as or the
origin-as.

IOS

ip flow-export version 9 origin-as bgp-nexthop ip flow-export

destination 34.0.0.7 3333

IOS

R3#sh ip flow export

Flow export v9 is enabled for main cache

Export source and destination details : VRF ID : Default

Destination(1) 34.0.0.7 (3333)

Version 9 flow records, peer-as bgp-nexthop
5 flows exported in 2 udp datagrams
0 flows failed due to lack of export packet
0 export packets were sent up to process level
0 export packets were dropped due to no fib
0 export packets were dropped due to adjacency issues
0 export packets were dropped due to fragmentation failures
0 export packets were dropped due to encapsulation fixup
failures

You can also define the duration of active/inactive flows before they are exported.

You need to find the right balance between short and large timeouts, taking into account the
cache size and the cpu load.

IOS

ip flow-cache timeout inactive 30 ip flow-cache timeout active

10

Various options are also available for aggregation caches:

IOS

R3(config)#ip flow-aggregation cache ?

as
as-tos
bgp-nexthop-tos destination-prefix destination-prefix-tos
prefix
prefix-port
prefix-tos protocol-port protocol-port-tos

AS aggregation
AS-TOS aggregation
BGP nexthop TOS aggregation Destination Prefix aggregation
Destination Prefix TOS aggregation Prefix aggregation
Prefix-port aggregation
Prefix-TOS aggregation
Protocol and port aggregation Protocol, port and TOS
aggregation

324

NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

source-prefix source-prefix-tos

You can use two export protocols: UDP (default)

o unreliable

o not congestion aware SCTP

Source Prefix aggregation Source Prefix TOS aggregation

o uses reliable, partly-reliable or no reliable transmission o implements congestion control

mechanism

IOS

ip flow-export destination 2.2.2.2 2222

ip flow-export destination 3.3.3.3 3333 sctp

backup destination 4.4.4.4 4444

SCTP is supported in IOS > 12.4(4)T.

MPLS egress netflow

It allows you to capture IP flow information for packets that arrive on a router as MPLS
packets and that are transmitted as IP packets (i.e. PE=>CE direction).

IOS

interface FastEthernet0/0.17 ip vrf forwarding ONE

mpls netflow egress

IOS

R7#sh mpls forwarding-table vrf ONE 10.1.7.0 24 detail

Local Outgoing Prefix

Bytes tag Outgoing Next Hop

tag 18

tag or VC or Tunnel Id Aggregate 10.1.7.0/24[V]

switched

interface

0 MAC/Encaps=0/0, MRU=0, Tag Stack{}

VPN route: ONE

Feature Quick flag set

Per-packet load-sharing

R7#sh ip cache flow

IP packet size distribution (5 total packets):

1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480

.000 .000 .000

1.00 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000

325 NTS for CCIE SP Lab by chatasos

Netflow for Layer 2

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

512 544 576 1024 1536 2048

2560 .000 .000 .000 .000 .000 .000 .000

IP Flow Switching Cache, 278544 bytes 1 active, 4095 inactive,

1 added
4 ager polls, 0 flow alloc failures Active flows timeout in 30
minutes Inactive flows timeout in 15 seconds

3072 3584 4096 4608

.000 .000 .000 .000

IP Sub Flow Cache, 25800 bytes

1 active, 1023 inactive, 1 added, 1 added to flow 0 alloc
failures, 0 force free
1 chunk, 1 chunk added
last clearing of statistics never

Protocol
Idle(Sec)
--------
/Flow
SrcIf
Pkts
Fa0/0.37
0800

Total Flows Packets Bytes Packets Active(Sec)

5

Flows

SrcIPaddress
10.0.0.3

/Sec /Flow /Pkt /Sec

/Flow

Pr SrcP DstP
01 0000
DstIf
Fa0/0.17*
DstIPaddress
10.0.0.1

You can also capture some extra fields that include L2 information, like below:

IOS

R3(config)#ip flow-capture ?
fragment-offset Capture the fragment offset
icmp Capture the ICMP type and code
ip-id Capture the IP id
mac-addresses Capture src and dst MAC addresses packet-length
Capture the max and min packet length ttl Capture the TTL
vlan-id Capture the VLAN id

IOS

R3#sh ip cache verbose flow IP packet size distribution 1-32

64 96 128 160

(229 total packets):

192 224 256 288 320 352 384 416 448

.000 .000 .000 .000 .000 .000 .000 .000 .000

2048 2560 3072 3584 4096 4608 .000 .000 .000 .000 .000 .000

480 .000

.427 .528 .000 .043 .000

512 544 576 1024 1536 .000 .000 .000 .000 .000
326

NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

IP Flow Switching Cache, 4456704 bytes

2 active, 65534 inactive, 158 added 3870 ager polls, 0 flow
alloc failures Active flows timeout in 10 minutes Inactive
flows timeout in 30 seconds

IP Sub Flow Cache, 533256 bytes

6 active, 16378 inactive, 47 added, 43 added to flow 0 alloc
failures, 0 force free
1 chunk, 1 chunk added
last clearing of statistics never

Protocol Total
Idle(Sec)
-------- Flows
/Flow
TCP-BGP 57
25.2
UDP-other 98
15.7

ICMP 1 15.8
Total: 156 19.1

Flows
/Sec
0.0
0.0
0.0
0.0
Packets
/Flow
2
1
5
1
Bytes Packets
/Pkt /Sec
49 0.0
28 0.0
100 0.0
41 0.0
Active(Sec)
 /Flow
13.4
0.0
8.0
4.9

Pr TOS B/Pk

Pr TOS B/Pk

01 00

(034) 0

06 C0

(000)

SrcIf SrcIPaddress Flgs Pkts

Port Msk AS
Active

BGP: BGP NextHop

SrcIf SrcIPaddress Flgs Pkts

Port Msk AS
Active

DstIf
Port Msk
DstIf
Port Msk
Fa0/0.34*
0800 /32

(037)

Local
00B3 /32

(034)

AS

AS

248

0
DstIPaddress
NextHop
DstIPaddress
NextHop
46.0.0.4
169.254.34.4

ca06.13bc.0000 ICMP code:

169.254.34.3
0.0.0.0

0000.0000.0000

BGP: BGP NextHop Fa0/0.37 34.3.7.7 10 5

0000 /24 0
100 7.9
BGP: 169.254.34.4 FFlags: 01
MAC: (VLAN
ICMP type:

id) c208.0618.0000 8

Fa0/0.34
18 2
5415 /32 0
49 17.9
BGP: 0.0.0.0
MAC: (VLAN id) ca06.13bc.0000

169.254.34.4

327

NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

Netflow for IPv6

You can also export IPv6 flows, like the IPv4 ones.

IOS

interface X

ipv6 flow ingress

 ipv6 flow egress

!
ipv6 flow-export destination 5.5.5.5 5555

The same flow parameters apply to IPv6 as well.

An extra option is the ability to specify a minimum mask for prefixes, in order to define the
detail of addresses.

Netflow for IPv6 is supported in IOS > 12.3.(7)T.

Netflow for multicast

ingress
o information about the source and how many times the traffic was replicated o packets that
fail RPF check

egress
o information about the destination of the traffic flow

IOS

ip multicast netflow output-counters ip multicast netflow rpf-

failure

You also need to enable normal netflow under the relevant interfaces.

Links

 IETF - RFC 3954

 IETF - RFC 7011
 IETF - RFC 7012
328 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

PBB (802.1ah) or MAC-in-MAC

Ingress UNI & Tunnel configuration

IOS

interface X
service instance 10 ethernet

encapsulation dot1q 10

bridge-domain 100 c-mac

service instance 20 ethernet encapsulation dot1q 20 bridge-

domain 200 c-mac

!
interface Y

service instance 10 ethernet encapsulation dot1q 10 bridge-

domain 100 c-mac

service instance 20 ethernet encapsulation dot1q 20

bridge-domain 200
c-mac

virtual 1

destination default 9999.9999.9999

ethernet mac-tunnel

bridge-domain 1111

mac tunnel address service instance 1

ethernet encapsulation dot1ah isid 1000

bridge-domain 100 c-mac

service instance 2 ethernet encapsulation dot1ah isid 2000

bridge-domain 200 c-mac

Egress forwarding can be accomplished using one of the following methods:

L2 bridging with switchport

interface Z
switchport
switchport mode trunk
switchport trunk allowed vlan 1111

L2 bridging with EVC

interface Z
service instance 1 ethernet

encapsulation dot1q 1111 bridge-domain 1111

329 NTS for CCIE SP Lab by chatasos

chatasos (ccie-in-2-months.blogspot.com) – Notes: The Series (NTS) for CCIE SP Lab

EoMPLS

interface vlan 1111

xconnect 10.10.10.10
VPLS

l2 vfi PBB-VFI manual vpn id 1111

neighbor 20.20.20.20 neighbor 30.30.30.30

interface vlan 1111

xconnect vfi PBB-VFI

PBB is supported on 7600.

11 encapsulation mpls

22 encapsulation mpls 33 encapsulation mpls

330

NTS for CCIE SP Lab by chatasos