The Complete IS-IS Routing Protocol- P15 ppt

After defining the ERO you need to link it to an existing tunnel using the option explicitargument to the tunnel mpls traffic-eng command.tunnel mode mpls traffic-eng tunnel mpls traffic-

Adspec Object (13) Flags: [reject if unknown], Class-Type: IntServ (2),

Parameter ID: Minimum path latency (8), length: 4, Flags: [0x00]

Minimum path latency: don’t care

Parameter ID: Composed MTU (10), length: 4, Flags: [0x00]

Composed MTU: 1500 bytes

Service Type: Controlled Load (5), break bit not set, Service length: 0

ERO Object (20) Flags: [reject if unknown], Class-Type: IPv4 (1), length: 28 Subobject Type: IPv4 prefix, Strict, 10.154.1.5/32, Flags: [none]

Subobject Type: IPv4 prefix, Strict, 10.154.6.1/32, Flags: [none]

Subobject Type: IPv4 prefix, Strict, 10.254.1.45/32, Flags: [none]

Label Request Object (19) Flags: [reject if unknown], Class- Type: without label range (1), length: 8

12:35:51.199611 IP (tos 0xc0, ttl 255, id 6344, offset 0, flags [none], length: 164) 10.154.1.5 > 10.154.1.6: RSVP

v: 1, msg-type: Resv, length: 144, ttl: 255, checksum: 0x2efc

Session Object (1) Flags: [reject if unknown], Class-Type: Tunnel IPv4 (7), length: 16

IPv4 Tunnel EndPoint: 209.211.134.10, Tunnel ID: 0x0013, Extended

Tunnel ID: 209.211.134.9

RSVP Hop Object (3) Flags: [reject if unknown], Class-Type: IPv4 (1), length: 12 Previous/Next Interface: 10.154.1.5, Logical Interface Handle: 0x0853f4c8 Time Values Object (5) Flags: [reject if unknown], Class-Type: 1 (1), length: 8 Refresh Period: 30000ms

Style Object (8) Flags: [reject if unknown], Class-Type: 1 (1), length: 8

Reservation Style: Fixed Filter, Flags: [0x00]

Flowspec Object (9) Flags: [reject if unknown], Class-Type: IntServ (2),

length: 36

Msg-Version: 0, length: 28

Service Type: Controlled Load (5), break bit not set, Service length: 24 Parameter ID: Token Bucket TSpec (127), length: 20, Flags: [0x00]

Token Bucket Rate: 0 Mbps

Token Bucket Size: 0 bytes

Peak Data Rate: inf Mbps

Minimum Policed Unit: 20 bytes

MPLS Signalling Protocols 411

FilterSpec Object (10) Flags: [reject if unknown], Class-Type: Tunnel IPv4 (7), length: 12

Source Address: 209.211.134.9, LSP-ID: 0x0005

Label Object (16) Flags: [reject if unknown], Class-Type: Label (1), length: 8 Label 12324

RRO Object (21) Flags: [reject if unknown], Class-Type: IPv4 (1), length: 36 Subobject Type: IPv4 prefix, Strict, 10.154.1.5/32, Flags: [none]

Subobject Type: IPv4 prefix, Strict, 10.154.6.1/32, Flags: [none]

Subobject Type: IPv4 prefix, Strict, 10.254.1.45/32, Flags: [none]

Subobject Type: IPv4 prefix, Strict, 10.254.1.2/32, Flags: [none]

The Label Request Object is embedded in a TE PATH message and gives

RSVP-TE the ability to request a label and subsequently return a label using the Label Object in

a RSVP-TE RESV message The Explicit Route Object (ERO) allows RSVP-TE to ify a set of nodes that an RSVP-TE message has to traverse Figure 14.12 shows sample

spec-EROs modelled using the Loose and Strict (L/S) path constraint A Strict hop indicates

that the next hop must be directly connected to the previous hop The first example ofFigure 14.12 shows a set of strict hops that specify a path A sequence of strict hops isoften used to nail down a path – that is, when the network administrator wants to enforce

a certain path A Loose hop means that the node has to be present in the path before the next hop, but does not have to be the next-hop The second example of Figure 14.12

shows that only a subset of the nodes is listed in the ERO With the Loose attribute, thismeans that there is some room for re-routing this path The path could potentially rundirectly from Washington via Frankfurt to Pennsauken In practice, the Loose optioncauses more problems than it solves The network is not in full control of the traffic pathanymore and in more complex topologies this may lead to strange results with long delaypaths The third example in Figure 14.12 shows a mix between loose and strict hops Thesemantics of the ERO Objects allows for the combination of loose and strict hops in anarbitrary fashion

There are two general ways to create an ERO The first is a manual specification andthe second, more sophisticated way, is automated computation The manual configur-ation will be discussed first

You can configure a label switched path using an ERO in similar ways on IOS andJUNOS First you need to specify the ERO and next you need to link the ERO to a labelswitched path

IOS configuration

In IOS you can specify an ERO manually using the ip explicit-path statement The next-address specifies the next-element in the ERO By default all hops in the ERO are strict except when you supply the loose keyword.

ip explicit-path identifier name via-Penssauken enable

next-address 192.168.1.1

next-address loose 192.168.2.1

[…]

MPLS Signalling Protocols 413

Area 49.0001 Level 2-only

ERO

Frankfurt loose;

Pennsauken loose;

Area 49.0001 Level 2-only

After defining the ERO you need to link it to an existing tunnel using the option explicitargument to the tunnel mpls traffic-eng command.

tunnel mode mpls traffic-eng

tunnel mpls traffic-eng autoroute announce

tunnel mpls traffic-eng path-option 5 explicit name via-Penssauken

After you have configured your tunnels, you need to verify if the TE tunnel is up and ifthe tunnel is following the desired path Because awkward combination of the Loose andStrict Hop option can cause unexpected results – the Record Route Object (RRO) pro-vides better visibility for troubleshooting purposes The Record Route Object is embed-ded in the RSVP-TE RESV messages During its journey from the egress router to theingress router all IP addresses are recorded and stored at the ingress router On IOS, youhave to explicitly turn on generation to the RRO object using a Tunnel Interface pathoption, in JUNOS it is automatic.

IOS configuration

In IOS the Record Route Object (RRO) is not automatically generated for a TE tunnel It needs to get configured explicitly using the tunnel mpls traffic-eng record-route command.

is included in the Route Record Object (RRO).

London#show mpls traffic-eng tunnels

Name: TE Tunnel to Washington via Pennsauken (Tunnel0) Destination: 192.168.20.1 Status:

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

path option 1, type explicit via-Pennsauken (Basis for Setup,path weight 10)

Config Parameters:

Bandwidth: 1 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF

Metric Type: TE (default)

AutoRoute: enabled LockDown: disabled Loadshare: 1 bw-based

auto-bw: disabled

InLabel :

-MPLS Signalling Protocols 415

Time since created: 12 days, 17 hours, 39 minutes

Time since path change: 1 minutes, 13 seconds

Current LSP:

Uptime: 1 minutes, 13 seconds

Most often you will notice a difference between the configured ERO and the recordedPATH It is common practice to use a router’s loopback ID as the address for a loose hop However, the route recorder in the PATH message thinks entirely in terms of linkaddresses So even if we used in our example the 192.168/16 addresses, the ones actuallyreported back in the RRO are from the link-address space 172.16/16

In JUNOS you can also display the recorded path using the show mpls lspingress detailcommand

Total 1 displayed, Up 1, Down 0

JUNOS behaves similarly to IOS, where the Route Path Recording is done using linkaddresses

If you want to achieve any-to-any MPLS connectivity between all routers in your

network, then the consequence is to deploy a full-mesh of RSVP-TE tunnels However,there are severe scaling implications with that approach To overcome these scaling

limitations a more lightweight MPLS label setup protocol called the Label Distribution Protocol (LDP) is used.

14.4.3 LDP

LDP is defined in RFC 3036 and it describes a lean, lightweight protocol that brings up a

mesh of connectivity to all LDP speakers in the network Generally, the term mesh raises warning flags in every network engineer’s head due to the perceived scaling problems However, LDP uses a technique called label-merging which is very conserva-

full-tive with label allocation Consider the right-hand side of Figure 14.13 There are fivedrawings inside the figure, one for each possible egress router The egress router is markedwith an E, and the metric on each link is 4

MPLS Signalling Protocols 417

Frankfurt Pa

LDP label allocation

6

4

4 4

4 4

6

4

4 4

4 4

6

4

4 4

4 4

6

4

4 4

4 4

6

4

4 4

4 4

Frankfurt

London Washington NewYork

Paris

Frankfurt

London Washington NewYork

Paris

Frankfurt

London Washington NewYork

Paris

Frankfurt

London Washington New York

Paris

Frankfurt

London Washington New York

Paris

Frankfurt

London Washington NewYork

Paris

Frankfurt

London Washington NewYork

Paris

Frankfurt

London Washington New York

Paris

Frankfurt

London Washington NewYork

F 14.13 LDP consumes less forwarding state per link than RSVP does

The figure describes the LSPs and the necessary forwarding state to set up full-meshconnectivity between all five routers in the core network Using RSVP-TE, we would

need at least N * (N – 1)/2  10 explicitly configured tunnels Because LDP supports label

merging, some labels can be re-used by other label switched paths Unlike RSVP-TE,

LDP signals its label using a mode called downstream unsolicited, which means that

the labels are signalled from the egress router to the ingress router Each LDP speaker

advertises prefixes according to the egress policy In JUNOS, the default egress policy is just to advertise the loopback IP address The IOS default egress policy is to advertise both

the loopback and all the directly connected interfaces Upstream nodes create MPLSSWAP states and pass on the label-mapping message to their upstream nodes, which cre-ate again MPLS SWAP states, and pass them on to further upstream nodes, and so on The

resulting shape of the merged tree is called a sink tree (In datacom speech the egress or destination point is sometimes called the sink.) And because the root of the tree is at the egress router, it is therefore a sink tree.

Figure 14.14 shows the number of forwarding entries (FE) that the sum of all labelswitched paths generates Even in the small topology, LDP behaves better than RSVP-TE LDP has an average of 3 FEs per link versus RSVP-TE, which consumes anaverage of 4.33 FEs per link LDP is therefore the protocol of choice for edge systemslike VPN and/or customer access routers, due to LDP’s ability to supply a full-mesh con-nectivity to all the other LDP speakers with no setup complexity at all

The configuration of LDP is a simple one: just enable it on a per-interface basis AnLDP configuration for router London on IOS could look like the following:

IOS configuration

In IOS two configuration lines are necessary for running LDP First turn on MPLS cessing on an interface plus the necessary Layer-2 Supporting Protocols like MPLSCP over PPP using the tag-switching ip keyword The mpls label protocol ldp key- word tells the system to run LDP rather than TDP (Cisco’s proprietary predecessor

419

In JUNOS we need to make sure that family mpls is configured under the logicalinterface branch In addition we add a list of interfaces where we want to speak LDPunder the protocols ldp stanza.

JUNOS configuration

In JUNOS you need to specify the interface where you want to run LDP both under the protocols mpls {} and protocols ldp {} stanza Alternatively you can set the mpls interface list to all which allows allocation of labels on all interfaces In addition every logical interface needs to have the family mpls configured.

It remains unknown why mpls interface all {} is not the default option,

since this does not break anything by being turned on On the other hand, it does break

proper label allocation if the interfaces are not listed under this command hierarchy Notall default decisions are obvious.

The neighbour state is verified using the show ldp neighbor command

JUNOS output

You can verify the neighbour state using the show ldp neighbor detail operational level command The output displays the session IP addresses plus the neighbour’s link IP address.

hannes@Frankfurt> show ldp neighbor detail

stand-One of the most frequent configuration mistakes is that the list of interfaces that run IS-ISand the list of interfaces which run LDP are not the same Consider Figure 14.15 All links

in the core network have IS-IS and LDP enabled, except the link between Washington andNew York, which lacks LDP due to a configuration mistake Paris learns the /32 FEC of theNew York router via the London, Frankfurt, Washington path and selects the path viaWashington because it is on the shortest path tree The traffic gets labelled to Washingtonwhere it gets black holed because no valid MPLS labelled switched paths to the FEC of New York are available

If you are troubleshooting an MPLS reachability problem, the first thing to check is ifthe IS-IS adjacencies match the LDP session It remains problematic why router vendors

do not change their default behaviour LDP should be automatically brought up as soon

as you enable IS-IS on an interface If someone does not want to run LDP, they couldthen explicitly turn it off That way you can prevent a network from black holing traffic

14.4.4 Conclusion

Clients often ask what the “signalling protocol of choice” is In 99 per cent of the cases,the answer is: both (LDP and RSVP-TE) Both protocols augment each other LDP lackspath control, however It is very frugal in its label usage and therefore inherently scalable.RSVP-TE is a heavyweight both from an administrative point of view as well as from alabel allocation perspective; however, RSVP-TE has sound path control properties So ingeneral, networks use LDP, but once they need to offload some traffic from hot trunks,they use RSVP-TE in addition There is no need to build full-mesh, explicitly configured

RSVP-TE tunnels First, pick a careful IGP metric scheme that provides good-enough

routes, and then on top of that use RSVP-TE established TE-tunnels to take some heat offthe hot trunks

14.5 Complex Traffic Engineering by CSPF Computations

Traffic engineering is deployed in two general ways: the first option is when the networkadministrator wants to have the maximum level of control and explicitly configures all thelabel switched paths, plus the EROs In moderately complex topologies, however, manu-ally writing up tens to hundreds of EROs is a daunting task and almost certainly over-whelms the processing capabilities of humans This is especially true if constraints likehop count and backup path diversity need to be considered; in these cases, automatic com-putation of EROs is the preferred choice The computation of the EROs is done using adistributed traffic engineering database called the TED The contents of this database arecarried in IS-IS or OSPF Figure 14.16 shows the differences between the two models

Extended IS-IS

Database (TED)

Constrained Shortest Path First (CSPF)

In the first method, the network administrator supplies the ERO data, and in the second theEROs are calculated using a Constrained Shortest Path First Calculation (CSPF) based onuser constrained TED input from the routers The final result is an ERO which gets passed

to RSVP-TE for LSP setup

You can display the contents of the TED database using the show mpls eng topologycommand in IOS and show ted database extensive com-mand in JUNOS

traffic-IOS command output

London#show mpls traffic-eng topology

My_System_id: 1921.6800.1008.00 (isis level-2)

Signalling error holddown: 10 sec Global Link Generation 5

IGP Id: 1921.6800.1012.00, MPLS TE Id:192.168.0.12 Router Node (isis level-2) link[0]: Point-to-Point, Nbr IGP Id: 1921.6800.1008.00, nbr_node_id:1, gen:2 frag_id 0, Intf Address:172.16.0.2, Nbr Intf Address:172.16.0.1

TE metric:10, IGP metric:10, attribute_flags:0x0

physical_bw: 2488320 (kbps), max_reservable_bw_global: 2488320 (kbps) max_reservable_bw_sub: 0 (kbps)

Global Pool Sub Pool

JUNOS command output

hannes@Frankfurt> show ted database extensive

TED database: 3 ISIS nodes 3 INET nodes

Available BW [priority] bps:

[0] 2488.32Mbps [1] 2488.32Mbps [2] 2488.32Mbps [3] 2488.32Mbps

[4] 2488.32Mbps [5] 2488.32Mbps [6] 2488.32Mbps [7] 2488.32Mbps

Interface Switching Capability Descriptor(1):

Switching type: Packet

Encoding type: Packet

Maximum LSP BW [priority] bps:

[0] 2488.32Mbps [1] 2488.32Mbps [2] 2488.32Mbps [3] 2488.32Mbps [4] 2488.32Mbps [5] 2488.32Mbps [6] 2488.32Mbps [7] 2488.32Mbps

Why isn’t the data for CSPF calculations taken straight from the link-state database ofthe routing protocol? Well, there still may be OSPF deployed in parts of the network The

TED is a unified view to the topology of the network, so no matter which IGP (OSPF,

IS-IS, or even vendor-proprietary protocols) supplied the topology data The TED is a

unified, abstracted view and knows only about nodes, links and link attributes.

How does IS-IS generate and encode the data in the TED output? How does it knowthat a certain interface is an OC-48 interface? As soon as RSVP-TE is enabled on aninterface, a lot of extra information is generated and conveyed using IS-IS

Consider the following tcpdump output of a LSP before RSVP-TE has been turned on

Tcpdump output

If RSVP-TE is not enabled on a core interface then no bandwidth relevant information is generated inside the Extended IS Reach TLV.

00:27:20.871975 OSI, IS-IS, length: 104

L2 LSP, hlen: 27, v: 1, pdu-v: 1, sys-id-len: 6 (0), max-area: 3 (0)

lsp-id: 0620.0000.0001.00-00, seq: 0x00000030, lifetime: 1196s

chksum: 0x1d9d (correct), PDU length: 104, L1L2 IS

Area address(es) TLV #1, length: 4

Area address (length: 3): 49.0001

Protocols supported TLV #129, length: 1

NLPID(s): IPv4

Traffic Engineering Router ID TLV #134, length: 4

Traffic Engineering Router ID: 62.0.0.1

IPv4 Interface address(es) TLV #132, length: 4

IPv4 interface address: 62.0.0.1

Hostname TLV #137, length: 9

Hostname: Frankfurt

Extended IS Reachability TLV #22, length: 23

IS Neighbor: 0621.5401.3008.00, Metric: 10, sub-TLVs present (12) IPv4 interface address subTLV #6, length: 4, 10.0.0.2

IPv4 neighbor address subTLV #8, length: 4, 10.0.0.1

Extended IPv4 Reachability TLV #135, length: 18

IPv4 prefix: 62.0.0.1/32, Distribution: up, Metric: 0

Complex Traffic Engineering by CSPF Computations 425Next, traffic engineering and RSVP-TE is configured on IOS and JUNOS and theresulting LSP structure is examined.

IOS configuration

In IOS you need to enable traffic-eng globally and under the router isis stanza Additionally you need to enable it on each interface using the mpls traffic-eng tunnels command plus the ip rsvp bandwidth keyword specifies how much bandwidth can be reserved.

max-imum amount of bandwidth that is available for a single reservation Typically those two

values are the same, which means that a single reservation can eat up all the interface’sbandwidth Under the router isis stanza you need to specify the IS-IS level to whichyou want to send traffic engineering information Unfortunately, you need to decide forLevel-1 or Level-2 Both levels are not yet supported Typically Level-2 is configured, andthat is done here

In JUNOS the sending of traffic engineering sub-TLV parameters is the default iour and there is no need to configure any further global options All that needs to be con-figured is to add the interface under the protocols rsvp stanza

behav-JUNOS configuration

In JUNOS you need to specify the interface where you want to send bandwidth and vation state both under the protocols mpls {} and protocols rsvp {} stanza Alternatively you can set the mpls interface list to all You can change the