1 NANAOG24 © 2001, Cisco Systems, Inc. All rights reserved. © 2002, Cisco Systems, Inc. All rights reserved. IS-IS Deployment, Design Guidelines and New

1NANAOG24 © 2001, Cisco Systems, Inc. All rights reserved.© 2001, Cisco Systems, Inc. All rights reserved.© 2002, Cisco Systems, Inc. All rights reserved.

IS-IS Deployment, Design Guidelines and New Features

Shankar [email protected]

Internet Engineering Support

mailto:[email protected]

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

Agenda

• Scope of the Presentation

• Deployment ScenariosL1-Only

L2-Only

L1 & L2 With Route Leaking

• Design Considerations Set Over Load Bit

LSP Flooding

SPF PRC LSP Generation and MORE

• New FeaturesRoute Leaking

Route Tags

Extensions to MPLS-TE and MORE


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.


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).


Deployment Scenarios


L1-Only POPs

POP 1L1-Only

POP 3L1-Only

COREL1-Only

POP 4L1-Only

POP 2L1-Only


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



• 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


L2-Only POPs (all in the same area)

POP 1Area 49.0001

POP 3Area 49.0001

POP 2Area 49.0001

COREL2-Only

POP 4Area 49.0001


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

POP 1Area 49.0001

POP 3Area 49.0003

POP 2Area 49.0002

CORE

L2-ONLY

POP 4Area 49.0004



• 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



• 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


L1 in the POP and L2 in the Core

POP 1L1-Only

Area 49.0001

POP 3L1-Only

Area 49.0003

POP 2L1-Only

Area 49.0002

COREL2-Only

Area 49.0005

POP 4L1-Only

Area 49.0004

L1L2L1L2

L1L2L1L2

L1L2L1L2

L1L2L1L2

L1L2L1L2

L1L2L1L2L1L2L1L2

L1L2L1L2


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.


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

• 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

Route-Leaking


Design Considerations


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


Set Over Load Bit

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

• Why/When use Overload-Bit ? When the router is not ready to forward 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)

Rtr-1Rtr-2

Rtr-3

Rtr-4

Rtr-5


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



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>



• 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.


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


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



• 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



• 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>


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


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.


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…


Exponential Backoff:Enhancements to SPF Algorithms

SPFSPF

Incremental-IntervalIncremental-Interval

Initial-WaitInitial-Wait

5.5 Sec5.5 Sec

5.5 Sec5.5 Sec

Maximum-IntervalMaximum-Interval 10 Sec10 Sec

PRCPRC

5 Sec5 Sec

2 Sec2 Sec

5 Sec5 Sec

LSPGeneration

LSPGeneration

5 Sec5 Sec

50 msec50 msec

5 Sec5 Sec


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)


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


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)


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

• Same Syntax for

prc-interval

lsp-gen-interval


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


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


TimerTimer Default ValueDefault Value Cisco IOS CommandCisco IOS Command

MaxageMaxage

LSP Refresh IntervalLSP Refresh Interval

LSP Transmission IntervalLSP Transmission Interval

LSP Retransmit IntervalLSP Retransmit Interval

CSNP IntervalCSNP Interval

1200s1200s

900s900s

33ms33ms

5s5s

10s10s

isis max-lsp-Intervalisis max-lsp-Interval

isis refresh-intervalisis refresh-interval

isis lsp-intervalisis lsp-interval

isis retransmit-intervalisis retransmit-interval

isis csnp-intervalisis csnp-interval

Database Timers


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.


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)


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


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

5

3

32

LSP AIS: 5 BIS: 3 BIS: 3 CIS: 5 D

LSP BIS: 5 AIS: 3 AIS: 6 CIS: 2 D

Only the best Parallel Adjacency is reported

Rtr-BRtr-A

Rtr-C Rtr-D


New Features


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>


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


Dynamic Host Name (Cont.)

• 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.

Rules


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)


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


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


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


Route Leaking

L1L2

L1

L1L2 L1L2

L1L2L1

L1L2

L1

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

4. At this point prefix 10.14.0.0/16 will NOT be inserted in L2 LSP since it has the Down-bit set

3. Level-1 LSP with IP prefix: 10.14.0.0/16 Up/Down-bit set

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

3. At this point prefix 10.14.0.0/16 will be inserted in L1 LSP since route leaking is configured AND the prefix is present in the routing table as a L2 route


Route Leaking

L1L2

L1

L1L2

4. Level-2 LSP with IP prefix: 10.1.0.0/16

L1L2

L1L2 L1

L1L2

L11. Level-1 LSP withIP prefix: 10.1.0.0/16

2. Level-2 LSP with IP prefix: 10.1.0.0/16 2. Level-2 LSP with IP

prefix: 10.1.0.0/16

3. Level-1 LSP withIP prefix: 10.1.0.0/16Up/Down-Bit set

3. Level-2 LSP withIP prefix: 10.1.0.0/16

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


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


Route Leaking

• RecommendationRecommendation: use wide Metric TLV (TLV 135)

• Configure with:

router isis metric-style wide


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


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)#Router(config-router)#advertise ip l2-into-l1 100advertise ip l2-into-l1 100 advertise ip l2-into-l1 100advertise ip l2-into-l1 100 syntax will be converted intosyntax will be converted into redistribute isis ip level-2 into level-1 distribute-list 100redistribute isis ip level-2 into level-1 distribute-list 100

Commnad Allow Visible Write/NVRAMCommnad Allow Visible Write/NVRAM

OLD+NEW OLD+NEW NEWOLD+NEW OLD+NEW NEW


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.txtdraft-ietf-traffic-04.txt



Extended IS Reachability TLV # 22

# of Octets# of Octets

System-ID

Default Metric

Length of Sub-TLVs

66

11

33

11

Pseudonode ID

Optional Sub-TLVs 0-2440-244



Extended IS Reachability Sub-TLVs

Sub-TLV #Sub-TLV #

IPv4 Neighbor Address

Maximum Link Bandwidth

33

66

88

99

IPv4 Interface Address

Reservable Link Bandwidth 1010

Administrative Group (color)

Unreserved Bandwidth 11

TE Default Metric 18



Router ID TLV # 134• Useful as stable address for traffic engineering


Router ID 44



Extended IP Reachability TLV # 135


Metric

U/D Sub-TLV Prefix Length

IPv4 Prefix

Optional Sub-TLVs

44

11

44

0-2500-250



Extended IP Reachability Sub-TLV

Sub-TLV #Sub-TLV #

Administrative TAG11


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


Fast Hellos (Cont.)

• AdvantagesReduced 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


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.


dCEF and ISIS

• Under router-isis

external overload signallingexternal overload signalling

By default this option is disabled.By default this option is disabled.

[no][no] external overload signallingexternal overload signalling

Can be used as a workaround in case dCEF Can be used as a workaround in case dCEF

forgets to pass enable signal to ISIS forgets to pass enable signal to ISIS when dCEF is actually up. when dCEF is actually up.


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).


Route Tags

10.1.1.0 /24

10.1.2.0 /24

L1

L1

L2

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.

Rtr-A

Rtr-BRtr-C

Rtr-D


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.txtdraft-martin-neal-policy-isis-admin-tags-02.txt


Route Tags

• The ‘tag’ can be applied to:

an interface an interface

an external route(s)an external route(s)

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

On Summary Addresses On Summary Addresses


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


Route Tags

• The current implementation supports only one tag value with the routes.

• The tag value can be seen via:

show isis database detail verboseshow isis database detail verbose


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.txtdraft-ietf-isis-igp-p2p-over-lan-00.txt



RtrADIS

Rtr-BLAN topology

SPT topologyPseudonode

Rtr-A Rtr-B

• SPF doesn’t know anything about LANs

• All links are p2p



LAN topology Rtr-A Rtr-B

Interface fa1/0 isis network point-to-point

SPT topologyRtr-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[no] isis network point-to-point


MPLS-TEForwarding 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


• 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.




Rtr-A

Rtr-B Rtr-CRtr-D

Rtr-E

Rtr-FRtr-G

10

10

10 10

MPLS-TE Tunnel

MPLS-TE Tunnel

10

10

10

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.


MPLS-TE Forwarding Adjacencies with IS-IS

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

• 2 Points to Remember2 Points to Remember


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 draft-martin-neal-policy-isis-admin-tags-02.txt (Route Tags)(Route Tags)

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

Documents

1 NANAOG24 © 2001, Cisco Systems, Inc. All rights reserved. © 2002, Cisco Systems, Inc. All rights reserved. IS-IS Deployment, Design Guidelines and New