Spirent TestCenter · BFD Solution Summary BFD support for IPv4 and IPv6 routing over ATM,...
Transcript of 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
Bidirectional Forwarding Detection (BFD) 7
Bidirectional Forwarding Detection (BFD)
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
Bidirectional Forwarding Detection (BFD)
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
Bidirectional Forwarding Detection (BFD)
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
Bidirectional Forwarding Detection (BFD)
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
Bidirectional Forwarding Detection (BFD)
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
Bidirectional Forwarding Detection (BFD) 13
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
Bidirectional Forwarding Detection (BFD) 14
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
Bidirectional Forwarding Detection (BFD) 15
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
Bidirectional Forwarding Detection (BFD)
CORE IP/MPLS
PE (Edge)
PE (Edge)
CDN
BGP/LDP & BFD
Video Distribution
16
BFD Scale Topology
Bidirectional Forwarding Detection (BFD)
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)
Bidirectional Forwarding Detection (BFD) 18
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
IPv6 Routing Topic Overview
Introduction to 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
IPv6 Routing Topic Overview
Introduction to 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
Withdrawn Routes (variable)
Total Path Attribute Length
Path Attributes (variable)
Network Layer Reachability Info (variable)
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.
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)
Attr. Flags Attr. Type Code
Attr. Type Attr. Length Attr. Value
2 bytes 1-2 bytes variable
Attr. Type Attr. Length Attr. Value
Attr. Type Attr. Length Attr. Value
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)
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)
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.
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) Attr. Flags Attr. Type Code
Attr. Type Attr. Length Attr. Value
2 bytes 1-2 bytes variable
Attr. Type Attr. Length Attr. Value
Attr. Type Attr. Length Attr. Value
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
Attr. Type Attr. Length Attr. Value
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
IPv6 Routing Topic Overview
Introduction to 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
Attached Router: 26.50.0.2
Attached Router: 26.50.0.4
Attached Router: 26.50.0.3
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
Advertising Router: 26.50.0.1
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
Prefix Length Prefix Options 0
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
Prefix Length Prefix Options 0
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
Advertising Router: 26.50.0.3
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
IPv6 Routing Topic Overview
Introduction to 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
This Page Left Blank
www.spirentcampus.com
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-SM/SSM Testing 150
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
PIM-SM/SSM Testing 153
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 171
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
This Page Left Blank
www.spirentcampus.com
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
This Page Left Blank
www.spirentcampus.com
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 Testing 209
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 Testing 210
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 Testing 211
MPLS VPN Wizards Example
Test Configuration wizards build complete end-to-end test topologies for common test cases
MPLS VPN Testing 212
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 VPN Testing 213
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
MPLS VPN Testing 214
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.
MPLS VPN Testing 216
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
MPLS VPN Testing 217
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)
MPLS VPN Testing 218
BGP VPLS-AD (Auto Discovery) Support
Easy to setup Wizard though the BGP VPLS VPN Generator
MPLS VPN Testing 219
BGP VPLS-AD: VPLS AD tab
Simple Wizard Support; Enhanced results
MPLS VPN Testing 220
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)
MPLS VPN Testing 221
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
MPLS VPN Testing 222
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 223
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
MPLS VPN Testing 226
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
MPLS VPN Testing 227
PWE3 / VPLS LDP Network Diagram – Protocols
PE PE P
CE’s
PE to PE Targeted LDP Session
(aka Pseudo Wires)
CE’s
STC Port 1 Customer Side
DUT
PE to P LDP Direct
IGP
STC Port 2 Provider Side
802.1Q Trunk
DUT = Device Under Test STC = Spirent TestCenter
ER = STC Emulated Router SR = STC Simulated Router
.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
MPLS VPN Testing 228
PWE3 / VPLS LDP Network Diagram – IP & VLANs
PE PE P
CE’s
PE to PE Targeted LDP Session
(aka Pseudo Wires)
CE’s
STC Port 1 Customer Side
DUT
PE to P LDP Direct
IGP
STC Port 2 Provider Side
802.1Q Trunk
20.1.1.0/24 61.1.1.0/24
DUT = Device Under Test STC = Spirent TestCenter
ER = STC Emulated Router SR = STC Simulated Router
.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
MPLS VPN Testing 229
PWE3 / VPLS LDP Network Diagram – Router IDs, VC IDs
PE PE P
CE’s
PE to PE Targeted LDP Session
(aka Pseudo Wires)
CE’s
STC Port 1 Customer Side
DUT
PE to P LDP Direct
IGP
STC Port 2 Provider Side
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
DUT = Device Under Test STC = Spirent TestCenter
ER = STC Emulated Router SR = STC Simulated Router
.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
MPLS VPN Testing 231
Configure the Physical Layer
Test Configuration > All Ports
MPLS VPN Testing 232
Access the PWE Wizard
Tools> Wizards > Routing > MPLS > PWE Wizard
MPLS VPN Testing 233
Configure Topology: Single Segment Type
Single versus Multi Segment
MPLS VPN Testing 234
Configure Topology: Multi Segment Type
For a multi-segment test, the DUT can serve as an S-PE router or an Ingress/Egress router
MPLS VPN Testing 235
Configure Provider Ports
Select Port, Configure VLAN and IP Information
MPLS VPN Testing 236
Configure Provider Routers
Protocols, P and PE Router addresses
MPLS VPN Testing 237
Configure Customer Ports
Select Port, Configure VLAN Information
MPLS VPN Testing 238
Configure Pseudowires FEC 128 or FEC 129, VC IDs
MPLS VPN Testing 239
Configure Hosts
Hosts MAC address and VLANs (if QnQ), used for traffic
MPLS VPN Testing 240
Configure Traffic
Uni- or Bi-directional, Traffic Rate
MPLS VPN Testing 241
Configuration Summary
Preview the configuration
MPLS VPN Testing 242
Emulated Device Interface
MPLS VPN Testing 243
Links: Topology Emulation
MPLS VPN Testing 244
Provider Side P Device Encapsulation
MPLS VPN Testing 245
Provider Side PE Device Encapsulation
MPLS VPN Testing 246
Virtual Networks: Pseudowire 1
How label stack is determined
MPLS VPN Testing 247
Virtual Networks: Pseudowire 2
MPLS VPN Testing 248
Virtual Networks: Pseudowire 3
MPLS VPN Testing 249
Device’s LDP Configuration
P Router Direct and PE Router Targeted LDP Sessions
MPLS VPN Testing 250
P Router’s LSPs
Prefix LSP for PE Router’s ID; Direct LDP Session
MPLS VPN Testing 251
PE Router’s LSPs
VC LSP for customer VCs; Targeted LDP Session
MPLS VPN Testing 252
P Device’s IGP (OSPF) Configuration
MPLS VPN Testing 253
OSPF Router LSAs
MPLS VPN Testing 254
OSPF Router LSAs continued
MPLS VPN Testing 255
Stream Blocks: Test Traffic Between VPNs
Provider side Stream Blocks not “resolved” yet
Because Devices are not Started yet
MPLS VPN Testing 256
Customer side: nothing to resolve
Provider side: not resolved
Stream Blocks Preview: Before
MPLS VPN Testing 257
View MPLS Bindings
Right-click on the P Router
MPLS VPN Testing 258
View MPLS Bindings: Not Resolved
MPLS VPN Testing 259
Start All Devices
MPLS VPN Testing 260
Devices Started
IGP Adjacency Full, LDP Sessions Up
Bound Stream Blocks resolved
MPLS VPN Testing 261
IGP and MPLS Results
MPLS VPN Testing 262
Customer side: no change
Provider side: Resolved/Bound
Stream Blocks Preview: After
MPLS VPN Testing 263
View MPLS Bindings Resolved
MPLS VPN Testing 264
Start Test Traffic
MPLS VPN Testing 265
Test Traffic is Layer 2 only: no IP Ethernet Plus VLAN on CE side
Ethernet Plus MPLS Label Stack on Provider Side
MPLS VPN Testing 266