Spirent TestCenter · BFD Solution Summary BFD support for IPv4 and IPv6 routing over ATM,...

Routing/MPLS Additional Topics

Spirent TestCenter

1

Copyright© 2012 Spirent Communications

All Rights Reserved.

International copyright laws prohibit the copying, reproducing or transmitting of part or all of this document in any form or by any means, electronic or mechanical, including photocopying, facsimile or recording, for any purpose without the express written permission of Spirent Communications.

Information in this document is subject to change without notice and does not represent a commitment on the part of Spirent Communications.

Spirent Communications makes no warranties with respect to the contents or the use of this documentation and specifically disclaims any expressed or implied warranties of merchantability or fitness for a particular purpose. Further, Spirent Communications reserves the right to revise this publication and to make changes to its contents, at any time, without obligation to notify any person or entity of such revisions or changes. Spirent Communications also assumes no responsibility for any errors that may appear in this document.

2

Routing/MPLS Additional Topics

BFD..................................................................5

IPv6................................................................19

LISP...............................................................125

PIM................................................................147

MPLS-TP..........................................................179

MPLS VPN........................................................207

3

This Page Left Blank

www.spirentcampus.com

4

Spirent TestCenter

Bidirectional Forwarding Detection (BFD)

5

BFD Topic Overview

BFD Testing Overview

BFD Solution Summary

BFD Modes

BFD Router Wizard Integration

BFD Configuring Static Sessions

BFD Generator/Analyzer Templates

BFD Results

BFD over VCCV (Virtual Circuit Connectivity Verification)

MPLS-TP BFD PDU Templates

Fast BFD as Failover Trigger

BFD Scale Topology

BFD Scale Mode

Bidirectional Forwarding Detection (BFD) 6

BFD Testing Overview – Why Test BFD? It is extremely processor intensive, with processor load increasing as timers decrease

It sends a large number of hello packets per second – affecting data plane performance

Each BFD session can potentially affect system performance and convergence times

As the processor load increases, traffic forwarding performance decreases

The following issues occur at very high processor load:

Route flapping

QoS policies kick in – low priority traffic suffers or drops

Dropped frames, out of sequence frames, high latency, etc

Interface alarms – red and yellow alarms for traffic issues

Poor system responsiveness to CLI/SNMP

System Crash or hang



BFD Solution Summary

BFD support for IPv4 and IPv6 routing over ATM, Ethernet, or SONET

Support for Protocol-Dependent & Control-Plane Independent modes

Integrated with all Unicast and MPLS protocols – I&E-BGP (+MH), OSPFv2, OSPFv3, IS-IS, RIPv1, RIPv2, RIPng, LDP, T-LDP (MH), and RSVP-TE

Emulate up to 1000 dynamic & 2000 static BFD sessions per port-group

Control of all timers with Transmit and Receive timers down to 10ms

Support for BFD Simple or MD-5 authentication

Asynchronous or Demand modes with active or passive router roles

Command Sequencer control of diagnostic codes to simulate specific failures

Supports BFD custom frame templates with support for MD-5 authentication

Support for BFD Analyzer Filters NOTE: MH = Multihop

8


BFD Modes

Both types of BFD include full Interactive and Command Sequencer support in Spirent TestCenter

BFD Independent is used mainly for scale and functional testing

Activate / Deactivate, and Reactivate BFD routers and control-plane independent sessions to build scalability tests that add objects over time

Both have their own advantages:

Protocol dependent BFD (fate-driven BFD) shares fate with the control plane protocol

good for convergence testing results correlate to control plane protocol

Control-plane Independent BFD (static BFD) is not tied to the control plane protocol and stays up regardless of other protocol states

Results are independent to other protocols easier to use for scale and functional testing

9


BFD Router Wizard Integration

Enables protocol-dependent

BFD and creates associated

session

Enables control-plane

independent BFD and allows

you to create individual

sessions with static

configurations

New wizard options for timers,

authentication, and router role

are available for both types of

BFD

10

BFD Configuring Static Sessions Control Plane Independent BFD allows you to create individual sessions with static configurations


View, activate, or add BFD

routers and associated options

View, activate, or add BFD

sessions and associated static

addressing Optional My Discriminator –

remote Discriminator is learned

automatically and displayed in

BFD session results

11


BFD Generator/Analyzer Templates

Select any field in the frame, the

templates includes well-known

values for authenticated or plain

BFD frames

Select encapsulation and BFD

frame type, select any value in

any header to filter upon

12

BFD Results Flaps and Timeouts Detected

Message Rate Statistics


BFD over VCCV RFC 5885, RFC 5085

CC Type 1(CW), 2(Router Alert), 3 (TTL=1)

Support “Raw” and “IP/UDP” by CV Type

Support GAL/GACH option and GACH TLV


MPLS-TP BFD PDU Templates RFC 6428 Proactive Connectivity Verification, Continuity Check,

and Remote Defect Indication for the MPLS Transport Profile

MPLS-TP BFD CC-CV RDI PDU templates now added to Spirent TestCenter

For negative testing or user-injected PDU’s for BFD


Fast BFD as Failover Trigger Need TDM based reliability to maintain SLAs

Real-time video distribution requires < 50ms failover/switchover

Routing protocols take too long to converge

Control Plane Dependent BFD at 3.33ms, 10ms

No MD5 support


CORE IP/MPLS

PE (Edge)

PE (Edge)

CDN

BGP/LDP & BFD

Video Distribution

16

BFD Scale Topology


SP Core - IGP Profile

2 X Spirent TestCenter - MX

Ports …

…

1

2 4 200 Vlans per port – Total= 800 Vlans

…

…

Multicast Traffic

Bi-directional Unicast traffic

700 BFD Sessions at interval= 3.33 ms, Detect Multiplier=3

800 LDP Sessions – 40K Prefix LSPs + 1 Million Labels

800 OSPF P2P – 40K Inter Area LSAs

800 PIM Neighbors– 80K groups

DUT P Router

3

2 X Spirent TestCenter - MX

Ports

150 iBGP – 50K IPv4 routes + 12K Labeled routes

17

BFD Scale Mode

Scale mode: Normal, GenTx(No Results), GenTx (w/ Rx Results)

One session w/ Rx Result available per port

Microsecond Intervals to support non-integer values, 3.33ms

CPD with OSPF, OSPFv3, BGP(v4/v6), LDP (no ISIS)


Spirent TestCenter

IPv6 Routing

19

IPv6 Routing

IPv6 Routing Topic Overview

Introduction to IPv6 Routing

RIPng

BGP4+

OSPFv3

PIM-SM

20

IPv6 Routing Observations

Unicast IPv6 routing is essentially the same as unicast IPv4

If you understand IPv4 routing, you “have it made”

OSPFv3 is a big improvement over OSPFv2

Changes based on 10 years of experience

Discussions underway to extend OSPFv3 for IPv4

Simple IPv6 multicast very similar to IPv4 multicast

“Simple” is mostly what is in use now

Complex (large scale and/or interdomain) IPv6 multicast still needs work

But then so does large-scale IPv4 multicast

IPv6 solutions should prove to be simpler in the long run

IPv6 Routing 21

IPv6 Path Considerations

IPv6 routers do not fragment packets

IPv6 MTU must be at least 1280 bytes

Recommended MTU is 1500 bytes

Nodes should implement MTU PD (Path Discovery)

Otherwise they must not exceed 1280 bytes

MTU path discovery uses ICMP "packet too big" error messages

IPv6 Routing 22

Static Route Considerations

Static route configuration syntax is the same as IPv4

Except prefix and next hop are IPv6

Next hop address should be link-local

ICMPv6 Redirect messages need link-local address

prefix -> next-hop address

IPv6 Routing 23

EIGRP

Same DUAL convergence algorithm

Simple addition of TLVs to support IPv6

Differences from EIGRP for IPv4:

Configured directly on interface

No network statement

Requires Router ID

Not supported by Spirent TestCenter

IPv6 Routing 24

IS-IS

RFC 5308 Routing IPv6 with IS-IS

2 new TLVs are defined:

IPv6 Reachability; TLV type 236

IPv6 Interface Address; TLV type 232

IPv6 NLPID = 142

IS-IS for IPv6 supports single and multi-topology

single allows IPv4 and IPv6 to share the same link-state topology

whereas OSPF always requires a separate routing instance (protocol, topology) for the two (IPv4 and IPv6)

IPv6 Routing 25

RIPng Overview

RFC 2080 describes RIPngv1, not to be confused with RIPv1

Based on RIP Version 2 (RIPv2 for IPv4)

Uses UDP port 521

Operational procedures, timers and stability functions remain unchanged

RIPng is not backward compatible to RIPv2

Message format changed to carry larger IPv6 addresses

IPv6 Routing 26

OSPFv3

Unlike IS-IS, entirely new version required

RFC 2740

Fundamental OSPF mechanisms and algorithms unchanged

Packet and LSA formats are different

IPv6 Routing 27

Multiprocotol BGP-4

MP-BGP defined in RFC 2283

Two BGP attributes defined: Multiprotocol Reachable NLRI advertises arbitrary Network Layer Routing Information

Multiprotocol Unreachable NLRI withdraws arbitrary Network Layer Routing Information

Address Family Identifier (AFI) specifies what NLRI is being carried (IPv6, IP Multicast, L2VPN, L3VPN, IPX...)

Use of MP-BGP extensions for IPv6 defined in RFC 2545 IPv6 AFI = 2

BGP TCP session can be over IPv4 or IPv6

Advertised Next-Hop address must be global or site-local IPv6 address

And can be followed by a link-local IPv6 address

Resolves conflicts between IPv6 rules and BGP rules

IPv6 Routing 28

IPv6 Multicast Routing

PIM-SM

“Basic” PIM-SM

PIM-Bidir

PIM-SSM

MP-BGP

Legacy protocols not supporting IPv6:

DVMRP

PIM-DM

IPv6 Routing 29

IPv6 Routing



RIPng

BGP4+

OSPFv3

PIM-SM

30

IPv6 Routing

RIPng Overview

RFC 2080 describes the RIPng IGP routing protocol for IPv6

RFC 2081 is the RIPng Protocol Applicability Statement

It operates essentially the same as RIPv2 for IPv4

Although it is not backward compatible to RIPv2

It uses UDP port 521 (instead of 520) and has maximum 15 hops

Operational procedures, timers and stability functions are the same

Message format changed to carry larger IPv6 addresses

Supports Triggered Updates and Split Horizon with Poison Reverse (hops=16)

Network A Network B

A=16, B=16, C=1 A=2, B=1, C=16

Network C

A=16, B=1, C=2 A=1, B=16, C=16

31

IPv6 Routing

IPv6 Related Functionality

It is an IPv6 only protocol and uses IPv6 for transport

In a dual-stack environment you’ll need RIP (IPv4) and RIPng (IPv6) running as "ships in the night"

It updates contain IPv6 prefix(s) and next-hop IPv6 address

Although there is only a single next-hop field for all RTEs (route table entry)

Each RTE also includes a route tag, prefix length, and metric (hop count)

The source of the datagram, and next-hop if present, must be a link-local address

RIP updates are sent to multicast address FF02::9

32

IPv6 Routing

The RIPng packet format

Carried in IP + UDP Port 521

33

IPv6 Routing

Route Table Entry (RTE) and Next Hop

Next Hop Route Table Entry (RTE):

Route Table Entry (RTE):

34

IPv6 Routing



RIPng

BGP4+

OSPFv3

PIM-SM

35

IPv6 Routing

What is BGP? RFC 4271

E-BGP link I-BGP link

Physical link

NOTE: Each BGP link requires a separate TCP connection

E-BGP is an exterior routing protocol spoken between BGP peers in different Autonomous Systems (ASs).

I-BGP is interior routing protocol spoken between BGP peers in the same Autonomous System (AS).

AS 1

AS 2

AS 3

E-BGP I-BGP

E-BGP

36

IPv6 Routing

BGP Protocol Operation

Each BGP session consists of exactly 2 BGP peers.

If you wish to “Peer” with N routers then, you will establish N BGP sessions.

Each BGP session uses TCP as the transport protocol.

At the outset of a BGP session, each router will advertise the routes it wishes to share.

Routes are not refreshed and are assumed to be good if they are not specifically withdrawn.

Each route that is advertised includes attributes that describe the following:

How the prefix (i.e., the network) came to be routed by BGP.

The path of ASs through which the prefix has been advertised until this point.

Metrics expressing degrees of preference for this prefix.

Except for the prefixes themselves, the attributes carry the important information.

Routing policies are used to enforce business agreements and affect the decisions about which routes to accept from and advertise to various BGP neighbors.

37

IPv6 Routing

BGP Decision Process

Input Policy – Filtering based on IP prefixes, AS path information, and attribute information.

Decision Process – Decide which routes to use to a certain destination based on the input policy.

Routes – Are those identified by the decision process as usable and may also be advertised.

Output Policy – Similar to input to determine which routes are advertised.

Routes Filtering Choose Best Routing Filtering Routes Received Route Table Sent

Input Policy

Decision Process Routes Output

Policy

38

IPv6 Routing

BGP vs. the OSI Model

RIP BGP UDP TCP port 179 OSPF IP Protocol 6 Data Link Physical

39

IPv6 Routing

BGP Message Types

A common header precedes all BGP messages.

There are 4 types of BGP Messages:

Open (1) is the first message sent after a TCP connection is established for each endpoint to identify itself and agree on protocol parameters.

Update (2) is the primary message used to advertise and/or withdraw routes.

Notification (3) is used to signal the presence of a errored condition before terminating the TCP (and therefore the BGP) session.

Keepalive (4) messages are exchanges between BGP peers to confirm the connection is still alive.

Route-refresh (5) messages facilitates non-disruptive routing policy changes.

IP TCP Marker Length Type BGP Message Type 20B 20B 16B 2B 1B Variable

BGP Common Header NOTE: The use of the Marker field for BGP Authentication has been deprecated.

40

IPv6 Routing

BGP Session Establishment and Maintenance

Establish TCP Session

Establish

BGP Session

BGP Session Maintenance

Send Routes

BGP Session Maintenance

Link Layer UP

Initial TCP Syn

TCP Syn/Ack

TCP Ack

BGP Open

BGP Open

TCP Ack

BGP Keepalive

BGP Keepalive

TCP Ack

BGP Update

BGP Update

BGP Update

BGP Update

TCP Ack

BGP Keepalive

BGP Keepalive

TCP Ack

AS 100 Peer

AS 200 Peer

Establish TCP Session Establish BGP Session BGP Session Maintenance Send Routes BGP Session Maintenance

41

IPv6 Routing

OPEN Message Format

After a TCP connection is established, the first message sent by each side is an OPEN message (BGP message Type=1).

If the OPEN message is acceptable, a KEEPALIVE message confirming the OPEN is sent back.

Once the OPEN is confirmed, UPDATE, KEEPALIVE, and NOTIFICATION messages may be exchanged.

In addition to the BGP header, the OPEN message contains the following fields:

1 2 3 4 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Version

My Autonomous System

Hold Time

BGP Identifier

Opt Parm Len Optional Parameters

42

IPv6 Routing

OPEN Message – Optional Parameters

Optional Parameters – This field may contain a list of optional parameters, where each parameter is encoded as a Parameter Type, Parameter Length, Parameter Value (TLV) triplet:

RFC 1771 defines only a single Optional Parameters:

Authentication Information (Parameter Type 1):

1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Parm. Type Parm. Length Parameter Value (variable)

1 0 1 2 3 4 5 6 7

Auth. Code Authentication Data

Deprecated

43

IPv6 Routing

Capabilities Advertisement with BGP-4 RFC 3392

The Optional Capabilities Parameter parameter lists the capabilities supported by the BGP speaker (Parameter Type 2).

A BGP speaker includes this parameter in its OPEN message to its BGP peer.

A BGP speaker that supports a particular capability may use this capability with its peer after the speaker determines that the peer supports this capability.

A BGP speaker determines that its peer doesn't support capabilities advertisement, if in response to an OPEN message that carries the Capabilities Optional Parameter, the speaker receives a NOTIFICATION message with the Error Subcode set to Unsupported Optional Parameter.

1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

Capability Code Cap. Length Capability Value (variable)

44

IPv6 Routing

Capability Codes

Value Description Reference

0 Reserved RFC 3392

1 Multiprotocol Extensions for BGP-4 RFC 2858

2 Route Refresh Capability for BGP-4 RFC 2918

3 Cooperative Route Filtering Capability Draft

4 Multiple routes to a destination capability RFC 3107

5-63 Unassigned

64 Graceful Restart Capability Draft

65 Support for 4-octet AS number capability Draft

66 Deprecated (2003-03-06)

67 Support for Dynamic Capability (capability specific) Draft

68-127 Unassigned

128-255 Vendor Specific

45

IPv6 Routing

Multiprotocol Extensions RFC 2858

A BGP speaker that uses Multiprotocol Extensions should use the Capabilities Optional Parameter (Parameter Type 2).

Uses of Multiprotocol BGP (BGP4+) include carrying IPv6 routes, MPLS labels, and VPN route information.

Carried in the “Parameter Value” field is one or more of:

1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

Capability Code Cap. Length Capability Value (variable)

1 2 3 4 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Address Family Identifier AFI Reserved SAFI Value:

Capability Code = 1 for Multiprotocol Extensions Capability Length = 4 AFI = 1 for IPv4 and 2 for IPv6 SAFI = 1 for unicast forwarding, 2 for multicast, 3 for both

46

IPv6 Routing

Update Message Format UPDATE messages are used to transfer routing information between BGP peers (BGP message Type=2).

The information in the UPDATE packet can be used to construct a graph describing the relationships of the various Autonomous Systems.

An UPDATE message is used to advertise a single feasible route to a peer, or to withdraw multiple unfeasible routes from service.

An UPDATE message may simultaneously advertise a feasible route and withdraw multiple unfeasible routes from service.

The UPDATE message always includes the fixed-size BGP header, and can optionally include the other fields as shown below:

Unreachable Routes

Path Attributes

Reachable Routes

1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Unfeasible Routes Length

Withdrawn Routes (variable)

Total Path Attribute Length

Path Attributes (variable)

Network Layer Reachability Info (variable)

47

IPv6 Routing

Update Message – Withdrawn Routes

This is a variable length field that contains a list of IP address prefixes for the routes that are being withdrawn from service.

Each IP address prefix is encoded as a 2-tuple of the form (length and prefix).

Length (1octet)

Prefix (variable) 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Unfeasible Routes Length





Length (1octet)

Prefix (variable)

Length (1octet)

Prefix (variable)

48

IPv6 Routing

Update Message – Path Attributes

A variable length sequence of path attributes is present in every UPDATE. Each path attribute is TLV encoded as attribute type, attribute length, and attribute value of variable length.

Attribute Type is a two-octet field that consists of the Attribute Flags octet followed by the Attribute Type Code octet.






Attr. Flags Attr. Type Code

Attr. Type Attr. Length Attr. Value

2 bytes 1-2 bytes variable



1 byte 1 byte

49

IPv6 Routing

Update Message – Network Layer Reachability Information (NLRI)

This variable length field contains a list of IPv4 address prefixes that are being advertises as reachable (IPv6 addresses are carried in the attributes).

The length in octets of the Network Layer Reachability Information is not encoded explicitly.

Reachability information is encoded as one or more 2-tuples of the form (length and prefix).

An initial UPDATE message will contain mostly NLRIs. Later updates may contain a mixture of withdrawn routes and NLRIs.

Length (1octet)

Prefix (variable)






Length (1octet)

Prefix (variable)

Length (1octet)

Prefix (variable)

NLRI

50

IPv6 Routing

Notification Message Format

A NOTIFICATION message is sent when an error condition is detected (BGP message Type=3).

The BGP connection is closed immediately after sending it.

In addition to the fixed-size BGP header, the NOTIFICATION message contains the following fields:

1 2 3 4 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Error Code Error subcode Data

Data Continued ...

51

IPv6 Routing

Keepalive Message Format

BGP does not use any transport protocol-based keep-alive mechanism (i.e., TCP has no keepalives) to determine if peers are reachable.

Instead, BGP KEEPALIVE messages are exchanged between peers often enough as not to cause the Hold Timer to expire.

A reasonable maximum time between KEEPALIVE messages would be one third of the Hold Time interval.

KEEPALIVE messages MUST NOT be sent more frequently than one per second.

If the negotiated Hold Time interval is zero, then periodic KEEPALIVE messages MUST NOT be sent.

NOTE: If the negotiated Hold Time value is zero, then the Hold Time timer and KeepAlive timers are not started.

KEEPALIVE message consists of only message header and has a length of 19 octets.

IP TCP Marker Length Type=4 20B 20B 16B 2B 1B

BGP Common Header 52

IPv6 Routing

Update Message – Path Attributes

Path attributes are carried in the UPDATE message.

Path attributes fall into four separate categories:

1. Well-known mandatory.

2. Well-known discretionary.

3. Optional transitive.

4. Optional non-transitive.





Network Layer Reachability Info (variable) Attr. Flags Attr. Type Code


2 bytes 1-2 bytes variable



1 byte 1 byte

53

IPv6 Routing

Path Attributes – Attribute Flags

The Attribute Flags octet is defined as follows:

Optional bit (O) defines whether the attribute is optional (set to 1) or well-known.

Transitive bit (T) defines whether an optional attribute is transitive (set to 1) or non-transitive (set to 0).

Partial bit (P) defines whether the information contained in the optional transitive attribute is partial (set to 1) or complete (set to 0).

Extended Length bit (E) defines whether the Attribute Length is one octet (if set to 0) or two octets (if set to 1).

The low 4 bits of the Attribute Flags octet are unused and must be zero (MBZ).

Attr. Flags Attr. Type Code


1 byte 1 byte

O T P E MBZ

0 1 2 3 4 5 6 7

54

IPv6 Routing

Path Attributes – Types

# Code Reference Comment Length

1 ORIGIN RFC 1771 Well-known, mandatory 1

2 AS_PATH RFC 1771 Well-known, mandatory 2 + 2 x n

3 NEXT_HOP RFC 1771 Well-known, mandatory 4

4 MULTI_EXIT_DISC RFC 1771 Optional, non-transitive 4

5 LOCAL_PREF RFC 1771 Well-known, discretionary 4

6 ATOMIC_AGGREGATE RFC 1771 Well-known, discretionary 0

7 AGGREGATOR RFC 1771 Optional, transitive 6

8 COMMUNITY RFC 1997 Optional, transitive # x 4

9 ORIGINATOR_ID RFC 2796 Optional, non-transitive 4

10 CLUSTER_LIST RFC 2796 Optional, non-transitive # x 4

55

IPv6 Routing

Path Attributes – Types Continued

# Code Reference Comment Length

11 DPA Draft

12 ADVERTISER RFC 1863

13 RCID_PATH/CLUSTER_ID RFC 1863

14 MP_REACH_NLRI RFC 2858 Optional, non-transitive 4+

15 MP_UNREACH_NLRI RFC 2858 Optional, non-transitive 3+

16 EXTENDED COMMUNITIES Draft Optional, transitive # x 8

17 NEW_AS_PATH Draft

18 NEW_AGGREGATOR Draft

19 SAFI Specific Attribute Draft

20 Connector Attribute Draft

21-254 Unassigned

255 reserved for development

56

IPv6 Routing

Multiprotocol Extensions for BGP-4 RFC 2858

Defines two new attributes to carry other (IPv6 too) NRLIs:

Multiprotocol Reachable NLRI (MP_REACH_NLRI) is Type Code 14

Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI) is Type Code 15

Both of these attributes are optional and non-transitive

The MP_REACH_NLRI attribute is encoded as shown below:

Address Family Identifier (2 octets)

Subsequent Address Family Identifier (1 octet)

Length of Next Hop Network Address (1 octet)

Network Address of Next Hop (variable)

Subnetwork Points of Attachment(s) (variable)

Network Layer Reachability Information (variable)

NLRI = Network Layer Reachability Information

57

IPv6 Routing

MP_REACH_NLRI Field Definitions

Address Family Identifier (AFI) carries the identity of the Network Layer protocol associated with the Network Address that follows (2 = IPv6).

Subsequent Address Family Identifier provides additional information about the type of NLRI carried in the attribute.

Network Address of Next Hop contains the Network Address of the router that should be used as the next hop to the destination(s) listed in the MP_NLRI attribute.

SNPAs is some or all of the Subnetwork Points of Attachment(s) that exist within the local system.

NLRIs are the feasible routes that are being advertised in this attribute (the format is determined by the Subsequent Address Family Identifier field).

58

IPv6 Routing

IPv6 Address Scopes

IPv6 defines 3 unicast address scopes:

global, site-local and link-local

BGP-4 makes no distinction between global and site-local addresses

Network administrators must however respect address scope restrictions

Only link-local address can be used when generating ICMP Redirect Messages

Link-local addresses are not, however, well suited to be used as next hop attributes in BGP-4

Therefore, with BGP-4 it is sometimes necessary to announce a next hop attribute that consists of a global address and a link-local address.

59

IPv6 Routing

Constructing the Next Hop field w/IPv6

A BGP speaker shall advertise to its peer in the Network Address of Next Hop field the global IPv6 address of the next hop, potentially followed by the link-local IPv6 address of the next hop.

The value of the Length of Next Hop Network Address field on a MP_REACH_NLRI attribute shall be set to 16, when only a global address is present, or 32 if a link-local address is also included in the Next Hop field.

The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to.

As a consequence, a BGP speaker that advertises a route to an internal peer may modify the Network Address of Next Hop field by removing the link-local IPv6 address of the next hop.

60

IPv6 Routing

Rules for Carrying Other Attributes

An UPDATE message that carries the MP_REACH_NLRI must also carry the ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP exchanges).

Also, in IBGP exchanges such a message must also carry the LOCAL_PREF attribute.

An UPDATE message that carries no NLRI, other than the one encoded in the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute.

61

IPv6 Routing

NLRI Encoding

The Network Layer Reachability information is encoded as one or more tuples of the form <length, prefix>.

Length indicates the length in bits of the address prefix.

Prefix contains an address prefix followed by enough trailing bits to make the end of the field fall on an octet boundary.

Length (1 octet)

Prefix (variable)

62

IPv6 Routing

Subsequent Address Family Identifier

0 - reserved

1 - used for unicast forwarding

2 - used for multicast forwarding

3 - used for both unicast and multicast forwarding

4 to 63 assigned by IANA using the IETF consensus policy

4 - used for MPLS Labels

64 to 127 assigned by IANA using the first come first served policy

128 to 255 are for "private use" (i.e., not assigned by IANA)

128 - used for VPN-IPv4 Route Distinguisher

63

IPv6 Routing

Transport Considerations

TCP connections, on top of which BGP-4 messages are exchanged, can be established either over IPv4 or IPv6.

Although when using TCP over IPv4 as a transport for IPv6 reachability information, additional explicit configuration of the peer's network address is required.

The BGP Identifier is a 32 bit unsigned integer exchanged between two peers at session establishment time, within an OPEN message.

The use of TCP over IPv6 as transport protocol for IPv6 reachability information also has the advantage of providing explicit confirmation of IPv6 network reachability between two peers.

64

IPv6 Routing



RIPng

BGP4+

OSPFv3

PIM-SM

65

IPv6 Routing

OSPF for IPv6 RFC 5340 (OSPFv3)

Operates very similar to IPv4 OSPFv2 (link-state protocol)

Sends topology and prefix information separately

New LSA Types defined

Protocol processing per-link, not per-subnet

IPv6 uses the term "link" to indicate communication; instead of network and subnet

Interfaces connect to links; Multiple IP subnets can be assigned to a single link; and two nodes can talk directly over a single link, even if they do not share a common IP subnet

66

IPv6 Routing

Differences with IPv4

Authentication changes

Packet format changes

LSA format changes

Handling unknown LSA types

Stub area support

Identifying neighbors by Router ID

Protocol processing per-link, not per-subnet

Removal of addressing semantics

Addition of Flooding scope

Explicit support for multiple instances per link

Use of link-local addresses

67

OSPFv3 Differences from OSPFv2

Runs per-link rather than per-subnet Multiple instances on a single link

More flexible handling of unknown LSA types More network changes without adjacency disruptions possible

Link-local flooding scope added Similar to flooding scope of type 9 Opaque LSAs

Area and AS flooding remain unchanged

Authentication removed Uses IPv6 Authentication (AH) extension header instead

Neighboring routers always identified by RID

Removal of addressing semantics IPv6 addresses not present in most OSPF packets

RIDs, AIDs, and LSA IDs

IPv6 Routing 68

OSPFv3: Intra-Area-Prefix LSA

OSPFv2: Prefixes are advertised in Router (Type 1) LSAs

Primary purpose of Type 1 LSAs is to compute SPF tree Any addition/deletion/change of prefix requires flood of new Type 1 LSA

Yet prefix change does not affect SPF tree SPF re-calculation is needlessly triggered

Partial Route Calculation (PRC) cannot help OSPFv2 to scale

OSPFv3: Prefixes are advertised in Intra-Area-Prefix LSAs

Not Router LSAs Intra-Area-Prefix LSAs do not trigger SPF run

Scalability much improved in very large areas

More comparable to IS-IS PRC becomes useful for OSPFv3

IPv6 Routing 69

IPv6 Routing

OSPFv3 and OSPFv2 Similarities

Basic packet types

Hello, DBD, LSR, LSU, LSA

Mechanisms for neighbor discovery and adjacency formation

Interface types

P2P, P2MP, Broadcast, NBMA, Virtual

LSA flooding and aging

Nearly identical LSA types

Both use DRs and BDRs for transit links

70

IPv6 Routing

OSPFv3 Packet Types

OSPFv3 has the same 5 packet types but some fields have been changed.

All OSPFv3 packets have a 16 byte common header vs. the 24 byte header in OSPFv2

Packet Type Description

1 Hello

2 Database Description

3 Link State Request

4 Link State Update

5 Link State Acknowledgement

71

IPv6 Routing

The Designated Router (DR)

Turns this Into this

Of course there could be a Backup DR too (BDR) 72

IPv6 Routing

OSPF Protocol Exchange (Simplified)

Router A Router B

0 secs. Interface Interface

Hello

Hello

Data Base Description

Loading Loading LS Req/LS Advertisement

LS Req/LS Advertisement

LS Ack

Data Base Description

Init Init

2-Way 2-Way

ExStart ExStart

Exchange Exchange

Loading Loading

Full Full

73

IPv6 Routing

OSPF Common Header

OSPFv2

OSPFv3

Version Type Packet Length

Router ID

Area ID

Checksum AuType

Authentication

Authentication

Version Type Packet Length

Router ID

Area ID

Checksum Instance ID 0

74

IPv6 Routing

OSPFv3 Common Header

Size of the header is reduced from 24 bytes to 16

Router ID is still a 32 bit number uniquely identifying a router in the domain

Instance ID is a new field that is used to have multiple OSPF process instance per link. In order that 2 instance talk to each other they need to have the same instance ID. By default it is 0 and for any additional instance it is increased, Instance ID has local link significance only

Authentication fields have been suppressed

75

IPv6 Routing

Hello Packet: v2 vs. v3 (OSPF common header is not represented)

OSPFv2

OSPFv3

Network Mask

Hello Interval Options Priority

Router Dead Interval

Designated Router

Backup Designated Router

Neighbor ID

Neighbor ID

Interface ID

Priority Options

Hello Interval Dead Interval

Designated Router

Backup Designated Router

Neighbor ID

Neighbor ID

76

IPv6 Routing

OSPFv3 Hello Packet

Mask field has been replaced by Interface ID which is a 32-bit number uniquely identify an interface, virtual link gets its own interface ID

Option field has been increased to 24-bit from 8-bits

Hello and Dead intervals have been reduced to 16-bits from 32

DR and BDR are still 32-bit field and contain the Router ID of DR /BDR instead of IP address. Router ID and Link ID uniquely identify the DR on an interface

77

IPv6 Routing

Processing a Hello Packet in v3

Interface ID is copied into the hello packet

Network mask is not needed adjacency is formed on the link local as v6 runs on per link instead of per subnet

The choice of DR and BDR in hello is indicated by the router ID instead of their IP interface address on the link

Neighbors IP address is set to the IPv6 source address in the IPv6 header of the received hello packet.

78

IPv6 Routing

IPv6 multicast address used in OSPFv3

The multicast address AllSPFRouters is FF02::5

Note that 02 means that this is a permanent address and has link scope.

The multicast address ALLDRouters is FF02::6

Used for communication with DR & BDR

79

IPv6 Routing

Database Description Packet (OSPF common header is not represented)

OSPFv2

OSPFv3

MTU Options 00000IMMS

DD Sequence Number

LSA Headers

LSA Headers

0 Options

MTU 0 00000IMMS

DD Sequence Number

LSA Headers

LSA Headers

80

IPv6 Routing

Link State Request Packet (OSPF common header is not represented)

OSPFv2

OSPFv3

LS Type

Link State ID

Advertising Router

0 LS Type

Link State ID

Advertising Router

81

IPv6 Routing

Link State Request

Every LSA is uniquely identified by:

LS type, Link State ID, Advertising router

OSPFv3 has the same field as OSPFv2

Note that LS Type field is now 2 bytes and it has different coding as for OSPFv2 since there are 2 bits that indicates the flooding scope. (later on flooding)

82

IPv6 Routing

Link State Update Packet (OSPF common header is not represented)

Nothing has changed

Number of LSAs

LSA Header & Body

LSA Header & Body

83

IPv6 Routing

Link State Update

For IPv6, the eligible interfaces are selected based on the following factors:

The LSA's flooding scope (will talk more later)

Whether the LSA has a recognized LS type.

The setting of the U-bit in the LS type. If the U-bit is set to 0, unrecognized LS types are treated as having link-local scope. If set to 1, unrecognized LS types are stored and flooded as if they were recognized.

84

IPv6 Routing

Link Sate Acknowledgement (OSPF common header is not represented)

Each newly received LSA must be acknowledged.

This is usually done by sending Link State Acknowledgment packets.

Acknowledgments can also be accomplished implicitly by sending Link State Update packets

85

IPv6 Routing

OSPF Options Field

The OSPF Options field is present in OSPF Hello packets, Database Description packets and all LSAs.

The Options field enables OSPF routers to support (or not support) optional capabilities, and to communicate their capability level to other OSPF routers

O DC EA N/P MC E

0 16 23

… * * DC R N X E V6

OSPFv2

OSPFv3

86

IPv6 Routing

OSPF Options

In OSPFv2 Option field was a 8-bit field in Hello packet, DD packet and LSA header ( we will talk separately about this in the LSA section).

In OSPFv3 option field has been increased into 24-bit and moved to the body of certain LSA (see detail later)

The option field in Hello and DD packet has been also increased to 24-bit.

Unused bits have been suppressed and two new bit have been introduced.

87

IPv6 Routing

Option Bits Details

V6-bit - If this bit is clear, the router/link should be excluded from IPv6 routing calculations.

E-bit - describes the way AS-external-LSAs are flooded.

x-bit - was previously used by MOSPF which has now been deprecated.

N-bit - indicates whether or not the router is attached to an NSSA.

R-bit - Indicates whether the originator is an active router. Could be used by a multi-homed host that wants to participate in routing, but does not want to forward non-locally addressed packets.

DC-bit - This bit describes the router's handling of demand circuits.

*bits - reserved for migration of OSPFv2 protocol extensions.

0 16 23

… * * DC R N X E V6

88

IPv6 Routing

OSPF Flooding

OSPFv2 originally had two flooding scopes, AS wide and area wide.

In OSPFv3 there are three flooding scopes

AS scope - LSA is flooded through out the AS

Area scope - LSA is flooded only within an area

Link-local scope - LSA is flooded only on the local link.

We will come back to flooding after the LSA discussion

89

IPv6 Routing

OSPF LSA Header

OSPFv2

OSPFv3

LS Age Options LS Type

Link State ID

Advertising Router

Sequence Number

Checksum Length

LS Age LS Type

Link State ID

Advertising Router

Sequence Number

Checksum Length

90

IPv6 Routing

LSA Header Details

All LSAs begin with a common 20 byte header just like OSPFv2

OSPFv3 increased the LS Type field from 1 byte to 2 bytes, since option field is now removed to the body of the LSA and three new bit have been defined

LS Age: The time in seconds since the LSA was originated

LS Type: The LS type field indicates the function performed by the LSA

The high-order three bits of LS type encode generic properties of the LSA, while the remainder (called LSA function code) indicate the LSA's specific functionality (more later)

Link state ID: This field identifies the piece of the routing domain that is being described by the LSA

Depending on the LSA's LS type, the Link State ID takes on its value

The behavior of assigning this value has changed from v4 to v6, we will talk about the change of behavior as we go to each of the LSAs

Advertising Router: ID of the router originating the packet

91

IPv6 Routing

LSA Type Bits & Function Codes

The LS Type Field indicates the function performed by the LSA.

The high-order three bits of LS type encode generic properties of the LSA, while the remainder (called LSA Function Code) indicate the LSA's specific functionality.

For example Router LSA is not coded as Type 1, but Type 0x2001 (since S1 is set, it has an area flooding scope)

Basically the Function Code matches the same LSA type as in OSPFv2.

U S2 S1 Function Code

0 0 1 0 0000 0000 0001

92

IPv6 Routing

LSA Type Bits continued

S2 / S1 bit indicates the three flooding scopes:

U (Unrecognized) bit is used to indicate a router how to handle a LSA if it doesn’t recognize it:

S2 S1 Flooding Scope

0 0 Link-Local

0 1 Area

1 0 Autonomous System

1 1 Reserved

U-bit LSA Handling

0 Treat this LSA as if it has link-local scope

1 Store and flood this LSA as if type was understood

93

IPv6 Routing

List of LSA Types

Here is the list of LSA types in OSPFv3:

LSA Name LS Type Code Flooding Scope Function Code

Router LSA 0x2001 Area 1

Network LSA 0x2002 Area 2

Inter-Area Prefix LSA 0x2003 Area 3

Inter-Area Router LSA 0x2004 Area 4

AS-External LSA 0x4005 AS 5

Group Membership LSA 0x2006 Area 6

NSSA External LSA 0x2007 Area 7

Link LSA 0x0008 Link-local 8

Intra-Area Prefix LSA 0x2009 Area 9

94

IPv6 Routing

OSPF Router LSA

OSPFv2:

OSPFv3:

0 0 0 0 0 V E B 0 Number of Links

Link ID

Link Data

Type # ToS Metric

…

TOS 0 TOS Metric

0 0 0 Nt W V E B Options

Type 0 Metric

Interface ID

Neighbor Interface ID

Neighbor Router ID

95

IPv6 Routing

LS Type 0x2001; now announces only topology information

Each router in an area originates one or more router-LSAs which describes the state and cost of the router's interfaces to the area.

An IPv6 router sends a separate Router LSA for each of its links which are distinguished by their Link-State IDs.

Interface ID has shed any addressing semantics.

Now they are assigned arbitrarily (generally the MIB II IfIndex).

For example, an An IPv6 router originating multiple Router-LSAs could start by assigning the first a Link State ID of 0.0.0.1, the second a Link State ID of 0.0.0.2 .

Type field descriptions:

1 - Point-to-point

2 - Connection to a transit network

3 - Reserved

4 - Virtual link

OSPFv2 link type 3 (Stub link) has been suppressed

Neighbor Interface ID - the Interface ID the neighbor router (or the attached link's DR for Type 2); Neighbor Router ID - the Router ID the neighbor router

Router LSA Field Descriptions

Bit V - virtual link endpoint Bit E - is an AS boundary router (ASBR) Bit B - is an area border router (ABR) Bit x - was previously used by MOSPF Bit Nt- is an NSSA border router

96

IPv6 Routing

R3#show ip ospf database router

Router Link States (Area 1)

LS age: 0 Always 0 at origination

Options: (V6-Bit E-Bit R-bit DC-Bit) This is an IPv6 router

LS Type: Router Links This is a router LSA

Link State ID: 0

Advertising Router: 26.50.0.2 Router ID of R3

Area Border Router bit B = 1

Number of Links: 1

Link connected to: a Transit Network

Link Metric: 1 Cost to reach the interface

Local Interface ID: 3 IfIndex

Neighbor (DR) Interface ID: 3 IfIndex Neighbor (DR) Router ID: 26.50.0.1 Router ID of R1

OSPF Router LSA of R3 for Area

Area 0 R4

R3

1

DR R1

64

97

IPv6 Routing

OSPF Network LSA

OSPFv2:

OSPFv3:

Network Mask

Attached Router

Attached Router

0 Options

Attached Router

Attached Router

98

IPv6 Routing

Network LSA Field Descriptions

LS Type 0x2002; still have area flooding scope

Originated by the DR for every broadcast or NBMA link having two or more attached routers

Lists all router's Router IDs attached to the link including the DR's; does not contain a Network Mask

All addressing information formerly contained in the IPv4 Network LSA has now been consigned to Intra-Area Prefix-LSAs

Link State ID of the common header is set to the Interface ID of the DR

The Options field is set to the logical OR of the Options fields contained within the associated link. In this way the network link exhibits a capability when at least one of the link's routers requests that the capability be asserted.

99

IPv6 Routing

R3#show ip ospf database network

LS age: 992

Options: (V6-Bit E-Bit R-bit DC-Bit)

LS Type: Network Links

Link State ID: 3 (Interface ID of Designated Router)

Advertising Router: 26.50.0.1

Attached Router: 26.50.0.1




DR

R4

R3

26.50.0.

1

26.50.0.

2

R1

R2

3

R6

26.50.0.

4

OSPF Network LSA

Area 0 26.50.0.

3 64

100

IPv6 Routing

OSPF Intra-Area Prefix LSA

101

IPv6 Routing

OSPF Intra-Area Prefix LSA Description

LS Type 0x2009; this is a new LSA in OSPFv3

Used in order to advertise one or more IPv6 prefixes.

The prefixes are associated with router segment, Stub network segment or transit network segment.

Whereas with OSPFv2 link address information was carried directly in Router and Network LSAs

# Prefixes is the number of prefixes advertised

Each IPv6 address is associate with:

Address Prefix, Prefix Length, and Prefix Options

The three fields Referenced LS type, Referenced Link State ID, Referenced Advertising Router identifies the Router LSA or Network LSA that the Intra-Area-Prefix-LSA should be associated with

102

IPv6 Routing

OSPF Intra-Area Prefix LSA Options

This 8 bit field serves as input to the various routing calculations

NU-bit: The "no unicast" capability bit. If set, the prefix should be excluded from IPv6 unicast calculations, otherwise it should be included.

LA: "local address" capability bit. If set, the /128 prefix is actually an IPv6 interface address of the advertising router.

MC: the "multicast" capability bit. If set, the prefix should be included in IPv6 multicast routing calculations.

P: The "propagate" bit. Set on NSSA area prefixes that should be re-advertised at the NSSA area border.

P MC LA NU

103

IPv6 Routing

Area 0

R3#show ip ospf database prefix

Net Link States (Area 1)

Routing Bit Set on this LSA

LS age: 428

LS Type: Intra-Area-Prefix-LSA

Link State ID: 1003


LS Seq Number: 80000009

Checksum: 0x5899

Length: 44

Referenced LSA Type: 2002

Referenced Link State ID: 3

Referenced Advertising Router: 26.50.0.1

Number of Prefixes: 1

Prefix Address: 3FFE:FFFF:1::

Prefix Length: 64, Options: None, Metric: 0

DR

R4

R3

26.50.0.

1

26.50.0.

2

R1

R2

3

R6

26.50.0.

4

OSPF Intra-Area Prefix LSA Transit

26.50.0.

3

3ffe:ffff:1::/64

64

104

IPv6 Routing

OSPF Link LSA

Router Priority Options

Link Local Interface Address

Number of Prefixes

Prefix Length Prefix Options 0

Address Prefix


Address Prefix

105

IPv6 Routing

OSPF Link LSA Field Descriptions

LS Type 0x2008; this is a new LSA in OSPFv3

Generated for every link, and flooded only on a given link.

It has the following three purposes:

1. Since Router and Network LSAs only announce topology information, the Link-LSA announces the link-local address of a router to all other routers attached to the link. This is needed for next hop calculation.

2. Link LSAs announce to other routers attached to the link a list of IPv6 prefixes associated with the link; a link can have more than one IPv6 address.

3. On a Multi-access networks, Link LSAs will announce the options capability of a given router to DR this will allow the DR to sets it’s options capabilities in Network LSA as OR'd options of all attached routers.

Link local interface address is used for next hop calculation

# Prefixes is the number of prefix advertised

Link LSAs can also advertise a list of IPv6 prefixes identified by Address prefix, PrefixLength, and PrefixOptions to other attached routers. For example a DR will include this list of IPv6 prefix advertised by a router in its Intra-area Prefix LSA

Link State ID in the common header of the Link LSA is set to router’s Interface ID on the link.

106

IPv6 Routing

Link LSA of R3 For LAN1

Area 0 R4

R3

1

DR

R1

64

R3#show ip ospf database link

Link (Type-8) Link States (Area 0) LS age: 1936 Options: (V6-Bit E-Bit R-bit DC-Bit) LS Type: Link-LSA (Interface: FastEthernet0/0) Link State ID: 3 (Interface ID) Advertising Router: 26.50.0.3 LS Seq Number: 8000002E Checksum: 0xD7B3 Length: 68 Router Priority: 1 Link Local Address: FE80::204:C1FF:FEDB:2FA0 Number of Prefixes: 2 Prefix Address: 3FFE:FFFF:1:: Prefix Length: 64, Options: None

R2

3ffe:ffff:1::/64

107

IPv6 Routing

OSPF Inter-Area Prefix LSA

OSPFv2

OSPFv3

Network Mask

0 Metric

TOS TOS Metric

0 Metric


Address Prefix

108

IPv6 Routing

OSPF Inter-Area Prefix LSA Description

LS Type 0x2003; similar to an OSPFv2 inter-area LSA Type 3

Announced by ABRs of destinations outside of the area

All TOS field have been suppressed

In OSPFv2 Link State ID in the LSA header contained IP destination out side of the area and the mask is in the body of the LSA

In OSPFv3 Link State ID is just a fragment number and the prefix is moved into the body of the LSA

All Prefix in OSPFv3 is defined by 3 fields:

Address Prefix, Prefix Length, and Prefix Options

109

IPv6 Routing

R6#sh ipv6 ospf database inter-area prefix 3FFE:FFFF:2::/64

Inter Area Prefix Link States (Area 0)

Routing Bit Set on this LSA

LS age: 81

LS Type: Inter Area Prefix Links

Link State ID: 5


Metric: 65

Prefix Address: 3FFE:FFFF:2::

Prefix Length: 64, Options: None

OSPF Inter-Area Prefix LSA

Area 0

R3

26.50.0.

1

26.50.0.

2

R2

1 64

64 3ffe:ffff:2:/64

ABR

3ffe:ffff:2::/64

metric 11

DR

R4 R1

R6

ABR

110

IPv6 Routing

OSPF Inter-Area Router LSA

OSPFv2

OSPFv3

LS Type 0x2004; announces the location of ASBR (Type 4 in OSPFv2)

In OSPFv2 Link State ID in the header contain the Router ID of the ASBR

In OSPFv3 Link State ID is just a fragment number and ASBR Router ID is inside the body of LSA

The OSPFv2 the mask field is suppressed in OSPFv3 (was not used OSPFv2 either)

Network Mask

0 Metric

TOS TOS Metric

0 Options

0 Metric

Destination Router ID

111

IPv6 Routing

R3#show ipv6 ospf database inter-area router Inter Area Router Link States (Area 1) LS age: 60 Options: (V6-Bit E-Bit R-bit DC-Bit) LS Type: Inter Area Router Links Link State ID: 1207959556 Advertising Router: 26.50.0.3 Metric: 128 Destination Router ID: 72.0.0.4

OSPF Inter-Area Router LSA Details on R3

R3

Area 0 1

64

R2

64 R4 R1

3ffe:ffff:a::/64

External Route

R8

ASBR RID

72.0.0.4 ABR

Type 0x2004

R6 R3

64 1

112

IPv6 Routing

OSPF External LSA

OSPFv2

OSPFv3

Network Mask

E0000000 Metric

Forwarding Address

External Route Tag

E TOS TOS Metric

00000EFT Metric

Prefix Len Options Referenced LS Type

Address Prefix (128 bits)

Forwarding Address (128 bits, optional)

External Route Tag (optional)

Referenced Link State ID (optional)

113

IPv6 Routing

OSPF External LSA Description

LS Type equal to 0x4005; has AS flooding scope (ABR does not modify them)

NSSA External uses 0x2007 (area flooding scope)

Describe destinations external to the AS (similar to Type 5 in OSPFv2)

Here are some changes from OSPFv2:

The Link State ID of an AS-external-LSA has lost all of its addressing semantics, it is used just to distinguish between multiple external LSA originated by the same ASBR

The prefix is described by the Prefix Length, Prefix Options and Address Prefix fields embedded within the LSA body.

Link-local addresses can never be advertised in AS-external-LSAs

114

IPv6 Routing

OSPF External LSA continued

bit E - Type 1 and 2 as with OSPFv2; the type of external metric.

set, the metric specified is a Type 2 external metric; the metric is considered larger than any intra-AS path.

zero, the specified metric is a Type 1 external metric; it is expressed in the same units as other LSAs

bit F - if set, a Forwarding Address has been included in the LSA

bit T - if set, an External Route Tag has been included in the LSA

Referenced LS type is normally set to zero and Referenced LS ID is not used

If a router advertising an AS External LSA wants to announce additional information regarding external route that is not used by OSPF itself (for example BGP external route attribute) it sets Referenced LS type and Referenced Link State ID in order to announce additional information.

115

IPv6 Routing

R3#show ip ospf database external Type-5 AS External Link States Routing Bit Set on this LSA LS age: 473 LS Type: AS External Link Link State ID: 5 Advertising Router: 72.0.0.4 LS Seq Number: 80000001 Checksum: 0x77AB Length: 36 Prefix Address: 3FFE:FFFF:A:: Prefix Length: 64, Metric Type: 2 Metric: 20

Area 0 R4

R8

RID ASBR

72.0.0.4

64

R3

64

3ffe:ffff:a::/64

External Route

External Type 5

R6

OSPF External LSA Details

64

116

IPv6 Routing



RIPng

BGP4+

OSPFv3

PIM-SM

117

Multicast Operational Models

Any-Source Multicast (ASM)

Basic PIM-SM

Smaller-scale many-to-many applications

“Few-to-many” applications

Examples: Conferencing, small chat rooms, data distribution

Bidirectional PIM (PIM-Bidir)

Larger-scale many-to-many applications

Examples: Full-participation voice/video/multimedia conferencing, massively multiplayer gaming, large chat rooms

Single-Source Multicast (SSM)

PIM-SSM

Single-to-many applications

Examples: Audio, video content distribution

Requires MLDv2 (equivalent to IGMPv3 for IPv4)

IPv6 Routing 118

Rendezvous Point (RP) Discovery

PIM-SM, PIM-Bidir require RP for shared trees

PIM-SSM does not require RP

Static RP Configuration

Currently most widely used method for IPv4 multicast

But will it scale operationally?

Bootstrap Router (BSR) protocol

Embedded RP addresses

Promising for automated RP discovery without added mechanism

No Auto-RP for IPv6

Never widely deployed anyway

IPv6 Routing 119

Embedded RP Addresses: RFC 3306

IPv6 Routing 120

Embedded RP Addresses

IPv6 Routing 121

Embedded RP Addresses: Shortcomings

RP failure management (BSR) problematic

Because RP tied to multicast address

MSDP or equivalent not available for IPv6

Anycast-RP useful only for “cold start”RP failover

IPv6 Routing 122

Inter-Domain IPv6 Multicast

MP-BGP

SSM models with PIM-SSM

ASM models problematic

No IPv6 version of MSDP

Embedded RP might help here

For now, “big SSM communities” will work

But need a more scalable solution for the long run

IPv6 Routing 123



124

Spirent TestCenter

LISP Testing

125

LISP Topic Overview

What is LISP?

LISP Positioning

What problem is LISP solving?

The LISP EID and RLOC and Mappings

LISP IP Encapsulation Scheme

Example LISP Topology

LISP Topology Details

The LISP Mapping System

Spirent TestCenter LISP Features

Spirent TestCenter LISP Router Actions

126

What is LISP?

Locator/Identifier Separation Protocol (LISP) is a "map-and-encapsulate" protocol

It is currently developed by the Internet Engineering Task Force LISP Working Group

http://datatracker.ietf.org/wg/lisp/charter/

LISP Separates out device location from device identifier

127



LISP Positioning

128

What problem is LISP solving?

What's the Problem?

The current Internet routing and addressing architecture uses a single namespace, an IP address, to simultaneously express two functions about a device:

its identity

how it is attached to the network

What is LISP?

LISP is a network architecture and set of protocols that implements a new semantic for IP addressing

LISP creates two namespaces and therefore uses two IP addresses:

Endpoint Identifiers (EIDs) which are assigned to end-hosts

Routing Locators (RLOCs) which are assigned to devices (primarily routers) that make up the global routing system.

129

The LISP EID and RLOC and Mappings

130

LISP IP Encapsulation Scheme

131

Example LISP Topology

This is an example of a 3-site topology used to verify Spirent’s LISP implementation with a DUT acting as LISP Server/Resolver/ETR.

DUT

ITR: Ingress Tunnel Router ETR: Egress Tunnel Router

132

LISP Topology Details The basic idea behind the separation is that the Internet architecture combines two functions, routing locators (where you are attached to the network) and identifiers (who you are) in one number space: the IP address.

LISP supports the separation of the IPv4 and IPv6 address space following a network-based map-and-encapsulate scheme (RFC 1955).

In LISP, both identifiers and locators can be IP addresses or arbitrary elements like a set of GPS coordinates or a MAC address

LISP Terminology:

Routing Locator (RLOC): A RLOC is an IPv4 or IPv6 address of an egress tunnel router (ETR). A RLOC is the output of an EID-to-RLOC mapping lookup.

Endpoint ID (EID): An EID is an IPv4 or IPv6 address used in the source and destination address fields of the first (most inner) LISP header of a packet.

Egress Tunnel Router (ETR): An ETR is a router that accepts an IP packet where the destination address in the "outer" IP header is one of its own RLOCs. ETR functionality does not have to be limited to a router device. A server host can be the endpoint of a LISP tunnel as well.

Ingress Tunnel Router (ITR): An ITR receives IP packets from site end-systems on one side and sends LISP-encapsulated IP packets toward the Internet on the other side.

133

The LISP Mapping System

With LISP, the network elements (routers) are responsible for looking up the mapping between EIDs and RLOCs

This process is invisible to the Internet end-hosts

The mappings are stored in a distributed database called the mapping system, which responds to the lookup queries

The Mapping system is a DNS-like indexing system called DDT (Delegated Database Tree)

draft-fuller-lisp-ddt-03.txt LISP Delegated Database Tree

Internet end-hosts look up other end-hosts EIDs using DNS

This remains unchanged

Internet routers look to see if a RLOC exists for an EID using LISP protocols (e.g., DDT)

This is new 134

Spirent TestCenter LISP Features LISP is supported on all Spirent TestCenter Modules

Run traffic and control-plane; Bound Stream Blocks make testing simple

Both IPv4 and IPv6 locator address family supported

Locator address family dictates how it is stacked (dual stack, could be two ipv4 headers)

Spirent TestCenter Device's roles can be both ETR and IGR, or either

Real-time Changes with Spirent TestCenter; Dynamic change exercises LISP in DUT

Your locator address family dictates which map resolver will be enabled and you can set the IP address

You can put the mapping record in the request; set up the authentication key

Counter for how often we send out map registers

Prefix link, the list of site network count is the count for that particular site, like a network block

Setting up LISP site(s) is as easy as setting up a network block

Multiple block support

Management & Change of prefix length, address increment, negative mapping request will be dropped, etc.

Static locator configurations

135

Locator ID Separation Protocol (LISP) functions

ITR

Spirent TestCenter Port 1 Spirent TestCenter Port 2

IPv6 EIDs ETR IPv6 EIDs MS MR

LISP Tunnel (IPv6 in IPv4)

IPv4 Internet

Use Spirent TestCenter to test the MS and MR functions and scale of a SUT • Spirent TestCenter “Devices” Emulate either the ETR, or ITR, or both (xTR) • The ETR will register its EID-to-RLOC associations with the Map Server (MS) • The ITR looks up destination EID-to-RLOC associations with the Map Resolver • The ITR encapsulates the IPv6 traffic from its IPv6 EIDs as: IPv4/UDP/LISP/IPv6 • The encapsulated Traffic is routed “normally” through the IPv4 Internet • ETR decapsulates and sends the traffic as the original IPv6 packets to its IPv6

EIDs (note that Spirent TestCenter does not need to decapsulate the traffic)

IPv4 RLOC

IPv4 RLOC

System Under Test

136

Emulated Device Interface

Create any Device to Start; can also use other Emulation

Set the Encapsulation EII/IPv4, Source MAC and IPv4 Address

In this example the RLOC will be IPv4 and the EIDs will be IPv6

Does NOT use Links or the Router ID (depicted in the call out)

137

Device LISP tab Address Family and Role

Use the Technology Selector not Device Wizard to enable

Locator Address Family is the network facing IP version

This determines IP version of the Map Resolver and Map Server

Device can be ITR, ETR, or both (xTR)

This Determines whether to use the Map Resolver and Map Server

138

Device LISP tab continued

Authentication Key is used for the Map-Register messages

Select to Enable Mapping Record in Request or not

selected it enables inclusion of mapping reply record inside Map-Request messages

Map Register Timer is only applicable for the ETR

determines the frequency of sending Map Register messages

See next slide to Edit LISP Site Configurations...

139

Edit LISP Site Configurations ITR will use it as a source endpoint for a Stream Block

ETR will use it as a destination endpoint for a Stream Block

ETR will also use it to send Map-Register message to MS

ITR will also use it with the associated Stream Block to resolve the EID-to-RLOC with the MR and to encapsulate the traffic accordingly

140

Traffic Wizard Endpoints Select IPv6 Encapsulation and Unidirectional Pair

can be Bidirectional if both are xTR

Select ITR LISP Site as the Source and ETR Site as the Destination

141

Traffic Wizard Tunnel Binding

Determines how the Traffic will be encapsulated (IPv6 in IPv4 for our example)

Bottom label is the ITR which is doing the Encapsulation

ignore the bogus Router ID as it’s just how Spirent TestCenter identifies its Devices; it is not used with LISP though

ignore that it says label; this screen format is also used for MPLS

Destination determines the EID-to-RLOC to resolve with the MR

142

Bound Stream Blocks before and after

Before starting the Device the status is Amber; resolve needed:

After starting the Devices the Status is Green; resolved:

When started the ITR sends a Map Request to the MR automatically to resolve the tunnel information for the associated Stream Blocks

Start all Devices

143

Spirent TestCenter LISP Router Actions

Start LISP

Stop LISP

LISP Mapping Request

Show Local Cache

Set Default Map Resolver Address

Set Default Map Server Address

Right-click on a LISP Device

144

LISP Results

145

Good to know

LISP Uses UDP Ports 4342 for LISP Control, and 4341 for LISP Data

For Data, the headers are: Ethernet II, IPv4, UDP, LISP, IPv6

LISP Data Header is only 8 bytes; consider this for minimum frame size

The ETR will register its EIDs/RLOC associations with the Map Server (MS) (Map-Register messages) (MS updates the MR)

The ITR looks up destination EIDs/RLOC associations with the Map Resolver (MR) (Map-Request messages)

For back-to-back it seems like we can send a Map Register from the ETR into “ether” (i.e., our ITR does not do anything with it). But we can send out a MAP Request from the ITR and the ETR will respond like it was also emulating an MR.

Spirent TestCenter ETR does not decapsulate the traffic

it does not need to and still uses the Signature field at the end

146

Spirent TestCenter

PIM-SM/SSM Testing

147

PIM-SM/SSM Testing

PIM Topic Overview PIM and Multicast Features

PIM Testing Overview

PIM Emulation Scenarios

Testing the DUT as the FHR, RP, LHR

Sample Command Sequence

Technology Selector

Adding Routers

Device Wizard

Configure VLANs

Device Interface

PIM Routers Configuration

Create Multicast Group

Edit Groups Mapping

Bootstrap Router (BSR) Emulation

PIM Global Options

Sending Multicast Traffic

Starting the Routers

PIM Router Results

148

PIM and Multicast Features PIM Sparse mode (PIM-SM) with Rendezvous Point (RP) mapping

PIM Source Specific Mode (PIM-SSM)

Bidirectional PIM (PIM BiDir)

PIM Bootstrap Router (BSR)

Support for (*, G), (S, G) or (*, *, RP) Multicast groups

Integration with IGP protocols

Integration with IGMP/MLD 1 to 3

Support for IPv4 & IPv6

Multicast Routing Wizard

PIM-SM/SSM Testing 149

PIM Testing Overview

Spirent TestCenter measures the performance of routers in a multicast network, testing data integrity and latency as data is replicated through multicast streams.

The Spirent TestCenter can be configured to test a DUT (device under test) that functions as any of the following:

PIM Router Emulation

Bootstrap Router (BSR)

Multicast edge router

Spirent TestCenter Application uses Protocol Independent Multicast (PIM) emulation between sending and receiving routers, and also uses a routing protocol (OSPF, ISIS, RIP, or BGP) to advertise the network topology if needed.


PIM Emulation Scenarios

PIM-SM/SSM Testing

FHR/RP/LHR PIM Router

Spirent TestCenter

Port 3

FHR/RP Emulated PIM Router

Spirent TestCenter

Port 2

RP/LHR Emulated PIM Router

Spirent TestCenter

Port 4

Emulated Client

Directly connected Emulated Client

Simulated Client

Spirent TestCenter

Port 1

Directly connected Emulated Server

Simulated Server

Emulated Server

Red = Testing the DUT as FHR Blue = Testing the DUT as the RP

Green = Testing the DUT as the LHR

151

Testing the DUT as the FHR

PIM-SM/SSM Testing

Spirent TestCenter

Port A

Spirent TestCenter

Port B

Directly connected Emulated Server

RP PIM Router

Emulated Server

Simulated Client

(S,G) Join/Prune Register Stop

Multicast Traffic

Register Traffic

Multicast Traffic

1. Establish PIM Adjacency between DUT and Spirent TestCenter Port B 2. Send BSR message announcing Emulated Router on Port B as the RP for (*,G) 3. Send Multicast Traffic from Emulated Server on Spirent TestCenter Port A 4. DUT automatically Register Encapsulates the multicast traffic and sends to Port B 5. Emulated PIM router on Spirent TestCenter Port B sends (S,G) Joins/Prunes

and watch for DUT to start/stop multicast traffic accordingly 6. Emulated PIM router on Spirent TestCenter Port B sends Register Stop messages

and watch for DUT to stop Register traffic accordingly NOTE: On Spirent TestCenter today, Register Stop messages need to be built and sent

manually. Although the whole process above can be automated via Command Sequencer

FHR PIM Router

152

DUT as the FHR: Sample Command Sequence


Testing the DUT as the RP

PIM-SM/SSM Testing

Spirent TestCenter

Port A

Spirent TestCenter

Port B

FHR PIM/OSPF Router

RP PIM Router

LHR PIM Router

Simulated Server

Simulated Client

(S,G) Join/Prune Register Stop

Multicast Traffic

Register Traffic Multicast Traffic

1. Establish PIM Adjacency between DUT and Spirent TestCenter Ports A & B 2. Use OSPF to advertise Simulated Server's subnet on Port A 3. Send Multicast Traffic from Simulated Server on Spirent TestCenter Port A 4. Optionally send Register Encapsulated Multicast Traffic from Port A 5. Emulated PIM router on Spirent TestCenter Port B sends (S,G) Joins/Prunes

and watch for DUT to start/stop multicast traffic accordingly. NOTE: On Spirent TestCenter today, Register Encapsulated Multicast Traffic needs to be built

and sent/stopped manually. Although the whole process above can be automated via the Command Sequencer.

(S,G) Join/Prune

154

Testing the DUT as the LHR

PIM-SM/SSM Testing

Spirent TestCenter

Port A

Spirent TestCenter

Port B

RP PIM/OSPF Router

LHR PIM Router

Directly Connected Emulated Client

Simulated Server

Emulated Client

(S,G) Join/Prune

Multicast Traffic

Multicast Traffic

1. Establish PIM Adjacency between DUT and Spirent TestCenter Port A 2. Use OSPF to advertise Simulated Server's subnet on Port A 3. Send Multicast Traffic from Simulated Server on Spirent TestCenter Port A 4. Emulated Client on Spirent TestCenter Port B sends IGMP Joins/Leaves

and watch for DUT to start/stop multicast traffic accordingly. NOTE: On Spirent TestCenter today, Multicast Traffic needs to be sent/stopped manually.

Although the whole process above can be automated via the Command Sequencer.

IGMP Join/Leave

155

PIM-SM/SSM Testing

Technology Selector

The Technology Selector is used to filter protocols seen in the Spirent TestCenter Application.

The tool automatically opens each time the Application is launched.

Users can add unselected protocols to a test at any time by clicking the Technology Selector button from the main toolbar.

156

PIM-SM/SSM Testing

Adding Routers

Spirent TestCenter offers you different options to add routers:

From either the All Ports or Individual Ports grids

Manually or using the Create Devices Wizard

or use a combination of any of the above

157

PIM-SM/SSM Testing

Device Wizard – Select Ports

During a single Router Wizard session you can add one or more Routers to one or more Ports.

However, all of the Routers added have similar attributes.

For example, they may all have the same encapsulation and support the same protocols.

Multiple Router Wizard sessions can be used to add different Routers with different attributes.

158

PIM-SM/SSM Testing

Device Wizard – Select Protocols

Select the routing protocol(s) to run on these routers.

Select whether to launch Route Wizard when finished (not for PIM).

159

PIM-SM/SSM Testing

Device Wizard – Encapsulation

Choose the Upper layer protocol (IPv4 only, IPV6 only, or both)

You can also add one or more (i.e., a stack) of 802.1Q tags by checking the “Number of VLAN Headers” option.

When this is selected, the Configure VLANs step will appear.

160

PIM-SM/SSM Testing

Device Wizard – Configure VLANs

The following slide has more information about this.

Ethernet Frame

D A

Ether- Type FCS Data

802.1Q Customer Tag (C-Tag)

TPID CoS Priority

VLAN ID

C F I

S A

802.1Q Service Provider Tag (S-Tag)

TPID CoS Priority

VLAN ID

D E

161

PIM-SM/SSM Testing

Configure VLANs continued

The example on the previous slide had 2 VLAN headers configured (i.e., Q-n-Q)

VLAN #1 is always the first (top) tag

It is the only tag if only 1 VLAN header is configured

If only 1 tag is configured, its TPID must be 0x8100 per IEEE 802.1Q

Spirent TestCenter only counts it as a VLAN frame when its TPID is 0x8100

The TPID identifies the frame as 802.1Q.

The S-Tag TPID is vendor proprietary.

Some vendors use a unique TPID for the S-Tag to identify the frame as Q-in-Q.

Some common S-Tag TPID values: 0x9100, 0x9200, 0x88a8

The C-Tag TPID is always 0x8100.

For the S-Tag, the Canonical Format Identifier (CFI) has been redefined to be used for Discard Eligible (DE), similar to Frame Relay DE.

162

PIM-SM/SSM Testing

Device Wizard – Configure Routers

Set the number of Routers, Router ID, Router MAC and IP Addresses, Gateway, and Priority (don’t forget the Steps).

163

PIM-SM/SSM Testing

Device Wizard – Configuring PIM

Configure the PIM Mode and DR priority.

Other PIM attributes can be configured outside of the Router Wizard.

164

PIM-SM/SSM Testing

Device Wizard – Preview

A last chance to view the parameters before selecting Finish

165

PIM-SM/SSM Testing

Router Interface

Routing Emulation with Spirent TestCenter is router centric which is more like you would set up a real router.

Go to All Routers > Router Interface tab or to an individual Port’s Routers tab.

The Router Interface tab is the common parameters for all protocols, such as IP address, MAC address, default gateway and so on.

NOTE: You do not have to resolve the Gateway Address (ARP) manually. Rather, it will resolve automatically when the Router is started.

166

PIM-SM/SSM Testing

Router Encapsulation

VLANs, Q-in-Q and other types of encapsulations like GRE tunneling are configured on the Router Interface.

All protocols running on that router inherit the encapsulation.

No need to configure the VLAN on each protocol

IPv6 is enabled when you set the encapsulation on the Router Interface.

All IPv6 related parameters are shown if IPv6 routers are configured (same with VLANs).

167

PIM-SM/SSM Testing

PIM Routers Configuration

Access to the PIM specific parameters.

168

PIM-SM/SSM Testing

Create Multicast Group

Add multicast group

169

PIM-SM/SSM Testing

Edit Groups Mapping

Since Spirent TestCenter does not listen to Bootstrap messages, you must configure the RP IP Address manually.

170

Bootstrap Router (BSR) Emulation

PIM routers enabled for BSR functionality generate bootstrap messages (BSM) periodically.

The BSR is configured with a list of group RP mappings.

Use the RP Mapping dialog to develop the list of group-RP mappings the BSR router should multicast.


PIM-SM/SSM Testing

PIM Global Options

Use the fields on this grid to set global PIM test parameters.

Values you enter are used for all PIM routers and groups in the test.

172

PIM-SM/SSM Testing

Sending Multicast Traffic

173

PIM-SM/SSM Testing

DUT PIM Neighbor – Before

174

PIM-SM/SSM Testing

Starting the Routers

Right click or use Start Router button.

175

PIM-SM/SSM Testing

DUT PIM Neighbor – After

Now the DUT has new PIM neighbors.

176

PIM-SM/SSM Testing

PIM Router Results

PIM protocol counter

PIM Router Event Log

177



178

Spirent TestCenter

MPLS-TP Testing

179

MPLS-TP Topic Overview

MPLS-TP Features

MPLS-TP: RFC Check

How Does MPLS-TP Work?

MPLS-TP: GAl / G-Ach (RFC 5586)

MPLS-TP OAM

Relationship of MPLS-TP Concepts

MPLS-TP Static LSP Fault OAM (RFC 6427)

Fault OAM Configuration and Results

MPLS-TP OAM Wizard (includes Linear Protection)

MPLS-TP Wizard: LSP Ping

MPLS-TP BFD PDU Templates

MPLS-TP Linear Protection

MPLS-TP Y.1731 OAM Performance Monitoring

MPLS-TP Testing 180

MPLS-TP Testing

MPLS-TP Features

Support for MPLS-TP LSP and Pseudowires over LSPs

Support for GAL and GACH

Support for VCCV, LSP-PING, BFD over MPLS-TP Tunnel

Support for Y.1731 over PW or LSP

Dynamic Real-time manipulation of tunnels

Full Topology Emulation support

Complements PTP and dynamic MPLS in a single Topology Emulation chain

181

MPLS-TP Features continued

Create 10’s of thousands MPLS-TP circuits per port

Model Real-time provisioning of circuits

Test what will break the Device Under Test (DUT)

Control word support

Signal in band our out of band OAM

LSP-PING, BFD, VCCV, Y.1731overPW

Model any customer OAM test scenarios

Start and Stop OAM in Real-time

Full Traffic Wizard Integration

Traffic wizard understands MPLS-TP CEs

Perform L2-7 testing over MPLS-TP Circuits

Provision 1588v2 and SyncE over MPLS-TP

Topology emulation in action

MPLS-TP Testing 182

MPLS-TP: RFC Check

MPLS-TP Testing

Note: Green checked items are supported in Spirent TestCenter

183

How Does MPLS-TP Work?

MPLS-TP is a variant of the traditional MPLS services that have been in use for many years in IP networks.

MPLS-TP uses Generalized MPLS (GMPLS) to provide deterministic and connection oriented behavior using LSPs (Label Switched Paths), making it a dependable transport protocol.

MPLS-TP also uses Targeted LDP (T-LDP) to set up pseudowires (PWs) over GMPLS LSPs, to provide VPWS (Virtual Private Wire Service) and VPLS (Virtual Private LAN Service).

MPLS-TP mandates running protocols such as BFD (Bidirectional Forwarding Detection) over GMPLS LSPs and PWs, to provide OAM functionality.

MPLS-TP Testing 184

How Does MPLS-TP Work? Continued

MPLS-TP does not assume IP connectivity between devices, and explicitly rules out related features of normal MPLS, such as PHP (Penultimate Hop Popping, ECMP (Equal Cost Multipath), and LSP Merge.

MPLS-TP specifies how very fast protection and restoration will be achieved using switchover to backup paths.

MPLS-TP allows LSPs and PWs to be signaled using a control plane (using RSVP-based GMPLS signaling and Targeted LDP signaling), or to be statically configured.

MPLS-TP Testing 185

How Does MPLS-TP Work? Continued For fault detection and localization, each device would run BFD over each PW and each underlying LSP. This works as follows:

Both ends of each LSP send BFD packets over the LSP, typically with very short intervals (10ms being common).

If either end sees an interval between received BFD packets above a certain threshold, it will raise an alarm for the specific service, and report the problem in the content of the BFD packets it transmits.

If either end sees such a problem reported in received BFD packets, it will also raise an alarm for that LSP.

To distinguish BFD packets from other labeled data flowing over the LSP, the BFD packets are pre-pended with a special well-known MPLS label, the "GAL" (GAch Label), which sits at the bottom of the MPLS label stack, and a G-Ach (Generic Associated Channel) header. The terminating device will use the GAL label to determine that the packet is not part of the normal data stream, and the G-Ach header to determine what sort of OAM traffic it is.

When BFD is used over the PW rather than over the underlying LSP, it does not use the GAL label. Instead, all data traversing the PW contains an initial header (the "G-Ach header", or "Control Word") which the terminating device can use to detect whether a packet is normal data or a BFD packet.

As well as raising alarms, BFD is also used to detect when traffic should be switched to pre-provisioned backup LSPs.

MPLS-TP Testing 186

MPLS-TP: GAl / G-Ach (RFC 5586) G-Ach - Generic Associated Channel Support

GAl – Generic Associated label Support

Support for UDP and RAW Encapsulation

BFD_CC and BFD_CV Message types Supported

MPLS-TP Testing 187

MPLS-TP: GAl / G-Ach (RFC 5586)

MPLS-TP Testing

Enable GAL / G-Ach Support

Set UDP or RAW Destination Address And Message format

(BFD_CC and BFD_CV)

188

GAl / G-Ach Positioning

“Spirent TestCenter MPLS-TP BFD supports GAL and G-Ach channelization and headers”

“Dynamically reconfigure BFD GAL headers on the fly”

“Support for RAW and UDP with BFD_CC and BFD_CV support”

MPLS-TP Testing 189

MPLS-TP OAM “Operational, Accounting, and Maintenance”, a key function of MPLS-TP

Spirent TestCenter 3.80 has a rich set of real-time management testing

Bi-directional RSVP

LSP Ping over Bi-dir RSVP

LSP Ping over Bi-dir RSVP with Gal/GAch

LSP Ping over VCCV

LSP Ping over VCCV with Gal/GAch

BFD over VCCV

BFD over VCCV with Gal/GAch

Static MPLS-TP LSP/PW Configuration

LSP Ping Over Static LSP and PW

BFD over Static PW (maybe LSP)

MPLS BFD (LSP Ping bootstrapped BFD)

Protection – ULTIMATE GOAL of MPLS-TP

MPLS-TP Testing 190

MPLS-TP OAM: Spirent TestCenter Support

Draft-ietf-pwe2-static-pw-status-01 (for Cisco)

Draft-ietf-mpls-tp-cc-cv-rdi-02

Draft-ietf-mpls-tp-fault-03

Draft-ietf-mpls-tp-linear-protection-04 (PSC)

Draft-bhh-mpls-tp-oam-y1731-06 (AIS, etc)

MPLS-TP Testing 191

Relationship of MPLS-TP Concepts

MPLS-TP Testing

LSP

PW

GACH

LSP-Ping BFD Y1731

Protection

RSVP/Static

LDP/Static

192

Static MPLS-TP LSP/PW Configuration

Draft-ietf-mpls-tp-identifiers-03

Configure Real-time “Static LSP”

Configure Real-Time “Static Psudowires”

Mapping of LSP/PW<->InOutLabel will be stored in the device

Data Traffic and OAM will run over static LSP/PW

MPLS-TP Testing 193

MPLS-TP Static LSP/PW Block Ease of use setting up MPLS-TP Static tunnels with MPLS-TP tab

Support for Static LSP/PW block, change count on the fly, easy to scale up

Added optional AGI field

MPLS-TP Testing 194

MPLS-TP Static LSP/PW OAM

MPLS-TP Testing

Already support GAL/G-ACh for inband signaling [RFC 5586, RFC 6423]

MPLS-TP Static LSP OAM

OAM on-demand CV: Ping & Traceroute (GAL/G-ACh with IP) [RFC 6426]

OAM Proactive CC: BFD (GAL/G-ACh with raw BFD or IP) [RFC 6428]

OAM Y.7131 CCM: (GAL/G-ACh with Y.1731 channel) [draft-bhh-mpls-tp-oam-y1731]

Y.1731 performance monitoring: Loss measurement (LM) and Delay measurement (DM)

OAM Fault Management(FM): AIS, LDI,LKR (GAL with FM channel) [RFC 6427]

MPLS-TP Static PW OAM

PW Ping & Traceroute (PW-ACh with IP)

PW BFD OAM (PW-ACh with raw BFD or IP)

PW Y.1731 OAM (PW-ACh with Y.1731 Channel)

Ethernet

LSP label

PW label

PW-ACH

Ethernet

LSP label

GAL

G-ACH

PW OAM LSP OAM

BFD IP4/IPv6

UDP

BFD LSP Ping

Y.1731 BFD IP4/IPv6

UDP

BFD LSP Ping

Y.1731 FM

195

MPLS-TP Static LSP Fault OAM (RFC 6427) Ability to send Fault messages over Static LSPs

Easy Start/Stop for Fault OAM messages: AIS, LDI, LKR and Clear Fault

Fault OAM State, Last error and TX/RX Fault timestamp

HW Fault Timestamp can be used to measure control plane switchover

Command sequence events, to use as Triggers for MPLS-TP Linear Protection

10,000 LSPs per port [MX-10G] with Fault OAM Active

MPLS-TP Testing

DUT

Traffic

LER

LSR’ LER’

LSR

CE

CE

CE’

LER

Switch Over

196

Fault OAM Configuration and Results

MPLS-TP Testing 197

MPLS-TP OAM Wizard (includes Linear Protection)

Easy to use wizard for Configuring MPLS-TP OAM and Linear Protection

Two modes:

Port to Port switchover

At least 3 Ports Supported on Spirent

TestCenter modules that have multiple ports per port group (EDM-2003, CM-1G )

LSP Switchover, same port

At least 2 Ports Supported on all cards

Measure switchover of DUT <50ms with +/-10 nSec of precision

Wizard builds the topology, topology emulation, and command sequence

MPLS-TP Testing 198

MPLS-TP Wizard: LSP Ping Allows the user to setup LSP-Ping from within the Wizard for MPLS-TP tunnels under scale

LSP-Ping, a key OAM component of MPLS-TP, adds realism to the test and is generally how MPLS-TP is provisioned in the Field

Spirent is Unique at allowing the user to configure LSP-Ping and MPLS-TP in a wizard in one pass

MPLS-TP Testing 199

MPLS-TP BFD PDU Templates RFC 6428 Proactive Connectivity Verification, Continuity Check,

and Remote Defect Indication for the MPLS Transport Profile

MPLS-TP BFD CC-CV RDI PDU templates now added to Spirent TestCenter

For negative testing or user-injected PDU’s for BFD

MPLS-TP Testing 200

MPLS-TP Linear Protection Test Models

MPLS-TP Testing

P(MIP)

PE(MEP) PE(MEP) DUT

MPLS-TP OAM for PWs

Site1A

Site2A

Site1B

Site2B

Provider Side Port Customer Side Port

Traffic CE

CE

CE

CE

P(MIP)

Working LSP Static LSP OAM

Protecting LSP

Static LSP OAM

Trigger

Traffic

DUT

3-port Test

2-port Test

MPLS-TP Topology Emulation

201

MPLS-TP Linear Protection Test Details 1:1 Protection Switching

No Protection Sate Co-ordination(PSC) support, only manual switchover

RFC 6378 and draft-zulr-mpls-tp-linear-protection-switching

Domain editor to view and configure working and protecting MPLS-TP paths

Measure <50ms DUT switchover

Command Sequencer Trigger Events to initiate Switchover

Revertive/Non-revertive with bidirectional traffic

Manual command to switchover STC Tx traffic in <10ms after Trigger event is sent

If working and protecting are on different ports, both ports need to be in the same port group

MPLS-TP Testing 202

MPLS-TP Linear Protection Results

MPLS-TP Testing

Customize DRV view to only select streams from Customer

side ports

203

MPLS-TP Y.1731 OAM Performance Monitoring

MPLS-TP OAM performance monitoring: Delay measurement and Loss measurement

BPK-1192A - MPLS-TP PERFORMANCE MONITORINGBASE PACKAGE (license) [draft-bhh-mpls-tp-oam-y1731-07.txt]

MPLS-TP Testing 204

MPLS-TP Y.1731 OAM Priority Setting

Configurable MPLS TTL and EXP bits (Priority)

MPLS-TP Testing 205



206

Spirent TestCenter

MPLS VPN Testing

207

MPLS VPN Topic Overview MPLS VPN Types Supported

MPLS VPN Supported Technologies

MPLS VPN Test Configuration Wizards

MPLS VPN Wizards Example

Topology Emulation

MPLS Protocols Supported

Routing Software Packages

BGP VPLS Global Options: Versions

Update: LDP-Signaled VPLS

LDP & PWE Protocol Updates

BGP VPLS-AD (Auto Discovery) Support

View MPLS Bindings

Full PGA Support for MPLS QoS(Exp) Bits

Seamless MPLS: VPLS PW Redundancy

Multicast VPN Test Wizard

PWE Wizard Example

MPLS VPN Testing 208

MPLS VPN Types Supported

Layer 2 VPNs:

PWE3 - Pseudo Wire Emulation Edge-to-Edge (RFC 3985, plus others)

BGP VPLS - Virtual Private LAN Service using BGP (RFC 4761)

LDP VPLS - Virtual Private LAN Service using LDP (RFC 4762)

Layer 3 VPNs:

MPLS IP VPN - previously RFC 2547bis (RFC 4364)

mVPN - Multicast VPN (RFC 6037, Rosen draft)

6PE - IPv6 Provider Edge (RFC 4798)

6VPE - IPv6 VPN Provider Edge (RFC 4659)

Wizards for setting up simple and complex environments

Configures CE, P, and PE Routers; LSPs, Routes, and test traffic


MPLS VPN Supported Technologies

MPLS IP VPN or MPLS BGP VPN

6PE/6VPE

Pseudowire Emulation Edge-to-Edge (PWE3)

LDP signaled VPLS/VPWS

BGP signaled VPLS

GRE-Based Rosen Draft 6-8 Multicast VPN (MVPN)

Point-to-Multipoint RSVP-TE (P2MP-TE)

InterAS VPN options A, B, and C

Carrier Supporting Carrier (CSC)

Access over LDP & BGP-signaled VPLS


MPLS VPN Test Configuration Wizards Look Under “MPLS” in the Wizards Selection

MPLS listings appear as seen in the tree

Each of the MPLS Wizards are updated with interactive graphic updates

Graphics support items for both the “Customer and Provider” protocol parameters

Additional “How to Information” is included below the graphics to guide the customer through setup


MPLS VPN Wizards Example

Test Configuration wizards build complete end-to-end test topologies for common test cases


Topology Emulation

Spirent TestCenter supports object-oriented Topology Emulation to test realistic test topologies that include control- and data-plane protocols running over control-plane protocols.

This example shows BGP emulation over an MPLS topology; BGP messages are encapsulated in MPLS labels and transported across the emulated MPLS network – emulating a realistic MPLS network transporting customer routing traffic.

In this example, the emulated CE router exchanges routing information with the DUT, the emulated PE router exchanges routing and label signaling with the DUT, building an emulated MPLS topology.


MPLS Protocols Supported IS-IS and OSPF-TE for provider-side topologies

OSPF and IS-IS-TE support for P2MP-TE capabilities negotiation

LDP and T-LDP label signaling

RSVP-TE with support for graceful restart and Fast ReRoute (FRR)

FRR support for facility and one-to-one failures with make-before-break support

BGP MDT support for MVPN, VPLS auto-discovery, and labeled IP SAFI

BFD support for LDP, T-LDP and RSVP-TE

GRE integration for MVPN testing with optional IPv4 VRFs

Dynamic and static label binding for all label signaling protocols

Dynamic binding for IPv4 GRE tunneling

Access, carrier Ethernet, routing, and switching protocols over MPLS

Application-layer protocols over MPLS

Dynamic binding for control-plane protocols over MPLS

Supported MPLS standards: RFC 4364, RFC 4360, RFC 4461, RFC4610, RFC 4873, RFC 4875, RFC 4970, RFC 4971, RFC 5073, RFC 2547bis, RFC 4364, RFC 4798, RFC 3107, RFC 3031, RFC 3032, RFC 3036, RFC 3037, RFC 3215, RFC 3478, RFC 2205, RFC 3209, RFC 4090, Draft-ietf-ccamp-rsvp-restart-ext, Draft-ietf-ppvpn-vpls-ldp-01, Draft-martini-l2circuit-encap-mpls, Draft-martini-l2circuit-trans-mpls, Draft-martini-ethernet-encap-mpls-01, Draft-martini-ppp-hdlc-encap-mpls-00, Draft-martini-frame-encap-mpls-01, Draft-martini-atm-encap-mpls-01, Draft-lasserre-vkompella-ppvpn-vpls, Draft-ietf-l2vpn-bgp-00 and 02, and Draft-rosen-vpn-mcast-06 to -08


Routing Software Packages

MPLS VPN Testing

Package Name Description Part Number

Unicast Routing Base Package Includes all Unicast routing protocols & GRE for IPv4 and IPv6: BGP, OSPF, IS-IS, & RIP

BPK-1004A/B

Multicast Routing Base Package Includes PIM routing protocols for IPv4 and IPv6: PIM-SM, PIM-SSM, and variants

BPK-1005A/B

MPLS Base Package Includes all MPLS/VPLS protocols: LDP, T-LDP, and RSVP-TE

BPK-1006A/B

BFD Base Package Includes BFD support for Unicast and MPLS single and multihop protocols

BPK-1066A

Unicast Routing Convergence Test Package

Tests convergence for BGP, OSPF, IS-IS and RIP protocols

TPK-1050

215

BGP VPLS Global Options: Versions Specify which VPLS version to use

NOTE: If no VPLS block is configured, the default VPLS version (draft-ietf-l2vpn-vpls-bgp-00) will be used, regardless of the value selected in this field.


Update: LDP-Signaled VPLS

Purpose: Update VPLS to RFC4762

Supported features:

Control word signaling

FEC 129 Support

BGP auto-discovery support

MAC address withdrawal – wildcard, range, or custom list

PWE grouping TLV

Automatic establishment of PWE between VPLS peers


LDP & PWE Protocol Updates

Update STC from outdated Martini draft to RFC4447

Newly supported features:

Status code signaling TLV –Use of LDP notification messages to signal status of PWE or VC.

PW grouping – withdraw all FECs associated with specific group

Wizard updates – added FEC129, multi-segment, and BGP-AD

Control word signaling (FEC128 and FEC129, traffic support)

Multi-segment PWE

FEC129 (Generalized FEC TLV)


BGP VPLS-AD (Auto Discovery) Support

Easy to setup Wizard though the BGP VPLS VPN Generator


BGP VPLS-AD: VPLS AD tab

Simple Wizard Support; Enhanced results


View MPLS Bindings A Total of 8 FEC Types are supported

IPv4prefix (LDP Prefix, BGP IPv4 Labeled [Inter-AS option C])

IPv6prefix (IPv6 Labeled [6PE])

LdpVcFEC128 (LDP VPLS =>VC ID)

LdpVcFEC129 (LDP VPLS =>AGI, SAII and TAII)

BGP VPLS (Near End VE ID, Far End VE ID, RD)

VPNv4 (MPLS IP VPN =>IPv4 VPN Prefix and RD)

VPNv6 (6VPE =>IPv6 VPN Prefix and RD)

RSVP (Tunnel ID/Name)


Full PGA Support for MPLS QoS(Exp) Bits MPLS EXP (QoS) bits uses the first 3 bits of the IP DSCP/TOS (IP Precedence) value – not visible to the user; done at the firmware level

Expanded this feature to support the L2 VPN (VPLS) configurations as well In this case, the VLAN P bits (802.1p) are copied to the MPLS EXP bits

Also exposes the MPLS header stack when the ‘Show ALL Headers’ is enabled to allow the user to explicitly set the EXP bits


Seamless MPLS: VPLS PW Redundancy

Term coined by DT to include MPLS forwarding across the whole network – through the access, edge, aggregation and core

Helps with Less management, flexible and efficient service delivery, lower OPEX cost, high availability

Features that are part of it (see MPLS Topic)

VPLS PW Redundancy

Entropy Labels

Downstream on Demand (LDP signaling)

Other features are coming in successive releases…


MPLS VPN Testing

Multicast VPN Test Wizard

Configure Default and optional

Data MDT – with full control over

MDT switchover and HyperFilters

to view GRE traffic in detail

Control Provider and Customer

PIM protocols with all associated

options, control Multicast Group

addressing, and optionally

Unicast MPLS VRFs

224

MPLS VPN Testing

Multicast VPN Test Wizard Implementation

Provides all you need to quickly test Rosen GRE-Based Multicast VPN (MVPN) based on draft-rosen-vpn-mcast-8.txt

The Multicast VPN wizard combines all areas of MVPN testing:

Configures all protocols for Multicast and Unicast routing of GRE and MPLS

Select individual provider and customer PIM protocols and associated options

Control Default and Data MDT parameters, including switchover times

Full control of all Multicast group addressing

Configure Unicast and Multicast traffic directions independently

Automatically creates GRE Analyzer Filters to sort GRE traffic results

Includes options from MPLS and Multicast wizards for quick, consistent configurations and lower learning curve

225

PWE Wizard Example

The following slides walk through a complete PWE test


PWE3 / VPLS LDP Network Diagram – Router Types

PE PE P

CE’s CE’s

STC Port 1 Customer Side

DUT STC Port 2

Provider Side

DUT = Device Under Test STC = Spirent TestCenter

ER = STC Emulated Router SR = STC Simulated Router

VPN site A

Host MACs

VPN site B

Host MACs

VPN site C

Host MACs

VPN site A

Host MACs

VPN site B

Host MACs

VPN site C

Host MACs


PWE3 / VPLS LDP Network Diagram – Protocols

PE PE P

CE’s

PE to PE Targeted LDP Session

(aka Pseudo Wires)

CE’s


DUT

PE to P LDP Direct

IGP

STC Port 2 Provider Side

802.1Q Trunk



.1

VPN site A

Host MACs

VPN site B

Host MACs

VPN site C

Host MACs

VPN site A

Host MACs

VPN site B

Host MACs

VPN site C

Host MACs


PWE3 / VPLS LDP Network Diagram – IP & VLANs

PE PE P

CE’s


(aka Pseudo Wires)

CE’s


DUT

PE to P LDP Direct

IGP


802.1Q Trunk

20.1.1.0/24 61.1.1.0/24



.1 .2

VLAN A 101

VLAN B 102

VLAN C 103

VPN site A

Host MACs

VPN site B

Host MACs

VPN site C

Host MACs

VPN site A

Host MACs

VPN site B

Host MACs

VPN site C

Host MACs


PWE3 / VPLS LDP Network Diagram – Router IDs, VC IDs

PE PE P

CE’s


(aka Pseudo Wires)

CE’s


DUT

PE to P LDP Direct

IGP


802.1Q Trunk VC IDs: 101, 102, 103

Device MACs: 00:00:01:00:00:0N

20.1.1.0/24

Router ID

3.3.3.1

Router ID

5.5.5.1

61.1.1.0/24



.1 .2

VLAN A 101

VLAN B 102

VLAN C 103

VPN site A

Host MACs

Router ID

4.4.4.4 VPN site B

Host MACs

VPN site C

Host MACs

VPN site A

Host MACs

VPN site B

Host MACs

VPN site C

Host MACs

NOTE: for the Device MAC addresses N starts at 1 MPLS VPN Testing 230

Connect to the Chassis and Reserve the Ports


Configure the Physical Layer

Test Configuration > All Ports


Access the PWE Wizard

Tools> Wizards > Routing > MPLS > PWE Wizard


Configure Topology: Single Segment Type

Single versus Multi Segment


Configure Topology: Multi Segment Type

For a multi-segment test, the DUT can serve as an S-PE router or an Ingress/Egress router


Configure Provider Ports

Select Port, Configure VLAN and IP Information


Configure Provider Routers

Protocols, P and PE Router addresses


Configure Customer Ports

Select Port, Configure VLAN Information


Configure Pseudowires FEC 128 or FEC 129, VC IDs


Configure Hosts

Hosts MAC address and VLANs (if QnQ), used for traffic


Configure Traffic

Uni- or Bi-directional, Traffic Rate


Configuration Summary

Preview the configuration


Emulated Device Interface


Links: Topology Emulation


Provider Side P Device Encapsulation


Provider Side PE Device Encapsulation


Virtual Networks: Pseudowire 1

How label stack is determined


Device’s LDP Configuration

P Router Direct and PE Router Targeted LDP Sessions


P Router’s LSPs

Prefix LSP for PE Router’s ID; Direct LDP Session


PE Router’s LSPs

VC LSP for customer VCs; Targeted LDP Session


P Device’s IGP (OSPF) Configuration


OSPF Router LSAs


OSPF Router LSAs continued


Stream Blocks: Test Traffic Between VPNs

Provider side Stream Blocks not “resolved” yet

Because Devices are not Started yet


Customer side: nothing to resolve

Provider side: not resolved

Stream Blocks Preview: Before


View MPLS Bindings

Right-click on the P Router


View MPLS Bindings: Not Resolved


Start All Devices


Devices Started

IGP Adjacency Full, LDP Sessions Up

Bound Stream Blocks resolved


IGP and MPLS Results


Customer side: no change

Provider side: Resolved/Bound

Stream Blocks Preview: After


View MPLS Bindings Resolved


Start Test Traffic


Test Traffic is Layer 2 only: no IP Ethernet Plus VLAN on CE side

Ethernet Plus MPLS Label Stack on Provider Side


Spirent TestCenter · BFD Solution Summary BFD support for IPv4 and IPv6 routing over ATM,...

Documents

Transcript of Spirent TestCenter · BFD Solution Summary BFD support for IPv4 and IPv6 routing over ATM,...