IS-IS Deployment, Design

Guidelines and
New Features
Shankar Vemulapalli
svemulap@cisco.com
Internet Engineering Support
NANAOG24 © 2002,
2001, Cisco Systems, Inc. All rights reserved. 1
 Agenda
• Scope of the Presentation

• Deployment Scenarios
L1-Only
L2-Only
L1 & L2 With Route Leaking

• Design Considerations
Set Over Load Bit
LSP Flooding
SPF PRC LSP Generation and MORE

• New Features
Route Leaking
Route Tags
Extensions to MPLS-TE and MORE
NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 2
 Scope of the Presentation

• Cover the Deployment Scenarios adopted by the

ISPs in deploying IS-IS.

• Talk about the Design Guidelines which applies

to the different deployment scenarios .

• Also cover the recent new enhancements to the

IS-IS Protocol.

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 3

 Why IS-IS ?

• Embraced by the large tier1 ISPs.

• Proven to be a very stable and scalable, with very fast

convergence.

• Encodes the packet(s) in TLV format.

• Flexible protocol in terms of tuning and easily

extensible to new features (MPLS-TE etc).

• It runs directly over Layer 2. (next to IP).

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 4
 Deployment Scenarios

NANAOG24 © 2002,
2001, Cisco Systems, Inc. All rights reserved. 5
 L1-Only POPs

POP 1 POP 2
L1-Only L1-Only

CORE
L1-Only

POP 3 POP 4
L1-Only L1-Only

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 6

 L1-Only POPs (Cont.)

• IS-IS is a newer protocol at that time at least

operationally with the ISPs
• In this design—all the routers will be running
in one area and are all doing L1-only routing
• This design is flat with a single L1-only
database running on all the routers
• If you have a change in the topology, the SPF
computation will be done in all the routers as
they are in the L1-only sub-domain

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 7

 L1-Only POPs (Cont.)

• Also the Tier 1 ISPs picked up L1-only to

avoid sub-optimal routing problems
[before Route-Leaking]

• The other factor is when the router runs

as L1L2—then the router(s) will have 2
instances of SPFs

• Since most of the routers were AGS+/7XXX

at that time, the ISPs had chosen L1-only
single-area IS-IS with in their network
NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 8
 L2-Only POPs (all in the same area)

POP 1
Area 49.0001 POP 2
Area 49.0001

CORE
L2-Only

POP 4
POP 3
Area 49.0001
Area 49.0001

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 9

 L2-Only POPs
(Each POP in a different area)

POP 1
Area 49.0001 POP 2
Area 49.0002

CORE
L2-ONLY

POP 3 POP 4
Area 49.0003 Area 49.0004

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 10

 L2-Only POPs (Cont.)
• Most of the Tier 1 ISPs are running
Level 2-only on all the routers [mid 90’s to late 90’s]

• The rough approximation of routers L2-only are

about 800–1000

• The SPF-computation may take up to ~150 msecs.

[ for +/- 1200 routers ]

• Most of the uplinks into the core are OC-12 to OC-192

POS links

• As the network grows, easy to bring the

L1-only POPs for easy migration.

• All the routers in L2 will share all the LSPs

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 11
 L2-Only POPs (Cont.)

• A typical optimized IS-IS configuration that a tier1 ISP uses:

 set-overload-bit [on-startup [<timeout> | wait-for-bgp] ]

 max-lsp-lifetime 65535
 isp-refresh-interval 65000
 spf-interval 10
 prc-interval
 metric-style wide
 [no] hello-padding [either turned globally or
per-interface basis]
 log-adjacency-changes
 ignore-lsp-errors

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 12

 L1 in the POP and L2 in the Core

POP 1 L1L2 L1L2 POP 2

L1-Only L1-Only
Area 49.0001 L1L2 L1L2 Area 49.0002

CORE
L2-Only
Area 49.0005 L1L2
L1L2

L1L2
L1L2 POP 4
POP 3 L1-Only
L1-Only Area 49.0004
Area 49.0003

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 13

 L1 in the POP and L2 in the Core (Cont.)

• Within a given local pop—all the routers will be in

a separate area
• The L1L2 routers at the edge of the POPs will
be running
L1-adj going into the POP
L2-adj into the core with the rest of the L1L2 routers
• The SPF computations will be limited to the
respective L1 and L2 Areas only.
• All the L1-routers in a given pop will receive the ATT
bit set by the L1L2 router at the edge of this pop
• This may cause the sub-optimal routing in reaching
out the prefixes outside the POP by the local routers.

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 14

 L1 in the POP and L2 in the Core (Cont.)
Route-Leaking

• It is recommended to configure the L1L2 routers at

the edge of the pop with route-leaking capabilities
• This way, we leak the longer prefixes of the remote
pop into the local pop
• Hence the L1 routers will be able to take the
right exit router based on the metric of the leaked
IP-prefix
• Whenever you configure for route-leaking—make
sure you configure the routers with metric-style wide

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 15

 Design Considerations

NANAOG24 © 2002,
2001, Cisco Systems, Inc. All rights reserved. 16
 Set Over Load Bit

• 10589 defines for each LSP a special bit

called the LSPDB Over Load Bit
• While having problems, a router could set
the OL bit, and other routers would route
around it
• Connected IP prefixes still reachable
This may change in the future

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 17

 Set Over Load Bit

Rtr-2 Rtr-1 When R1 computes SPT, it will find

That R5 LSP has Overload-bit-set.
Therefore R5 cannot be used as
Transit node and shortest path to R4 is:
R1->R2->R3->R4

Rtr-3 Rtr-5
• Why/When use Overload-Bit ?
 When the router is not ready to forward
Rtr-4 traffic for ALL destinations

 Typically when IS-IS is up but BGP (or even

MPLS) not up yet.

 When the router has other functions

(Network Management)
NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 18
 Set Over Load Bit (Cont.)

• Feature to assist routers in completing

their BGP tables after boot-up
• BGP may not have had time to fully
converge before receiving traffic
• Therefore router may drop traffic for
destinations not learnt yet via BGP
• Better stabilization if router could build
its BGP table before fully participating
in packet forwarding
NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 19
 Set Over Load Bit (Cont.)

router isis
set-overload-bit
set-overload-bit on-startup <sec>
set-overload-bit on-startup wait-for-bgp
router bgp 100
bgp update-delay <sec>

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 20

 Set Over Load Bit (Cont.)

• Enhanced configuration:
router isis
set-overload-bit [on-startup[<timeout>|wait-for-bgp]]

• New keyword “wait-for-bgp”

• When BGP doesn’t inform IS-IS it is ready
and “wait-for-bgp” is configured, the over
load bit will be cleared after 10 minutes.

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 21

 LSP Flooding

• ISO 10589 states LSP flooding on a LAN

should be limited to 30 LSP’s per second
• IOS throttles over both LAN and point-to-
point interfaces
• Default time between consecutive LSP’s
is a minimum of 33 milliseconds
• On slow speed links, 30 LSP’s per second
may be too much

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 22

 LSP Flooding (Cont.)

• Time between flooding consecutive LSP’s

is configurable:
Rtr-A(config)#int serial0
Rtr-A(config-if)#isis lsp-interval?
<1-4294967295> LSP transmission interval (milliseconds)

• IS-IS will now send LSP’s only up to 50% of the

configured bandwidth
• Therefore, advisable to configure the bandwidth
parameter on links below T1

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 23

 LSP Flooding (Cont.)

• Several interface configuration commands

isis lsp-interval 33
delay between LSP transmission interval (flooding) (msecs)

isis retransmit-interval 5
delay between retransmissions of the same LSP (seconds)

isis retransmit-throttle-interval 100

delay between retransmitted LSPs (msecs)

isis mesh-group blocked

block LSP flooding on this interface

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 24

 LSP Flooding (Cont.)

• LAN flooding usually doesn’t encounter any

problem
• No retransmission over LANs
• No ACKs on LANs; DIS only sends periodic
CSNPs
• Reduce CSNP timer for faster convergence over
a LAN
int ethernet 1/0
isis csnp-interval <0-65535>

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 25

 LSP Generation: What triggers a new LSP

• When something changes …

 adjacency came up or went down
 interface up/down (connected IP prefix !)
 redistributed IP routes change
 inter-area IP routes change
 an interface is assigned a new metric
 most other configuration changes
 periodic refresh

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 26

 LSP Generation: New LSP

• Create new LSP, install in your own

LSPDB and mark it for flooding

• Send the new LSP to all neighbors

• Neighbors flood the LSP further.

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 27

 LSP Generation

• LSP generation (lsp-gen-interval)

Control the “frequency” of LSP generation
Prevent from flapping links causing a lot of
LSPs to be flooded throughout the network
• IS-IS throttles it main events SPF/PRC
computation, LSP generation
• Throttling slows down convergence
• Not throttling can cause melt-downs
• Find a compromise…

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 28

 Exponential Backoff:
Enhancements to SPF Algorithms

SPF PRC LSP

Generation

Maximum-Interval 10 Sec 5 Sec 5 Sec

Initial-Wait 5.5 Sec 2 Sec 50 msec

Incremental-Interval 5.5 Sec 5 Sec 5 Sec

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 29

 Exponential Backoff:
spf-interval

• Extended syntax
spf-interval <a> [<b> <c>]

<a> seconds between consecutive SPF runs(seconds)

<b> initial wait before the first SPF (msecs)
<c> minimum wait between first and second SPF (msecs)

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 30

 Exponential Backoff:
spf-interval Example

spf-interval 10 100 1000

(a) (b) (c)

 On original trigger a delay of 100 ms is incurred prior

to running SPF.

 If a 2nd SPF is required, a delay of at least

1000msecs must expire.

 The 3rd SPF can only be run after another 2s, then
4s, then 8s, then 10 sec, 10 sec

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 31

 Exponential Backoff:
spf-interval Example

• When the network calms down, and there

were no triggers for 2 times the minimum
interval (20sec in this example), go back to
fast behavior (100 ms initial wait)

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 32

 Exponential Backoff:
prc-interval and lsp-gen-interval

• Same Syntax for

 prc-interval
 lsp-gen-interval

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 33

 Hello Padding

• IS-IS by default pads the Hellos to the fullest

MTU size to detect the MTU mismatches.

• This results in:

 Inefficient use of bandwidth
 May use significant number of buffers
 Processing overhead when using Authentication

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 34

 Hello Padding

• You can turn on/off the Hello-Padding either

per interface level or via globally

• The router isis CLI:

[no] hello padding [multi-point|point-to-point]

• The Interface CLI:

[no] isis hello padding

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 35

 Database Timers

Timer Default Value Cisco IOS Command

Maxage 1200s isis max-lsp-Interval

LSP Refresh Interval 900s isis refresh-interval

LSP Transmission Interval 33ms isis lsp-interval

LSP Retransmit Interval 5s isis retransmit-interval

CSNP Interval 10s isis csnp-interval

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 36

 Database Timers (Cont.)
• Note: On high lifetime values

 The high lifetime values need to be used carefully

even though they provide robustness in the network.

 Using high lifetimes may result in keeping obsolete

information in LSPDB for more time than needed.

 Having such useless LSPs in database is harmless

anyway but should be aware of the above drawback.
NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 37
 Non-Advertisement of Parallel
Adjacencies in the LSP

• When building an IS-IS LSP all adjacencies

are inserted from the DB
• Parallel adjacencies may therefore be
included and advertised in the LSP
• Not necessary—only need to advertise
parallel pt2pt adjacencies once
• Only use best connection between two
routers for SPF (unequal path metrics)

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 38

 Non-Advertisement of Parallel
Adjacencies in the LSP (Cont.)

• Number of advantages for not advertising

parallel adjacencies
LSP’s will be smaller and use less bandwidth
when flooded
LSP’s have lower chances of being fragmented
SPF calculations will be more efficient
Flapping of one of a set of parallel links will be
invisible to the rest of the network

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 39

 Non-Advertisement of Parallel
Adjacencies in the LSP (Cont.)
Rtr-A Rtr-B
LSP A 5 LSP B
IS: 5 B IS: 5 A
IS: 3 B 3 IS: 3 A
IS: 3 C IS: 6 C
IS: 5 D IS: 2 D
3
2
Rtr-C Rtr-D

Only the best Parallel Adjacency is reported

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 40

 New Features

NANAOG24 © 2002,
2001, Cisco Systems, Inc. All rights reserved. 41
 Dynamic Host Name

• All ISPs configure STATIC mappings of system-IDs

• This process has dis-adv of maintaining
huge (identical) databases on all the routers
• Adding a router to the network, means updating this
static mappings on all
the routers
• Human mistake(s)
Router-A(config)# clns host <name> <nsap>

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 42

 Dynamic Host Name (Cont.)

• A New TLV 137

• RFC 2763
• Floods the host names dynamically
• show isis topology shows the NSAPs
getting dynamically mapped to the hostname

• Can turn it off using

[no] hostname dynamic

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 43
 Dynamic Host Name (Cont.)
Rules
• Always static CLNS host mappings have higher
preference over dynamically learned mappings

• Static mappings can be seen with “show hosts”

and dynamic mappings can be seen with
“show isis hostname”

• If you remove the static CLNS host-name list on a

router which is capable of dynamic-hostname
exchange—we may not see this router itself in the
‘show isis hostname’ table immediately.

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 44

 Route Leaking

• RFC1195 defines all routers as STUB routers

• No information is leaked from routers in L2
into routers in L1
• Hence all L1-routers are forced to route to the
closest L2-router
• This may result in sub-optimal routing
• This is IP only feature (CLNS still uses STUB)

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 45

 Route Leaking

• This new feature allows redistribution

of L2-IP routes into L1 areas
• Enables Level 1-only routers to pick the
best path to exit the area
• Enables shortest-exit and MED for BGP
• Enables MPLS-VPN (PE reachability)
between areas
• Redistribution is controlled via
distribute-lists

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 46

 Route Leaking

• Prefixes MUST be present in the routing

table as ISIS level-2 routes
Otherwise no leaking occurs
Same criteria than L1 to L2
Inter-area routing is done through the routing
table

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 47

 Route Leaking

• When leaking routes from L2 backbone

into L1 areas a loop protection mechanism
need to be used in order to prevent leaked
routes to be re-injected into the backbone

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 48

 Route Leaking
1. Level-1 LSP with
L1L2 IP prefix:10.14.0.0/16
L1L2

L1
L1L2
2. Level-2 LSP with IP
prefix: 10.14.0.0/16

L1L2 L1L2
3. Level-1 LSP with IP
prefix: 10.14.0.0/16
Up/Down-bit set 3. At this point prefix
10.14.0.0/16 will be inserted
in L1 LSP since route leaking
L1 is configured AND the prefix is
L1
present in the routing table as
a L2 route

4. At this point prefix

10.14.0.0/16 will NOT be
inserted in L2 LSP since
it has the Down-bit set

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 49

 Route Leaking

3. Level-2 LSP with

IP prefix: 10.1.0.0/16 L1L2
L1L2

4. Level-2 LSP with

IP prefix: 10.1.0.0/16 L1L2 L1

3. Level-1 LSP with

2. Level-2 LSP with IP prefix: 10.1.0.0/16
IP prefix: 10.1.0.0/16 Up/Down-Bit set
2. Level-2 LSP with IP
prefix: 10.1.0.0/16

L1L2 L1L2
5. At this point the prefix
10.1.0.0/16 will NOT be inserted
in the L1 LSP since a L1 route is
preferred in the routing table

L1
1. Level-1 LSP with L1
IP prefix: 10.1.0.0/16

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 50

 Route Leaking

• TVLs 128 and 130 have a metric field that

consists of 4 TOS metrics
The first metric, the so-called "default metric", has the high-
order bit reserved (bit 8) Routers must set this bit to zero on
transmission, and ignore it on receipt

• The high-order bit in the default metric

field in TLVs 128 and 130 becomes the
Up/Down bit

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 51

 Route Leaking

• Recommendation:
use wide Metric TLV (TLV 135)

• Configure with:
router isis
metric-style wide

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 52

 Route Leaking (Cont.)

• Route leaking is implemented in both

12.0S and 12.1
Cisco IOS 12.0S command
advertise ip l2-into-l1 <100-199>
Cisco IOS 12.1 command
redistribute isis ip level-2 into level-1
distribute-list <100-199>

• Both commands are supported

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 53
 Route Leaking (Cont.)

• With this new change, when a user inputs

older command (advertise ip), it will be
changed to the newer syntax.

Router(config-router)#advertise ip l2-into-l1 100

advertise ip l2-into-l1 100
syntax will be converted into
redistribute isis ip level-2 into level-1 distribute-list 100

Commnad Allow Visible Write/NVRAM

OLD+NEW OLD+NEW NEW

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 54

 Extensions for MPLS-TE

• New TLVs have been added for the

support of MPLS-traffic engineering
• For reference they are:
Extended IS neighbor TLV # 22 (consists
of Sub-TLVs)
Extended IP reachability TLV # 135
Router ID TLV # 134
• The IETF draft: draft-ietf-traffic-04.txt
NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 55
 Extensions for MPLS-TE
Extended IS Reachability TLV # 22

# of Octets

System-ID 6

Pseudonode ID 1

Default Metric 3

Length of Sub-TLVs 1

Optional Sub-TLVs 0-244

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 56

 Extensions for MPLS-TE
Extended IS Reachability Sub-TLVs

Sub-TLV #

Administrative Group (color) 3

IPv4 Interface Address 6

IPv4 Neighbor Address 8

Maximum Link Bandwidth 9

Reservable Link Bandwidth 10

Unreserved Bandwidth 11

TE Default Metric 18

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 57

 Extensions for MPLS-TE
Router ID TLV # 134
• Useful as stable address for traffic engineering

# of Octets

Router ID 4

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 58

 Extensions for MPLS-TE

Extended IP Reachability TLV # 135

# of Octets

Metric 4

U/D Sub-TLV Prefix Length 1

IPv4 Prefix 4

Optional Sub-TLVs 0-250

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 59

 Extensions for MPLS-TE

Extended IP Reachability Sub-TLV

Sub-TLV #

1
Administrative TAG

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 60

 Fast Hellos

• Hold-time can be set to 1 second

interface POS0/0
isis hello-interval minimal
• By default hello-multiplier is 3
Hello packets sent every 333 msecs

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 61

 Fast Hellos (Cont.)

• Advantages
Reduced link failure detection time

• Disadvantages
 Increased BW/buffer/CPU usage can cause
missed hellos; potential increased adjacency
flapping can cause instability

 Use no hello padding feature to reduce BW

and buffer usage
NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 62
 dCEF and ISIS

• When CEF disabled on a LC, it should inform

the Routing protocol.

• Since ISIS runs directly on top of L2, it still

keeps the neighbor adjacency(ies) and
doesn’t detect that the LC got disabled for
the CEF.

• Hence black-holing of the traffic.

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 63
 dCEF and ISIS

• Under router-isis
external overload signalling
By default this option is disabled.

[no] external overload signalling

Can be used as a workaround in case dCEF
forgets to pass enable signal to ISIS
when dCEF is actually up.

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 64

 Route Tags

• The IP prefixes can be ‘tagged’ with Color/admin

information.

• This may be useful to control the routes

redistributed between area/domain boundaries.
OR
• Can be used to apply for some policies to the
ISIS Routes.

• This is similar to what BGP is doing with the community

attribute(s).

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 65

 Route Tags

Rtr-C Rtr-B

Rtr-A

Rtr-D
10.1.2.0 /24
10.1.1.0 /24

Rtr C doesn’t differentiate the IP Prefixes

10.1.1.0 vs 10.1.2.0
when it is leaking it to Rtr D
if we wanted to have
some policy applied to these prefixes.
NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 66
 Route Tags

• A New sub-TLV has been defined with a value

of 1 as a part of Extended IP Reachability
TLV 135

• This admin-tag strings attached to the IP prefix

are used to color the ISIS IP routes.

• The IETF Draft:

draft-martin-neal-policy-isis-admin-tags-02.txt

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 67

 Route Tags

• The ‘tag’ can be applied to:

 an interface

 an external route(s)

 while filtering between L1->L2 or L2->L1

 On Summary Addresses
NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 68
 Route Tags

• The interface tagging is:

 isis tag X [X is between 1 & ]

• External-Routes tagging is:

 applied via route-map on a redistributed routes
[static etc]
• Filtering between L1->L2 or L2->L1 is:
 applied via route-map via redistribution option

• Summary Addresses
 summary-addresss [ip prefix, mask] tag [value] metic X

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 69

 Route Tags

• The current implementation supports only

one tag value with the routes.

• The tag value can be seen via:

show isis database detail verbose

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 70

 P2P Adjacencies over Broadcast Media
• When Broadcast interfaces (Ethernet, FE, GE,
FDDI etc) used to connect only two routers,
tell IS-IS to behave as p2p:
 No Need for DIS Election
 Also, no need for CSNPs
 Reduce the number of nodes in SPT
(no Pseudonode)

• The IETF draft:

draft-ietf-isis-igp-p2p-over-lan-00.txt
NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 71
 P2P Adjacencies over Broadcast Media

LAN topology RtrA Rtr-B

DIS

Rtr-A Rtr-B

SPT topology
Pseudonode

• SPF doesn’t know anything about LANs

• All links are p2p

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 72

 P2P Adjacencies over Broadcast Media
Interface fa1/0
isis network point-to-point

LAN topology Rtr-A Rtr-B

SPT topology Rtr-A Rtr-B

• One step less in SPF computation

• No DIS election
• No CSNP flooding
•New CLI command under the interface:
 [no] isis network point-to-point
NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 73
 MPLS-TE
Forwarding Adjacencies with IS-IS

• Ability to advertise the MPLS-TE Tunnels into

the IGP (IS-IS) as a regular link.
• Then, IGP (IS-IS) will treat it as a normal link .
• This is called as “Forwarding Adjacencies”
• FA allows to mask the unequal physical
topologies so that down-stream nodes can
do load balancing to the destination node.
• This is a part of the draft:
draft-ietf-mpls-lsp-hierarchy-03.txt
NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 74
 MPLS-TE
Forwarding Adjacencies with IS-IS

• Following are the caveats to remember: (wrt IS-IS)

 LSP will be put into IS-IS Link State Database

 IS-IS Hello will not run over the TE Tunnel

 IS-IS LSPs wont’ be flooded over the TE Tunnels.

 SPF bi-directional check will be enabled.

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 75

 MPLS-TE
Forwarding Adjacencies with IS-IS
MPLS-TE Tunnel

Rtr-B Rtr-C
Rtr-D
10 10
10 10 Rtr-E

Rtr-A
10 10
Rtr-G 10 Rtr-F

MPLS-TE Tunnel

With FA –
 RtrA & RtrE will know the MPLS-TE Tunnels as an
additional link
 Allows load balancing on the un-equal cost paths.
 Hides the Core topology.
NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 76
 MPLS-TE
Forwarding Adjacencies with IS-IS

• 2 Points to Remember

 FA has the benefit in some particular

cases and is not recommended
everywhere.

 We can not use FAs to do lsp-hierarchy

since there is no TE information on FAs
NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 77
 Suggested Reading

• ISO 10589 (IS-IS Intra-Domain Routing Exchange Protocol)

• RFC 1195
(OSI IS-IS for Routing in TCP/IP and Dual Environments)
• draft-ietf-isis-traffic-04.txt (TE Extensions for IS-IS)
• draft-ietf-isis-igp-p2p-over-lan-00.txt (P2P Adj over LAN)
• RFC 2966 (Route-leaking)
• RFC 2763 (Dynamic Hostname Exchange)
• draft-martin-neal-policy-isis-admin-tags-02.txt (Route Tags)

NANOG24 © 2002, Cisco Systems, Inc. All rights reserved. 78

RST-208
3010_05_2001_c1 © 2001, Cisco Systems, Inc. All rights reserved. 79