Professional Documents
Culture Documents
1/89
2/89
Table of Contents
Alcatel-Lucent Advanced Troubleshooting (AT) Lab & Troubleshooting Guide.........1
Troubleshooting Methodology .................................................................................... 1-8
General Layered Approach ......................................................................................... 1-8
Quantitative vs. Qualitative Service Issues ................................................................. 1-8
Services Context.......................................................................................................... 1-8
Fault Determination vs. Fault Resolution vs. Fault Isolation ..................................... 1-9
The OSI Model A Layered Approach to Network Architecture and Troubleshooting1-10
The Physical Layer .................................................................................................... 1-11
General .......................................................................................................................... 1-11
Alcatel-Lucent Services Model Context ....................................................................... 1-11
The Application Layer (TCP/IP = Layers 5, 6, and 7 of the OSI Model) ................. 1-19
General .......................................................................................................................... 1-19
Lab 1
Section 1.3 Save your configuration to the TFTP Server ...................................... 1-25
Objective: ...................................................................................................................... 1-25
Exercise: ........................................................................................................................ 1-25
Verification:................................................................................................................... 1-25
Questions:................................................................................................................. 1-26
Lab 2
Section 2.2 Use Debugs on the router for analysis ................................................ 2-28
Objective: ...................................................................................................................... 2-28
Exercise: ........................................................................................................................ 2-28
3/89
Lab 3
Lab 4
Lab 5
Lab 6
Lab 7
4/89
Lab 8
Section 8.4 Tracking packet flow in a VPLS with layer 3 termination .................... 8-49
Objection: ...................................................................................................................... 8-49
Exercise: ........................................................................................................................ 8-50
Lab 9
5/89
A.10.
A.11.
6/89
Table of Figures
Figure 1 Demarcations in the Alcatel-Lucent Services Model ....................................... 1-9
Figure 2 The OSI Model .............................................................................................. 1-10
Figure 3 OSI Layer 1 ................................................................................................... 1-11
Figure 4 OSI Layer 2 ................................................................................................... 1-12
Figure 5 OSI Layer 3 ................................................................................................... 1-15
Figure 6 OSI Layer 4 .................................................................................................. 1-18
Figure 7 Layers 5, 6 and 7 of the OSI Model .............................................................. 1-19
Figure 1-1: Physical Connectivity ................................................................................... 1-21
Figure 1-2: IP Connectivity ............................................................................................ 1-24
Figure 1-3: TFTP Server Location ................................................................................... 1-25
Figure 3-1: OSPF Topology............................................................................................. 3-30
Figure 3-2: OSPF Topology............................................................................................. 3-33
Figure 4-1: OSPF-RIP Topology ..................................................................................... 4-34
Figure 5-1: IS-IS Topology.............................................................................................. 5-36
Figure 5-2: IS-IS Topology.............................................................................................. 5-38
Figure 6-1: BGP Topology .............................................................................................. 6-39
Figure 6-2: BGP Route Reflector Topology .................................................................... 6-40
Figure 6-3: BGP and OSPF topology .............................................................................. 6-41
Figure 7-1: Full Mesh of LSPs......................................................................................... 7-43
Figure 8-1: VPLS 4000 .................................................................................................... 8-45
Figure 8-2: H-VPLS ......................................................................................................... 8-47
Figure 8-3: VPLS with Layer 3 Termination ................................................................... 8-49
Figure 9-1: VPRN Setup .................................................................................................. 9-51
Figure 9-2: VPRN With Spoke Termination ................................................................... 9-53
Table of Tables
Table 1-1: Router remote access addresses ..................................................................... 1-22
Table 1-2: Lab 1 command list ........................................................................................ 1-22
Table 2-1: Lab 2 command list ........................................................................................ 2-27
Table 3-1: Lab 3 configuration commands ...................................................................... 3-31
Table 5-1: IS-IS Commands ............................................................................................ 5-37
Table 8-1: Command List ................................................................................................ 8-50
7/89
Troubleshooting Methodology
Start
Problem
Reported
Details Requested of
Customer as reqd
Ticket
Opened
Fault
Determination
Fault
Resolution
Stop
Problems are not necessarily binary in nature. They are not always
on or off. Our experience tells us that sudden network outages,
while hopefully rare, are often caused by some type of hardware
malfunction or physical cabling plant issues. Fibre backbone torn up
by contractors, power outages of equipment in buildings whose
network equipment has not been properly configured with a backup
power supply, EMI sources and sinks, etc., are typically fairly
straightforward to isolate and rectify.
Services Context
Qualitative issues are somewhat more difficult to troubleshoot and
isolate since they often deal with, at least from the customers
perspective, intangiblesthings that are often subject and hard to
quantify. One of the major strengths of the Alcatel-Lucent Services
Routers and Ethernet Services Switches is that they have a rich suite
of tools that can be used to apply metrics to quality of service issues.
Because of the Alcatel-Lucent model of building services, (or service
tunnels) across an IP/MPLS core and the subsequent ability to
segregate customer traffic and manage it in discrete flows, it is
relatively straightforward to troubleshoot QoS issues. SAA, OA&M,
show, and debug commands can be used both in real-time, as well as
for statistical reporting afterwards.
8/89
switches. Troubleshooting up the protocol stack is the preferred approach but it should be
viewed in the context of not only the underlying switched and IP/MPLS infrastructure but
equally importantly in the context of services.
9/89
10/89
General
Troubleshooting Layer 1 can be relatively straightforward. This is the Is it plugged in? layer. In
summary, the physical layer is responsible for bit-encoding and physical cabling topology. It defines how
binary 1s and 0s are represented on the wire and defines the physical interface that devices have with the
cabling topology. For example, Ethernet uses Manchester binary encoding at layer 1 and uses protocols
such as the nWay protocol to negotiate speed and duplex of nodes connecting to the cabling plant.
Common issues as this layer are:
speed, and duplex (for multi-access, non point-to-point links)basic PnP issues.
bit encoding (for example NRZI vs. RZI) for point-to-point serial links
improper category, grade and installation of cabling plant
excessive collisions (multi-access, shared topologies like wireless Ethernet access points, wired
Ethernet hubs)
signal loss due to attenuation, impedance, cable length, cross-talk, EMI and capacitance (cabling
plant again)
mismatched layer 1 setting between nodes (for example laser emitter settings on fibre optic shorthaul vs. long-haul circuits).
11/89
General
The Data Link layer frames / organizes the binary 1s and 0s into frames, labeling each frame with an
address field. For multi-access links such as Ethernet and FDDI, the frame labels the data with both a
source and destination address since the underlying physical topology might be shared media. In point-topoint, non-shared data link configurations such as serial links, a single address field is required since the
data link itself is essentially being identified. These point-to-point data link configurations, often called
virtual circuits, are typical of packet-switched technologies such as ATM, Frame Relay and X.25.
Services that create a pseudo layer 2 are called VLL (Virtual Link Layer) services. ePipe, aPipe and fPipe
create pseudo point-to-point data link configurations. VPLS creates a pseudo multi-access data link
configuration. Troubleshooting these services is discussed briefly in their separate contexts below.
12/89
QoS solutions will often use information in the layer 2 PDU for classification and marking decisions. For
example source/destination SAPs (IEEE service access points), 801.q VLAN ID, 802.1p priority bits and
source/destination MAC addresses might be used to either segregate traffic into different forwarding
classes or to immediately dispatch high-priority traffic to LLQs. Problems often arise if the QoS solution
doesnt properly classify the customers traffic or else properly respect the layer 2 markings which indicate
priority.
VLL Services
PE B
PE C
PE A
IP / MPLS
ePipe
service
Network
PE D
Some Alcatel-Lucent services mimic or emulate layer 2 of the OSI model. For example, VLLs such as
aPipe, ePipe, and fPipe services create logical vs. physical point-to-point data links between peer devices.
The service appears as a single data link or wire between the peer devices. Customer devices (represented
as buildings in the diagram above) that use the service must be on the same IP subnet as a result. Many
problems with VLL type services can be rectified by visualizing the logical layout of the network.
Knowledge of framing, basic organization of the layer 2 PDU including 802.1p, Q-in-Q, 802.1q, as well as
STP are crucial.
The aPipe service uses ATM for transport. Customers traffic is mapped to ATM VCs, creating a VLL
mapped directly to an ATM VC.
13/89
VPLS Service
PE B
VPLS Service
IP/LSP FullMesh
PE C
PE A
IP / MPLS
Network
PE D
The VPLS service extends the customers switched network across the IP/MPLS core. It provides for a
layer 2 class of VPN solution. The IP/MPLS core appears as a logical switch (pictured as a solid rectangle
in the above picture) to the customers equipment. As with VLL services, a thorough knowledge of
trunking, STP and layer 2 prioritization would be useful. For example, if IEEE 802.2 LLC frames are
switched across the network, the network may experience a higher load that Ethernet II frames since the
former is connection-oriented. As such retransmission and basic sequencing and acknowledgement may
create timing issues for the customers traffic if a proper QoS solution where this traffic is not given higher
priority than other flows is not implemented.
14/89
General
According to RFC 791, The Internet Protocol is responsible for providing addressing of the logical data
link between TCP/IP end systems. While it does not, itself, create or manage the logical data link (this is
the responsibility of the Transport Layer), it is responsible for packaging and fragmenting/reassembling
customer data for delivery by intermediate systems (routers) and providing enough information such that
routers can make informed decisions as to where next to transmit the data on a hop-by-hop basis. QoS
solutions can modify this PHB (per-hop behaviour) by respecting the markings in the ToS byte of the IP
header which indicate the requirement for differentiated services in the IP network. Traffic can be marked,
classified and forwarded based on other information found in the IP header including IP version number,
source/destination address, protocol number, etc. Knowledge of the organization of an IP packet, IP
addressing in general and IP address planning / subnetting in general is crucial. Furthermore, access lists
can be created to filter and block traffic based on just about any piece of information in the IP packet
header.
Dynamic routing protocols, both IGPs and EGPs, can take advantage of good subnetting and route
summarization techniquescareful IP address planning to reduce routing table sizes and the complexity
of the forwarding of IP datagrams throughout an IP network. Basic, common sense principles of 1 subnet =
1 wire (pseudo or physical) must be adhered to. Many troubleshooting exercises begin and end with
careful analysis of the per-hop behaviour of traffic through an IP network. Given the network layers
responsibility to address the logical endpoints for TCP and UDP sessions (as well as stateless, tunnelled
traffic such as GRE and IPSec) and routers responsibility to find the best path between the endpoints, it is
hard to overstate its importance.
15/89
VPRN
Service
Red
RI-1
RI-2
PE B
PE C
PE A
RI-1
RI-1
RI-2
RI-2
IP / MPLS
Network
PE D
RI-1
VPRN
Service
Green
RI-2
VPRN is a class of VPN that allows the connection of multiple sites in a routed domain over a provider
managed IP/MPLS network. From the customers perspective it looks like all sites are connected to a
private routed network administered by the service provider for that customer only. The Service provider,
however, can reuse the IP/MPLS infrastructure to offer multiple services.
Each VPRN appears like an additional routing instance, routes for a service between the various PEs are
exchanged using MP-BGP. From a troubleshooting perspective this is critical because each service
contains a separate instance of routed traffic, segregating the customers routed traffic and allowing traffic
conditioning, shaping, modified PHBs and other QoS policies to be managed individually. More
importantly, unless there is some catastrophic, universal problem in the IP/MPLS core, each customers
traffic can be troubleshooted separately too. This is the P for Private in VPRN. Effectively the
customers traffic flows in virtual, private, managed layer 3 domains in the same way the with the VPLS
service the customers traffic flows in virtual, private, managed layer 2 domains.
Since the SDPs tie into the providers IP/MPLS core and are signalled within the context of IP tunnels or
MPLS/RSVP, they are sensitive to bad design and other faults in the underlying layer 3 infrastructure.
Also, another troubleshooting nexus is the use of the customers own IP address structure, often using their
own RFC 1918 addresses when connecting to sites through the service providers service tunnels. This
often means that troubleshooting is done on two planes, the service provider network and the customers
virtual reality network.
16/89
IES Service
Internet
Company C
PE C
CE C
PE A
CE A
Company A
Service Provider
Network
PE B
CE B
Company B
From the customers perspective the IES provides a direct connection to the Internet. The Service provider
can apply all billing, ingress/egress shaping and policing to the customer. Unlike the VPRN service, there
is no separation at the network layer for the customer and the service provider. This coupling of customer
traffic to the service providers network may make troubleshooting more problematic in some
circumstances as natural demarcation points may be hard to find at the network layer. However, using
hierarchical routing protocols, good route summarization techniques and redistribution between the access
layer and the edge may aid in fault isolation.
17/89
General
In an IP network there are two transport layer protocols, TCP and UDP. TCP is connection-oriented and
UDP is connectionless. TCP and UDP share source and destination port numbers that can be used as
discriminators for a variety of filtering and QoS decisions. These port numbers are associated with and
identify application layer protocols on the server side of the connection such as Telnet, FTP, SMTP, etc. In
addition, because TCP is connection oriented, it has additional fields that manage the state of the
connection (the control field) as well as sequencing (sequence number and acknowledgement number) as
well as receiving windows size, etc. As a consequence, TCP has more overhead per unit data than UDP.
From a troubleshooting standpoint, what makes TCP somewhat problematic is that the devices inside the
service providers network tend to be ignorant of the TCP session parameters since this is largely the
responsibility of the endpoints of the TCP connectionthe customers devices. While these TCP
parameters may used for input classification decisions, for example, as part of a QoS solution, congestion
issues in the service providers network can be exacerbated by the retransmission of data segments and
other spurious signalling initiated by the customer end systems, causing a cascading effect in extreme
situations. Furthermore, customers applications may time out if there is not sufficient priority given to
TCP connection setup in the QoS solution offered by the service provider.
18/89
General
Layers 5, 6, and 7 of the OSI model are often represented as a layer 5 of the TCP/IP stack. Since there is
no RFC that defines an application layer nor for that matter a layered network architecture, this
simplification is debatable and can often lead to errors when troubleshooting a network. For example, layer
5 of the OSI model, the session layer, is a management layer that indicated to the transport layer what level
or type of service is required for the transport of application layer protocols.
The requirement for encryption at the transport layer, connection-oriented vs. connectionless transport, etc.,
is indicated by the session layer. While, some may view this as an unnecessary distinction in
troubleshooting a service-oriented solution which does not classify traffic based on any information
above layer 4.knowledge of timers, synchronization and other application layer behaviours will be useful
in conceptualizing problems. For example, knowing how a VoIP call, is setup, calls progress and then
sessions are torn down might prove useful.
19/89
While classification and differentiated services for an application layer protocol occur at a lower layer of
the OSI model in the Alcatel-Lucent services model, the symptoms of inadequate network provisioning and
outages will be seen first at the application layer. This, of course, is what prompts our customers to call us
in the first place.
As was indicated earlier, as we progress up through the layered network protocol stack, more specialized
knowledge of the protocols is required.
20/89
21/89
Pod Number
Router Name
Connect Address
Pod 1 -
P1R1
192.168.161.221
P1R2
192.168.161.241
P1R3
192.168.161.231
P2R1
192.168.161.222
P2R2
192.168.161.242
P2R3
192.168.161.232
P3R1
192.168.161.223
P3R2
192.168.161.243
P3R3
192.168.161.233
P4R1
192.168.161.224
P4R2
192.168.161.244
P4R3
192.168.161.234
Pod 2 -
Pod 3 -
Pod 4 -
Syntax:
Commands required for this exercise are found in Table 1-2. Detail may be found in Module 1, IGP
Review. Each command may have additional parameters possible. Use the ? character for help and to
explore all command line options. Other commands may also be used, including those from previous
courses.
Exercise:
1.
2.
Connect to the routers in your Pod using the addresses provided by your instructor. Fill in the
required fields for Table 1. The username and password for all devices is admin. If you are
unable to connect to any of the routers, notify your instructor.
Verify the router has the initial configuration uploaded.
22/89
Verification:
1.
2.
23/89
Objective:
Identify the IP addressing and routing protocol for your pods topology.
Exercise:
Determine the IP addressing and pod configuration for your assigned pod.
1. Identify the naming convention for each router in your pod
2. Document the IP addressing and subnet masking on each interface of each router and fill in the
diagram above. This addressing will not change throughout the entire course. This diagram can
be used as reference for the labs that follow.
3. Ensure network connectivity by use of Ping, and ssh
4. Determine what routing protocol is configured on the router (note: The routing protocol will
change in labs that follow)
5. Ensure routing is operational
6. Document the network topology
Verification:
1.
2.
3.
24/89
4.
Make sure your lab topology is complete and accurate. The following labs will not provide
addressing. It is your responsibility to use your documentation from this lab for the subsequent
troubleshooting labs.
Exercise:
Ensure you can access the TFTP server and then save the configuration files to it.
1.
Your instructor will provide you with the IP address of the TFTP server for each pod.
2.
Ping the TFTP server and ensure its operational
3.
Save your Core routers configuration file using the following naming convention:
a. podXcore-student
4.
Save your Edge routers configuration file using the following naming convention
a. podXedge-student
5.
If possible access the TFTP server and ensure the file has been saved
Verification:
Make sure the files have been saved on the TFTP server.
1.
Access your TFTP server and look for the file you saved
2.
If unable to access the TFTP server directly, ask your instructor to verify the file has been
saved to the TFTP server.
25/89
Questions:
Notes
26/89
Syntax:
Commands required for this exercise are found in Table 2-1. Detail may be found in Module 2,
Troubleshooting Methodology. Each command may have additional parameters possible. Use the ?
character for help and to explore all command line options. Other commands may also be used, including
those from previous courses.
Exercise:
For this exercise each student will create a log on one of the routers in their POD.
1. Configure an event log on the R1 and R2 router using log-id 1
2. define the source as all events from the main event stream
3. define the destination to memory with a maximum size of 100
4. Create log filter so only link down and link up events are logged.
Verification:
1.
2.
3.
4.
5.
27/89
Objective:
Using Debugs examine the output and determine usability.
Exercise:
For this exercise each student will enable debug on one of the routers in their POD.
Use Debug for packet analysis. It is always a good idea to have multiple sessions open when enabling
debug.
1. Open 2 sessions to a router within your POD
2. From one of your sessions create a log file with log-id 2
3. Define the source of information that of debug-trace
4. Forward the information to session
5. Enable debug for IP packet
6. Initiate a ping between the R1 and R2 router in your pod
7. Notice from the debug output there is a lot more information than the ping
8. From the session that is not being used for debug administratively shutdown the log that is being
used for debug (note: this releases any system resources that were being used for debug). Other
methods for turning debug off are disconnecting the session that is being used for debug or using
the command no debug.
9. Disable the debug for IP packet
10. Enable debug for IP packet again but this time only enable it for icmp traffic on the interface
between R1 and R2 in your pod. What command did you use to do this?
____________________________________________________________________________
11. Turn off debug
Exercise:
For this exercise each student will create filter to log packets to memory on one of the routers in their POD.
1. Create a filter log to log to memory
2. On your R1 router Configure an IP filter to match the address of your R1 system address and your
R2 system address for ICMP protocol. The goal is to log echo requests and echo replies between
your R1 and R2 router. The default action should be forward and the action for each entry should
be forward. The same exercise can be done on your R3 router for pings between the R3 router and
R2 router in your POD.
3. clear the filter log to endues it is empty
4. Initiate a ping from your R1 router to the system address of your R2 router
Verification:
1.
2.
3.
28/89
Questions:
1. What must be created prior to activating debug on the router? _______________
_________________________________________________________________
2. Where can the debug output be sent? _________________________________
_________________________________________________________________
3. Debug outputs are turned off by what command? _________________________
_________________________________________________________________
4. To log telnet debug traffic to a file what command would you execute when
activating the debug? _______________________________________________
__________________________________________________________________
Notes
29/89
Objective:
Troubleshoot network problems in a OSPF routing environment
Syntax:
In this lab we will troubleshoot some typical OSPF problems. Several troubleshooting tools will be used.
30/89
31/89
Exercise:
In this section the students will work on their own POD.
Take a look at the OSPF configuration on pxr2.
1. Can you see any routing policy configured? What show command can you use to see if any
policies have been applied?
2. What type of route should you see in the OSPF database if the policy were functioning as
intended?
3. What is the solution to this problem?
Notes
32/89
Exercise:
Load the pxry_ospf2.cfg configuration into all routers.
Isolate the problem.
33/89
Objective:
Troubleshoot some typical problems that arise in RIP networks and when redistribution is used for RIP and
OSPF.
Section 4.1
Exercise:
When you logon to pxr2 or pxr3 you can see that not all routes from the backbone or from the other pods
can be found in the route table.
1. Whats wrong?
34/89
Section 4.2
Exercise:
The system address of pxr3 does not appear in the route-table of the other routers. Router pxr3 however
does receive RIP routes from the other routers.
1. Whats wrong?
Section 4.3
Exercise:
The link address of pxr1-pxr2 does not appear in the route-table of routers in other PODs.
1. Whats wrong?
Section 4.4
Exercise:
The system address of p2r2 and p2r4 does not appear in the route-table of the other routers.
1. Whats wrong?
Notes
35/89
Objective:
Trouble shoot ISIS related network problems
36/89
1.
37/89
Exercise:
There have been reports of asymmetrical traffic flow in the above network. Confirm the reports and
identify where this is occurring in the network.
Load configuration file pxry_isis-2.cfg.
1. Identify all link metrics and fill in the information in space provided on the topology
2. What is the cause of the asymmetrical traffic flow?
38/89
Objective:
Troubleshoot BGP network related problems.
Section 6.1
Exercise:
Load the pxry_bgp-1.cfg configuration in each router.
In the above network P4R1 is the preferred exit point for all traffic destined outside of AS 6510. All
networks and routers should be reachable from AS 6510. Notice P3R1 and P4R1 are the only routers
within AS 6510 running BGP. Both P3R1 and P4R1 are injecting default routes into the IGP.
1. Identify which routers and networks are not reachable
2. What is the result of the current configuration
3. Identify 2 possible solutions or recommendations
39/89
Section 6.2
Exercise:
Load config pxry_bgp-2.cfg
In the above network P1R1 and P3R1 are router reflector servers for AS 6500. All networks in all 3
autonomous systems should be reachable from any router in any autonomous system. So far it has been
determined that there is no connectivity between AS 6510 and AS 6520.
Note. There are a number prefixes being advertised by AS 6510 and AS 6520 which will not be reachable
but are used to populate the routing tables with a larger number of entries. All networks that are physically
on each router should be reachable.
1. Identify if there are any other connectivity problems in the above network.
2. Identify the BGP peering sessions
3. Which prefixes are being populated in the routing table?
4. What is the Flag value of the BGP routes that are not being installed? What command did you use
to find this?
5. Identify 2 possible solutions to the problem
40/89
Objective:
Troubleshoot BGP network related problems.
Exercise:
There seems to be a problem with the BGP peering sessions on pxr3.
1. Whats wrong?
2. On top of show commands and checking configurations, what extra tools can you use to
troubleshoot these problems?
41/89
Exercise:
Solve the problem in Section 6.3. All BGP peering should be up when you start section 6.4.
The routers in AS 6500 can not reach the p1r3 or p3r3 router.
1. Whats wrong?
2. How could you solve this problem
42/89
Objective:
Troubleshoot MPLS RSVP signaled LSPs.
Section 7.1
Exercise:
Load pxry_fullmesh_lsps.cfg on all routers.
In the above network a full mesh of LSPs has been setup between all routers. For this exercise each student
will work a on a single router.
1. What command can be used to view RSVP sessions?
2. View only originating RSVP sessions.
3. Enable debug for only one of the originating RSVP sessions. Use debug router rsvp lsp-id
<lspname>::<pathname> packet path detail
4. Disable Debug for the single LSP
5. View only terminating RSVP sessions
6. Enable debug for only one of the terminating RSVP session. Use debug router rsvp lsp-id
<lspname> packet path detail
7. Disable debug for the single LSP
8. View only transit RSVP sessions
9. Enable debug for only of the terminating RSVP sessions. Use debug router rsvp lsp-id <lspname>
packet path detail
10. What other options are available for limiting the debug output for RSVP packets?
43/89
Section 7.2
Before you begin this section the instructor must implement a change.
Exercise:
There are several LSPs that are down. Use the tools perform router mpls cspf command to isolate where
the problem is in the network. Refer to the RSVP Signaled LSP Problems section in the appendix of the
lab guide. Try the options that are available in the command. Each node has visibility of the entire TE
network. There is no need to go to each router in the network to see which path cspf will return to an
endpoint. The from option can be used to determine what another router will return as its path to an
endpoint
1. Where in the network is problem?
Section 7.3
Before you begin this section the instructor has to make changes.
Exercise:
There are a number of LSPs that are down in the network.
1. Determine which LSPs are down. What do all the LSPs have in common?
2. What is the failure code of the LSP Path (show router mpls lsp <lspname> path <path name>
detail)?
3. What are the LSPs relying on to get the information required to signal the LSP?
Section 7.4
Exercise:
Before this lab begins the instructor must make changes
There is a mesh of LSPs between all R2 routers with FRR enabled. All expected detours are not coming
up.
1. View the LSPs and path configuration
2. For each of the FRR enabled LSPs determine where the expected detours should be.
3. Isolate where the problem is in the network.
44/89
45/89
10. Use the tools perform router mpls cspf to <address> command each explicit hop in the list. In
this case the second one fails. The 3rd explicit hop takes a path that is not expected. This is a good
starting point to help isolate the problem
11. Open a connection to the router that is the second in the path
12. Are all expected interfaces operationally up? show router interface
13. Can you ping the adjacent interface on the link? ping <address>
14. Are all routing adjacencies up? show router ospf neighbor
15. Is MPLS enabled on the right interfaces? show router mpls interface
16. What is the problem?
Exercise:
A fix for the previous sections must be implemented before continuing with this section.
Connectivity between all sites in VPLS 4000 is down. Work in groups of 2 for this exercise.
1.
2.
46/89
Exercise:
Load pxry_m-vpls.cfg on all routers
In the above diagram VPLS 6000 is fully meshed in Metro 1. VPLS 8000 is fully meshed in Metro 2. The
2 metro networks are connected via redundant Spokes between P1R1 and P3R1 and between P2R1 and
P4R1. Management VPLS 10000 has been created for the redundant Spoke connectivity. There are reports
that some sites are not reachable. It seems there maybe packets getting dropped. The R3 routers are CE
devices in this topology. Each is configured with a router interface on the 192.168.10.x/24.
1. You have full access to all equipment
2. Verify the reports of instability
3. Identify the cause of the problem
47/89
Notes
48/89
49/89
Exercise:
Load pxry_trace.cfg on all routers.
Trace the path taken when initiating a ping from 192.168.1.2 to 192.168.3.2. Use 192.168.1.2 as the
source address when initiating a ping from P1R3. Include the return path from 192.168.3.2 to
192.168.1.2.
Notes
50/89
51/89
Exercise:
The instructor will implement a change before you begin this section.
VPRN 100, 200, 300 and 400 are configured in the same way as section 9.1. All VPRN interfaces should
be reachable from all VPRN interfaces within the same VPRN. Refer to the Layer 3 VPRN Problem
section in the appendix.
1. Isolate the problem
52/89
Exercise:
Load pxry-services1.cfg
The Pxr3 routers are CPE routers that are connected through a VPRN service. They have an interface
10.99.x.1/24 that is connected to the PxR2 router. The CPEs can not ping the gateway 10.99.x.100.
1.
2.
Notes
53/89
A.
This section covers some common troubleshooting scenarios that might happen in a 7750 SR network.
A.1.
This section describes methods/commands that can be used to troubleshoot a Layer 1 or layer 2 (i.e. IOM,
MDA and port level) problem of 7750 SRs. More details of how to verify hardware operational status are
described in Section 4.
CLI Command
show log log-id 99 subject 1/1/1
CLI Command
show chassis
show chassis environment
show chassis power-supply
IOM or SF/CPM
configuration & status
show card
show card <A/B> detail
show card <slot-number> detail
54/89
MDA
configuration & status
show mda
show mda detail
port
configuration & status
show port
show port <slot/mda/port>
show
port
<slot/mda/port[.sonet-sdhindex]>
show port <port-id> detail
show port <port-id> ppp [detail]
show lag <lag-id>
show lag <lag-id> detail
What To Check
show statistics of a port
CLI Command
show port <slot/mda/port> count
clear
port
statistics
<
sap
slot/mda/port
>
CLI Command
show port <slot/mda/port>
config port <slot/mda/port>
[no] shutdown
55/89
NOTE:
1) The SONET/SDH port must be in a shut down state to activate any type of loopback.
2) When you loop back a SONET/SDH port, make sure it is not line timing.
3) The loopback setting is never saved to the generated/saved configuration file.
Task
To activate a loopback on the
SONET/SDH port
CLI Command
config port <port-id> <enter>
config>port# sonet-sdh loopback {line|internal}
Description:
line Set the port into line loopback state.
internal Set the port into internal loopback state.
TDM ports:
You can use CLI to put a specified TDM port or channel into a loopback mode.
NOTE:
1) The corresponding port or channel must be in a shutdown state in order for the loopback mode to be
enabled. The upper level port or channel or parallel channels should not be affected by the loopback mode.
2) When you loop back a port, make sure it is not line timeing.
3) The loopback setting is never saved to the generated/saved configuration file.
Task
To activate a loopback on a
DS3 port
CLI Command
config port <port-id> <enter>
config>port#tdm
ds3
{line|internal|remote}
config>port#tdm
{line|internal|remote}
config>port#tdm
{line|internal|remote}
loopback
e3
loopback
ds1
loopback
config>port#
tdm
{line|internal|remote}
e1
loopback
56/89
A.2.
OSPF Problems
router
router
router
router
router
ospf
ospf
ospf
ospf
ospf
area
interface
neighbor
status
database
[no]
[no]
[no]
[no]
[no]
[no]
[no]
[no]
[no]
[no]
[no]
- Enable/disable debugging
- Enable/disable debugging
range
cspf
- Enable/disable debugging
interface
- Enable/disable debugging
interface
leak
- Enable/disable debugging
lsdb
- Enable/disable debugging
statedatabase (LSDB)
misc
- Enable/disable debugging
OSPF events
neighbor
- Enable/disable debugging
neighbor
nssa-range
- Enable/disable debugging
packet
- Enable/disable debugging
rtm
- Enable/disable debugging
spf
- Enable/disable debugging
virtual-neighb* - Enable/disable debugging
virtual neighbor
an NSSA range
OSPF packets
OSPF rtm
OSPF spf
an OSPF
Important Notes:
1) Before enabling debug, the user must make sure a log is created to view the debug result. The
following is an example log created to view debug results.
Note that if the log destination is session, when the session is closed, the log (log-id) will not be saved.
For example, log 3 is created to view the debug result:
SR12>config>log>log-id 3
SR12>config>log>log-id$ from debug-trace
SR12>config>log>log-id$ to session
SR12>config>log>log-id$ no exit
57/89
2) To stop the debug, use either of the following commands to stop the debug at different levels:
Command
debug router ospf no
packet
debug router no ospf
no debug
Explanation
Disable debugging for OSPF packets
Disable debugging for all OSPF messages
Disable debugging for all applications
58/89
2. MTU Mismatch
Suggested Action
To verify if the port is up:
show port
To verify that interface has been assigned a port
show router interface <int-name> detail
or
config router interface <int-name>
config>router>if# info [detail]
To bind an interface to a physical port, use the command:
config router interface <int-name>
config>router>if# port-id[:encap-val]
Note: encap-val - 0
for null
- [0..4094] for dot1q
The MTU can be set at the port level or at the IP level. To view the
MTU settings, use the following commands:
show port displays MTU at the port level.
show router ospf interface <int-name> detail
displays the IP MTU.
3. Mismatched Interface
Type
59/89
4. Mismatched subnet
mask or IP address
5. Interface not
configured in OSPF
Check the router and its neighbors interface to see if the subnet mask
or IP address matches each other. Use the command:
show router interface
To verify if the interface has been configured in OSPF, use the
commands:
show router interface to display router interfaces
show router ospf interface to display router interfaces in
OSPF
To configure an interface in OSPF, use the command:
config router ospf area <area-id> interface
<int-name>
7. Neighbor is
configured for
authentication
60/89
8. Incorrect area
Command
show router ospf spf
This command will display spf calculation statistics. The total number of
spf runs should not continually increment when the output is refreshed in
a stable network. This command can be used to determine if network
instability is caused by networks external to OSPF or internal to OSPF.
Note: In multi area environments it will be required to check the source of the summary LSAs. Once the
source of the summary LSAs has been determined run the above commands from the source of the
summary LSAs.
A.3.
ISIS Problems
router
router
router
router
router
router
router
router
router
isis
isis
isis
isis
isis
isis
isis
isis
isis
status
interface
adjacency
routes
database
statistics
spf
spf-log
summary-address
61/89
- Enable/disable debugging
adjacency
[no] cspf
- Enable/disable debugging
[no] graceful-resta* - Enable/disable debugging
graceful-restart
[no] interface
- Enable/disable debugging
interface
[no] leak
- Enable/disable debugging
[no] lsdb
- Enable/disable debugging
[no] misc
- Enable/disable debugging
[no] packet
- Enable/disable debugging
[no] rtm
- Enable/disable debugging
[no] spf
- Enable/disable debugging
for ISIS
for ISIS cspf
for ISIS
for ISIS
for
for
for
for
for
for
ISIS
ISIS
ISIS
ISIS
ISIS
ISIS
leaks
LSDB
misc
packet
RTM
SPF
Important Notes:
1) Before enabling debug, the user must make sure a log is created to view the debug result. The
following is an example log created to view debug results. Note that if the log destination is session, when
the session is closed, the log (log-id) will not be saved.
For example, log 3 is created to view the debug result:
SR12>config>log>log-id 3
SR12>config>log>log-id$ from debug-trace
SR12>config>log>log-id$ to session
SR12>config>log>log-id$ no exit
2) To stop the debug, use either of the following commands to stop the debug at different levels:
Command
debug router isis no
packet
debug router no isis
no debug
Explanation
Disable debugging for ISIS packets
Disable debugging for all ISIS messages
Disable debugging for all applications
62/89
Suggested Action
To verify if the port is up:
show port
To verify that interface has been assigned a port
show router interface <int-name> detail
or
config router interface <int-name>
config>router>if# info [detail]
To bind an interface to a physical port, use the command:
config router interface <int-name>
config>router>if# port-id[:encap-val]
Note: encap-val - 0
for null
- [0..4094] for dot1q
Use the commands below to modify MTU setting if it is wrong.
To set the MTU at the port level:
config port <port-id> ethernet mtu <value>
Note: An MTU mismatch will not stop the ISIS adjacency from
coming up but the MTU should match on point-to-point links.
2. Mismatched Interface
Type
4. Interface not
configured in ISIS
Check the router and its neighbors interface to see if the subnet mask
or IP address matches each other. Use the command:
show router interface
debug router isis adjacency
To verify if the interface has been configured in ISIS, use the
commands:
show router interface to display router interfaces
show router isis interface to display router interfaces in
ISIS
To configure an interface in ISIS, use the command:
config router isis interface <int-name>
63/89
6. Neighbor is
configured for
authentication
7. Level Capability
mismatch
If the adjacent routers
are in the same area the
interfaces and router
must be level 1 capable.
If the adjacent routers
are in different areas the
interface and router
must be level 2 capable
8. Mismatched
hello/dead interval
timers
64/89
Task
Check for network stability.
Command
show router isis statistics
This command will display ISIS statistics. The total number of spf runs
should not continually increment when the output is refreshed in a stable
network.
A.4.
BGP Problems
This section provides information on how to troubleshoot a BGP related problem. Each sub-section
describes a possible problem scenario. Examples of command usage are provided in the sub-sections.
- Enable/disable
events
- Enable/disable
Keepalive
messages
- Enable/disable
Notification
messages
- Enable/disable
65/89
[no] packets
[no] route-refresh
[no] rtm
[no] socket
[no] timers
[no] update
messages
- Enable/disable debugging
packets
- Enable/disable debugging
refresh
- Enable/disable debugging
removal and modification
the system Route Table
Manager
- Enable/disable debugging
sockets
- Enable/disable debugging
timers
- Enable/disable debugging
Update messages
Important Notes:
1) Before enabling the debug, the user must make sure a log is created to view the debug result.
2) To stop the debug, use either of the following commands to stop the debug at different level:
Command
Explanation
debug router bgp no
Disable debugging for all BGP Keepalive messages
keepalive
debug router no bgp
Disable debugging for all BGP messages
no debug
Disable debugging for all applications
3) The debug will stop if a router is rebooted for some reason.
Suggested Action
To verify if the port MTU size is configured correctly, use command: show
port <port-id>
66/89
By default the ttl for BGP packets for EBGP sessions is 1. Modify the ttl for
the BGP neighbor with the following command
config router bgp group <name> neighbor <address>
multi-hop <ttl value>
67/89
Attributes
Local Preference Attribute
CLI Commands
Local preference can be set at the global level:
config>router>bgp local-preference [0..4294967295]
or group level:
config>router>bgp>group name local-preference
[0..4294967295]
or neighbor level.
config>router>bgp>group name>neighbor ip-addr
local-preference [0..4294967295]
Note: This command enables setting the BGP local-preference attribute in
incoming routes if not specified and configures the default value for the
attribute.
This value is used if the BGP route arrives from a BGP peer without the
local-preference integer set.
The specified value can be overridden by any value set via a route policy.
This configuration parameter can be set at three levels: global level
(applies to all peers), group level (applies to all peers in peer-group) or
neighbor level (only applies to specified peer). The most specific value is
used.
as-path-ignore
MED Attribute
68/89
always-compare-med
A.5.
This section describes with an example how prefix lists (aka. access lists) are configured and used in route
policies. Show commands are also provided to troubleshooting a route policy related issue.
Overview of the route policy
Route policies allow you to configure routing according to specifically defined policies. You can create
policies and entries to allow or deny paths based on various parameters such as destination address,
protocol, packet size, and community list.
Policies can be as simple or complex as required. A simple policy can block routes for a specific location or
IP address. More complex policies can be configured using numerous policy statement entries containing
matching conditions to specify whether to accept or reject the route, control how a series of policies are
evaluated, and manipulate the characteristics associated with a route.
There are no default route policies. Each policy must be created explicitly and applied to a policy, a routing
protocol, or to the forwarding table. Policy parameters are modifiable.
Process of provisioning a basic router policy
The following diagram shows the process of how to provision a basic route policy.
69/89
The following example is focused on how prefix lists are configured and used in a route policy, and how
this route policy applied to BGP. Other parameters such as AS-path, community list and damping
parameters are disregarded.
1) create/edit route policy
SR12>config>router>policy-options#
SR12>config>router>policy-options# begin
2) create/edit prefix lists
SR12>config>router>policy-options# prefix-list
SR12>config>router>policy-options>prefix-list#
. . .
SR12>config>router>policy-options>prefix-list#
SR12>config>router>policy-options# prefix-list
SR12>config>router>policy-options>prefix-list$
SR12>config>router>policy-options>prefix-list$
. . .
SR12>config>router>policy-options>prefix-list$
Deny-routes
prefix 0.0.0.0/8 longer
exit
"permit-routes"
prefix 10.10.1.0/30 exact
prefix 10.10.2.0/24
exit
70/89
autonomous-system <as-number>
bgp
import "Service Provider-IN"
export "Service Provider-OUT"
exit
A commit will save all policy configuration in progress on a node, this include all
session that have entered begin without having exited with a commit regardless of the state of
the route-policy under configuration.
A commit terminates edit mode for all users that are currently in edit mode.
71/89
A.6.
When an AS provides transit service to other ASs and if there are non-BGP transit routers in the AS, transit
traffic might be dropped if the intermediate non-BGP routers havent learned the routes for that traffic via
IGP. In this case, the transit traffic is black-holed.
By default, Alcatel-Lucent 7750SR will not re-advertise learned iBGP routes unless there is an entry in its
routing table learned via an IGP or a static route.
If you believe that you are black holing a route, you can:
1. Check if the route is in the RIB. Use command show router bgp neighbor <ip addr>
{advertised-routes|received-routes} and show route route-table
72/89
2. Check if the route is in the FIB. Use command show router fib <slot-number> [<ipprefix/mask]> [longer]]
3. Verify the routing policies for inaccuracies to ensure that packets are not getting filtered.
- To check what policy is applied in IGP (ex. OSPF), use commands:
config router ospf
config>router>ospf# info detail
- To check if the policy is configured correctly, use command:
show router policy <policy-name>
A.7.
Important Notes:
1) Before enabling the debug, the user must make sure a log is created to view the debug result. 2) To
stop the debug, use either of the following commands to stop the debug at different level (more choices
can be found by clicking ? at any level of the CLI syntax):
73/89
Command
Explanation
debug router ldp interface <int-name>
Disables debugging for specific LDP packets
no packet
debug router ldp no interface <intDisables debugging for LDP interface
name>
no debug
Disables debugging for all applications
3) The debug will stop if a router is rebooted for some reason.
Using show commands to check LDP information
Command
show router ldp bindings
show router ldp bindings active
show
show
show
show
show
show
A.8.
router
router
router
router
router
router
ldp
ldp
ldp
ldp
ldp
ldp
discovery
interface
parameters
peer
session
status
Explanation
To display LDP bindings information
To display LDP active bindings. An active binding must exist for a
prefix in order for an LSP to be active
To display LDP discovery information
To display LDP interface information
To display LDP configured and operation parameters
To display LDP targeted peer information
To display LDP session information
To display LDP operational information
router
router
router
router
router
router
router
rsvp
rsvp
rsvp
rsvp
mpls
mpls
mpls
status
interface
session
statistics
lsp
lsp path
lsp active path
74/89
<lsp-name>
<sender-address>
<endpoint-address>
<tunnel-id>
<lsp-id>
<ip-int-name>
:
:
:
:
:
:
[no] event
[no] packet
- Enable/disable
packets
[no] patherr
- Enable/disable
packets
[no] pathtear
- Enable/disable
packets
[no] resv
- Enable/disable
packets
[no] resverr
- Enable/disable
packets
[no] resvtear
- Enable/disable
packets
SR12# debug router rsvp event
- event
- no event
[no] bundle
[no] error
[no] hello
[no]
[no]
[no]
[no]
psb
rre
rsb
tcsb
- Enable/disable
messages
- Enable/disable
- Enable/disable
messages
- Enable/disable
- Enable/disable
- Enable/disable
- Enable/disable
for
for
for
for
RSVP
RSVP
RSVP
RSVP
psb
rre
rsb
tcsb
Important Notes:
1) Before enabling debug, the user must make sure a log is created to view the debug result. The
following is an example log created to view debug results. Note that if the log destination is session, when
the session is closed, the log (log-id) will not be saved.
For example, log 3 is created to view the debug result:
SR12>config>log>log-id 3
SR12>config>log>log-id$ from debug-trace
SR12>config>log>log-id$ to session
SR12>config>log>log-id$ no exit
75/89
2) To stop the debug, use either of the following commands to stop the debug at different levels:
Command
debug router rsvp no
packet
debug router no rsvp
no debug
Explanation
Disable debugging for rsvp packets
Disable debugging for all rsvp messages
Disable debugging for all applications
76/89
Explanation
Syntax :tools perform router mpls cspf
to <ip-addr> [from <ip-addr>] [bandwidth <bandwidth>]
[include-bitmap<bitmap>] [exclude-bitmap <bitmap>] [hoplimit <limit>] [exclude-address <excl-addr> [<excladdr>...(upto 8 max)]]
<ip-addr>
: a.b.c.d
<bandwidth>
: [1..100000] in Mbps
<bitmap>
: [0..4294967295] - accepted in decimal,
hex(0x) or binary(0b)
<limit>
: [1..255]
<excl-addr>
: a.b.c.d (system or egress ip-address)
Context : tools>perform>
Description: This command does a manual CSPF calculation
based on the constraints provided in the command string. This
tool is very useful for troubleshooting LSPs that are not in the
up state or are not using the optimal path. This command can
only be used if Traffic Engineering is enabled in the IGP as It
relies on the traffic engineering database. The output of the
command is strictly informational and has no impact on any
LSPs. If the CSPF calculation fails it indicates that there is no
path in the TE database to reach the endpoint. The Traffic
Engineering database will not be fully populated if TE is not
enabled on all nodes in the network and if interfaces are not
MPLS or RSVP enabled. This tools command can be used
similar to ping to isolate the source of the problem. For
example, if the CSPF calculation fails to the desired endpoint
the next node in the path can be specified as the endpoint. This
can be continued until the failing node is isolated.
Parameters:
To Address- Endpoint IP address to run CSPF calculation to.
From Address- Starting point IP address for CSPF calculation.
This can be used to determine what path another node in the
network will return based on the constraints in the command
string
Bandwidth- 1..100000 in Mbps. This is used to add bandwidth
as a constraint when performing the CSPF calculation.
Include-bitmap- 0..4294967295 accepted in decimal, hex(0x) or
binary (0b). Only interfaces belonging to the specified
administrative group can be used as part of the CSPF calculation
Exlude-bitmap-0..4294967295 accepted in decimal, hex(0x) or
binary (0b). Only interfaces NOT belonging to the specified
administrative group can be used as part of the CSPF calculation
Hop-Limit-[1..255]. This is used to add a hop limit as a
constraint when performing the CSPF calculation
Exclude-address- IP address. Up to 8 addresses can be
specified. The address specified must be an egress interface
address for the node. By default the CSPF calculation will
follow the IGP to endpoint for the calculation. By excluding
egress addresses alternate paths can be calculated.
77/89
Suggested Action
Verify that the following are all true.
mpls no shut
rsvp no shut
lsp no shut
lsp path no shut
lsp has a destination address assigned to it.
lsp has primary/secondary path assigned to it
For a non-cspf LSP, RTM is not empty.
In addition, type cli command show router rsvp session status down on
all the LSRs along the LSP path to check if a PATH message reaches all the
LSRs or not.
noRouteToDestination
For a non cspf empty path LSP with Dest Addr not valid/no valid route to
destination.
Verify that MPLS is enabled on all the LSRs in the network.
Verify that the to address is in the RTM. (Reachable by IGP)
For a cspf LSP with invalid strict/loose path.
Verify that all the routes/hops in the strict/loose path are valid and
are in correct sequence according to the network topology.
If a cspf LSP is trying to reserve a BW that none of the end-to-end paths in
the network can fulfill.
Check if the requested BW is too big for the network to handle or
the resources has already being used by other LSPs. Use tools
perform router mpls cspf to verify that there is a cspf path that
can fulfill the BW constraint.
If a cspf LSP cant find an end-to-end path in the network that matches the
color constraint.
Check if link color is assigned correctly for all the routes in the
network. Use tools perform router mpls cspf to verify that there
is a cspf path that can fulfill the color constraint.
For a cspf LSP, downstream routers have ospf/isis te off or opaque LSA
disabled.
Enable te /opaque LSA on all the LSRs that the LSP traverses.
78/89
noCspfRouteOwner
For a cspf LSP with Dest Addr not valid/ no valid route to destination.
Verify that MPLS is enabled on all the LSRs in the network.
Verify that the Dest Addr is in the IGP database. (Reachable by
IGP)
badNode
looseHopsInFRRLsp
routingLoop
admissionControlError
79/89
A.9.
: [1..17407]
[no] event-type
Important Notes:
1) Before enabling debug, the user must make sure a log is created to view the debug result. The
following is an example log created to view debug results. Note that if the log destination is session, when
the session is closed, the log (log-id) will not be saved.
For example, log 3 is created to view the debug result:
SR12>config>log>log-id 3
SR12>config>log>log-id$ from debug-trace
SR12>config>log>log-id$ to session
SR12>config>log>log-id$ no exit
2) To stop the debug, use either of the following commands to stop the debug at different levels:
Command
debug service no sdp
no debug
Explanation
Disable debugging for sdp events
Disable debugging for all applications
80/89
Suggested Action
Verify that the following are all true.
LDP is no shut on both nodes
show router ldp status
Endpoint address is in the routing table
show router route-table <prefix>
There is an SDP configured in both directions
show service sdp far-end <ip-address>
show service sdp-using <ip-address>
TransportTunnDown
KAFailure
If message-length is configured for SDP keep Alive verify the SDP MTU
with the following oam command:
oam sdp-mtu
- sdp-mtu <orig-sdp-id> size-inc <start-octets> <end-octets> [step
<step-size>] [timeout <timeout>] [interval <interval>]
<orig-sdp-id>
: [1..17407]
<octets>
: start-octets [40..9198] end-octets [40..9198]
<step-size>
: [1..512]
<timeout>
: [1..10] seconds
<interval>
: [1..10] seconds
81/89
service
service
service
service
service
service
id
id
id
id
id
id
<id>
<id>
<id>
<id>
<id>
<id>
base
sdp <sdp-id>
sap <sap-id>
fdb (VPLS only)
stp (VPLS only)
all
: [1..2147483647]
[no] dhcp
[no] event-type
[no] sap
[no] sdp
[no] stp
Important Notes:
1) Before enabling debug, the user must make sure a log is created to view the debug result. The
following is an example log created to view debug results. Note that if the log destination is session, when
the session is closed, the log (log-id) will not be saved.
For example, log 3 is created to view the debug result:
SR12>config>log>log-id 3
SR12>config>log>log-id$ from debug-trace
SR12>config>log>log-id$ to session
SR12>config>log>log-id$ no exit
82/89
2) To stop the debug, use either of the following commands to stop the debug at different levels:
Command
debug service no service
no debug
Explanation
Disable debugging for service events
Disable debugging for all applications
NoIngVCLabel
NoEgrVCLabel
(if both flags are present)
SdpOperDown
Suggested Action
Verify that the following are all true.
The service is administratively enabled
show service <id> base
Verify the following is True
The status of the SDP is operational. If not go to the Service
Distribution Path (SDP) Problems Section
show service sdp <sdp-id>
This indicates the SDP is down.
Go to the Service Distribution Path (SDP) Problems Section
83/89
SdpBindAdminDown
NoEgrVCLabel
(if this is the only flag
present)
PathMTUTooSmal
ServiceMTUMismatch
Suggested Action
This indicates that the port for the logical SAP is in the down state.
Verify the port status with the show port <port-id> command
PortMTUTooSmall
This indicates that the port MTU is smaller then the Service MTU. The
SAP MTU must be equal to or greater then the Service MTU
Check the port MTU the show port <port-id> command.
Adjust the port MTU.
84/89
: [1..2147483647]
Important Notes:
1) Before enabling debug, the user must make sure a log is created to view the debug result. The
following is an example log created to view debug results. Note that if the log destination is session, when
the session is closed, the log (log-id) will not be saved.
85/89
SR12>config>log>log-id 3
SR12>config>log>log-id$ from debug-trace
SR12>config>log>log-id$ to session
SR12>config>log>log-id$ no exit
2) To stop the debug, use either of the following commands to stop the debug at different levels:
Command
no debug
Explanation
Disable debugging for all applications
Explanation
A PE router is on the Service Provider Edge. Each CE device is
attached, via some sort of attachment circuit, toone or more
Provider Edge (PE) routers.
P Router
MP-BPG
Route-Distinguisher
Route-Target
Transport Tunnel
Used to transport the data for the VPRN service between PEs.
Can be delivered by RSVP signaled LSPs, LDP signaled LSPs
or GRE. Auto-bind ldp and Auto-bind GRE are options.
Static
RIP
OSPF
BGP
86/89
A.11.3. Route Selection Process for VPRNS when BGP is being used as the PECE routing protocol
IP-VPNs MSE direct route comparison of BGP and MP-BGP learned routes provides the ability
to compare a route received from a CE peer (inside the VPRN context) to the same route prefix
received as a BGP VPN-IPv4 update from a PE peer. This is required when a CE router is dual
homed and advertises the same customer route prefix to two (or more) PE peers. Each PE router
needs to choose one of the prefixes, which was done previously, based on the Route Table
Preference as opposed to comparing the BGP attributes. The BGP route decision process takes
into account the attribute values of the two routes according following table to decide which is
chosen to be the best route to install in the VRF table:
1. Routes are not considered if they are unreachable.
2. Routes of the protocol with the lowest preference value are selected.
3. BGP routes with higher local preference have preference.
4. BGP routes with the shorter AS path have preference.
(This is checked independent of the as-path-ignore parameter.)
5. BGP routes with the lowest MED metric have preference.
(If MED values are present, they are checked independent of the always-compare-med
parameter.)
6. BGP CE-PE learned routes are preferred over MP-BGP learned routes.
Possible Problem
1. Service Status
Suggested Action
Verify the service is administratively enabled
show service id <id> base
To verify that interface has been assigned a port
2. MP-BGP session
status between PE
routers
87/89
3. Route-Distinguisher
is not configured
Import targets on the local PE must match the export targets on remote
PEs.
Verify that the expected routes from remote PEs are in the global BGP
routing table (BGP Rib-In). If there are no VPRNs with an import
target on the PE that matches the target in a received route the PE
router will silently drop the advertised route.
show router bgp routes <prefix>
If the expected routes are not present verify that the import target
configured within the VPRN matches the export target on the remote
PE.
Another command to verify the number of VPN routes learned from
remote PE is.
show router bgp summary
Verify the route-targets that are being advertised by the local node.
show router bgp routes <prefix> hunt
Check the community of the output from the above command to
confirm the export target used.
Note: This command will display the RIB-IN and RIB-OUT for the
specified prefix.
Verify the status of the local interface
Show router <service-id> interface
A transport tunnel to the VPN routes next hop must be active before
the route will get installed into the VRF.
A spoke-sdp , auto-bind ldp or auto-bind gre must be configured.
show service id <id> base
From the output confirm that a spoke-sdp is configured or auto-bind is
configured.
If spoke-sdps are used for transport use the following command to
verify the status of the sdp
show service sdp <sdp-id>
If the sdp is not operational go to the Service Distribution Path (SDP)
Problemssection.
Note: Inner Labels are signaled by MP-BGP for VPRNs and signaling
is not required for SDPs being used for a VPRN service
If auto-bind LDP is configured confirm that there is an active binding
for the VPN next-hop address
show router ldp bindings prefix <vpn nexthop/32> active
88/89
http:/ /www.alcatel-lucent.com/src
89/89