<Course Title>

Monitoring and Troubleshooting

LY
N
O
SE
U
AL
N
R
TE
IN
Monitoring and Troubleshooting

LY
N
O
SE
U
AL

The Situation
N

You might have found yourself in a similar situation to the one highlighted on the slide. In these types
of situations, you may ask yourself a number of questions such as: What is broken?, What has
R

changed recently?, Is there really an issue or is it working as designed?, and Where do I begin?
These are all relevant questions and there are a number of correct ways to approach these types of
TE

situations. We discuss a basic troubleshooting method throughout this section that can be applied to
situations like the one illustrated on the slide.
IN

2 www.juniper.net
 Monitoring and Troubleshooting

LY
N
O
SE
U
AL

A Basic Method for Troubleshooting

N

When beginning your troubleshooting, it is important to take a structured approach. In this material,
we will be using the troubleshooting method outlined on the slide. Each step in this troubleshooting
R

method is highlighted in detail on subsequent slides in this material.

TE
IN

www.juniper.net 3
Monitoring and Troubleshooting

LY
N
O
SE
U
AL

Knowing Your Environment

N

To effectively troubleshoot a network you must be familiar with the network and know what is normal
for your environment. There are many tools that allow you to get familiar with your environment. You
R

can use tools, such as sFlow and SNMP, to monitor your network environment and even establish a
baseline for that network environment. Note that we discuss sFlow and SNMP in further detail in a
TE

subsequent section in this material.

In addition to the physical components in your network, you should also have a detailed
understanding of the logical components and protocols in your environment. Without a detailed
understanding your entire environment, troubleshooting issues can be a significant challenge and
IN

you may actually end up causing more problems by troubleshooting something that is operating as
expected.

4 www.juniper.net
 Monitoring and Troubleshooting

LY
N
O
SE
U
AL

Gathering Information
N

Before attempting to fix a problem that may or may not exist, you should gather as much information
as possible. When gathering information it is helpful to get answers to key questions relevant to the
R

situation. The answers to these key questions should provide detailed information about the
symptoms related to the issue.
TE

While talking to end users can provide some valuable information, it is also important to understand
what other resources and tools you have available and use those additional resources to help gather
relevant information. Ultimately it is the information gathered that will lead you to the problem and
help you identify a solution. Typically the sooner you gather the relevant information for a given issue,
IN

the sooner you will be able to solve that issue and be able to get back to your video game or favorite
YouTube video.

www.juniper.net 5
Monitoring and Troubleshooting

LY
N
O
SE
U
AL

Understanding Symptoms and Layers

N

Recall that EX Series switches maintain a strict separation between the control plane and the data
plane. When you characterize a problem, certain types of symptoms indicate the control plane as the
R

most probable cause, whereas other symptoms indicate that the root cause ultimately lies in the
data plane. In an established operating environment, it is extremely rare to find a fault in both planes
TE

simultaneously because of the different role that each plays.

The control plane is responsible for installing routes and media access control (MAC) address entries
into the forwarding table. This function relies on configuration, protocols, connection to peers and so
on. The most common symptom of a control plane problem is incorrect or missing forwarding paths
IN

at Layer 2 and Layer 3. When in doubt, it is generally beneficial to determine whether the control
plane is functioning properly before moving on to the data plane.
The data plane uses the forwarding path information provided by the control plane to perform packet
forwarding. The most common symptoms of a data plane issue are physical errors, intermittent
connectivity and dropped packets. Problems in the data plane can result from faulty hardware or
configuration-based issues such as firewall filters, policers, and so forth. Note that intermittent
issues and bottlenecks almost always trace back to the data plane.
Understanding how symptoms relate to the various layers in a modeled structure, such as the Open
Systems Interconnection (OSI) and TCP models, and the control and data planes on EX Series
switches can speed-up your troubleshooting efforts in many cases.

6 www.juniper.net
 Monitoring and Troubleshooting

LY
N
O
SE
U
AL

Hardware Troubleshooting Flowchart

N

The artistic aspect of troubleshooting and the various ways in which a modern communications
device might malfunction combine to make a definitive set of troubleshooting steps and procedures
R

an unobtainable goal. The purpose of the hardware troubleshooting flowchart shown on the slide is
simply to provide a set of high-level steps designed to get you started with hardware fault analysis.
TE

Note that reasonable people might disagree on the exact ordering of the steps or the particular
command-line interface (CLI) commands used to help isolate a hardware failure (for example, some
might prefer the extensive option to the show interfaces command, whereas the sample
chart calls out the terse and detail options).
IN

www.juniper.net 7
Monitoring and Troubleshooting

LY
N
O
SE
U
AL

Software Troubleshooting Flowchart

N

The purpose of the software troubleshooting flowchart shown on the slide is simply to provide a set
of high-level steps designed to get you started on the path of software-related troubleshooting. Note
R

that as with the hardware flowchart, reasonable people might disagree on the exact ordering of the
steps or on the particulars of the CLI commands used to help isolate a software failure. Note that it is
TE

sometimes necessary to execute the same command multiple times over a brief period of time to
see patterns or indications of problems.
In some situations, configuration errors can appear as a software issue. The commands used to
investigate configuration errors depends on the reported symptoms. As an example, the commands
IN

you use to troubleshoot symptoms related to 802.1X will not be the same commands you use to
troubleshoot symptoms related to MSTP. Because of the number of possible scenarios that could involve
configuration errors, we do not provide the related CLI commands.
Some software issues may be related to a malfunctioning process. The slide also outlines some of
the key Junos processes used on EX Series switches. These processes are responsible for individual
functions including chassis and interface control as well as operations related to routing and
switching. These process can be restarted using the CLI, but this should only be used as a last
resort. Restarting a process might resolve an issue, but it makes determining the root cause very
difficult. Restarting a process can also have a cascading and adverse effect on other process that
may impact the switch or even the network as a whole.

8 www.juniper.net
 Monitoring and Troubleshooting

LY
N
O
SE
U
AL

System Logging and Traceoptions

N

You can use the system logging and traceoptions features on EX Series switches to gather
useful information when troubleshooting hardware and software issues. This slide provides a
R

basic review of each of these features along with configuration examples.

System logging (syslog) uses a UNIX syslog-style mechanism to record system-wide, high-level
TE

operations and events, such as interfaces going up or down or users logging in to or out of the
device. The Junos OS places the resulting log messages in files stored in the /var/log directory
or can send the log messages to a remote server. The primary syslog file, which is included in
all factory-default configurations, is the /var/log/messages file.
IN

When using traceoptions, you create a trace file that is used to store decoded protocol
information received or sent by the Routing Engine (RE). As shown in the configuration example
on the slide, you identify the types of messages you want logged to the trace file using
traceoption flags. The Junos OS sends the tracing results to a specified file stored in the /var/log
directory or to a remote syslog server. You can enable traceoptions at various hierarchies to
capture detailed information pertaining to a specific protocol or feature.

www.juniper.net 9
Monitoring and Troubleshooting

LY
N
O
SE
U
AL

Routing Engine Information

N

The overall health of a networking device often has a lot to do with the stability of its control plane
and its dedicated resources. On EX Series switches, the RE is responsible for all control plane
R

functions. The RE has dedicated memory and a CPU to support the various control plane functions.
As with any resource, the REs memory and CPU cycles may become consumed beyond a sustainable
TE

point.
If the REs memory and CPU become overwhelmed, the stability of the system, and potentially the
entire network, may be in jeopardy. Although this is not typical, high memory and CPU utilization can
impact the performance and overall operations of the running processes and can potentially cause
IN

those processes to fail. Note that in environments that are well designed and implemented correctly,
RE CPU and memory utilization are typically maintained at a sustainable level. The utilization levels
vary and are dependant on the device’s configuration and processing load.

10 www.juniper.net
 Monitoring and Troubleshooting

LY
N
O
SE
U
AL

Process Failures
N

The software used on today’s networking devices can be exceedingly complex. As a result, equally
complex bugs that result from unforeseen circumstances can result in a fatal error within a software
R

process. Most of these software faults relate to illegal memory operations caused by the process
attempting to read or write data from a memory area outside the boundaries allocated for that
TE

process. In some cases, faulty hardware, such as failing memory, can cause stack or register
corruption that leads to a fatal error in a software process. Core and log file analysis are used to
determine whether hardware errors have led to a software panic. A core file represents the set of
memory locations and stack data that was in place at the time of the fault. The core file that is
generated is stored in the /var/tmp file system directory and is named in the
IN

process-name.core-tarball.core-number.tgz format. Secondary core files might be

generated in the /var/crash/kernel directory as well depending on what process was involved
in the core. You can easily verify if your device has core files stored on it by executing the show
system core-dumps command from operational mode.
If your system has generated a core file, you can contact the Juniper Networks Technical Assistance
Center (JTAC) support team to assist with decoding the core file and to identify the root cause.

www.juniper.net 11
Monitoring and Troubleshooting

LY
N
O
SE
U
AL

Creating an Action Plan

N

It is important to outline possible causes that correlate with the known symptoms identified in the
previous step. Many common network issues fall into the following three categories:
R

• Physical: Physical issues can include, but are not limited to, faulty hardware as well as
faulty cabling or fiber.
TE

• Software: Software issues are often referred to as bugs and are problems in the
software coding.
• Configuration: Configuration issues could be as simple as a missed virtual LAN (VLAN)
IN

tag or more complicated like a spanning tree setting that affects the entire network.
After narrowing down the problem, you can create a plan to prove or disprove the possible cause.
Each plan should include the steps to prove or disprove the possible cause and how success is
defined. It is also a good idea to have a contingency plan just in case the changes associated with a
test make the situation worse. A good action plan allows you to revert back to the previous state in a
short amount of time.

12 www.juniper.net
 Monitoring and Troubleshooting

LY
N
O
SE
U
AL

Testing Possible Solutions

N

The final step in this basic troubleshooting method is to execute the proposed test that you outlined
in the previous step. If a given test does not resolve the issue, it is recommended that you remove
R

any changes associated with that test and move on to the next test from the original starting point.
This process will help keep your configuration clean and may help you avoid any unexpected issues
TE

later on.
If none of your tests resolve the issue, you should return to step one and gather additional
information. You might need to go through this entire troubleshooting process multiple times before
identifying the resolution to the problem. If you have exhausted all of your local resources, you may
IN

consider working with JTAC. We discuss some key considerations when working with JTAC on the next
slides.

www.juniper.net 13
Monitoring and Troubleshooting

LY
N
O
SE
U
AL

Working with JTAC: Part 1

N

In some cases, you may need help identifying and resolving issues. You can open a support case
with JTAC to get help from Juniper Networks’ support engineers. For non critical issues it is
R

recommended that you open the case using the web portal located at www.juniper.net/cm.
Alternatively, for critical issues it is recommended you call JTAC directly to open a new case.
TE

You should provide as much detail as you can about the issue and what steps have already been
carried out. It is also a very good time to attach any relevant outputs from the affected devices. By
providing as much detail about the issue and supplying the relevant outputs up front, JTAC should
have a better understanding of the issue initially and be able to provide a resolution more quickly.
IN

14 www.juniper.net
 Monitoring and Troubleshooting

LY
N
O
SE
U
AL

Working with JTAC: Part 2

N

When working with JTAC, you can avoid unnecessary delay by providing as much relevant information
as possible when you open a support case. In addition to the outputs and details you feel are
R

relevant to the problem, there are some standard outputs that JTAC typically request. The commands
used to capture the standard outputs requested by JTAC are outlined on the slide.
TE

JTAC may request that you gather the same output several times to illustrate historical values, like
incrementing traffic statistics, dropped packet counters, and incrementing errors. To help illustrate
the time between each instance of a specific command, you can use the set cli timestamp
command in operational mode to generate a timestamp at the beginning of each CLI output. A
IN

sample capture showing the generated timestamp is illustrated on the slide.

www.juniper.net 15
Monitoring and Troubleshooting

LY
N
O
SE
U
AL

Troubleshooting Tools
N

The Junos OS offers several tools that can be used when troubleshooting. We highlighted various CLI
commands that can be used to monitor system operations as well as the system logging and
R

traceoptions features in the preceding section. We cover the remaining tools listed on the slide in
this section.
TE
IN

16 www.juniper.net
 Monitoring and Troubleshooting

LY
N
O
SE
U
AL

SNMP
N

The Junos OS supports Simple Network Management Protocol (SNMP) which can be used with a
wide variety of network management systems (NMSs) to collect information and establish a
R

meaningful baseline.
SNMP defines a set of standards for network management including a protocol, a database
TE

structure specification, and a set of data objects that facilitate communications between an SNMP
agent running on a managed device (like an EX Series switch) and an NMS. SNMP can be used to
monitor various parameters such as CPU utilization, memory utilization, CPU temperature, interface
throughput, and so on. SNMP gathers this system information by sending a GetRequest to the
IN

agent device. The agent device can send a variety of different SNMP trap message to the NMS
indicating that there has been an unexpected event on the local system.
You can also configure the local system to monitor the health of key components. When a threshold
is exceeded, the system reports this information using trap messages to the NMS. When configuring
health-monitor on a device, you can define the interval that the system checks the current
values against thresholds. These thresholds can also be explicitly defined or you can use the default
values. Additional information regarding the health-monitor feature can be found in KB16450,
by entering this number in the KB field at http://kb.juniper.net.

www.juniper.net 17
Monitoring and Troubleshooting

LY
N
O
SE
U
AL

sFlow Monitoring: Part 1

N

The sFlow (RFC 3176) technology is designed for monitoring high-speed switched or routed networks
and provides visibility into the types of traffic in those networks. sFlow is a statistical sampling-based
R

network monitoring technology that samples network packets and sends those samples to a
monitoring station, known as a collector. Once the samples are received by the collector, the network
TE

administrator can determine network behaviors, traffic patterns, and detect anomalies in traffic
flows.
The sFlow agent is typically embedded in a switch’s application-specific integrated circuit (ASIC)
hardware, where it collects different samples at regular intervals. The datagrams are sent at regular
IN

intervals to the sFlow collector whose address is configured as an IP address and UDP port pair. The
collector reads the datagram, estimates the traffic pattern, and generates a traffic report. The sFlow
technology provides Layer 2-7 visibility.
The sFlow agent does sampling in two phases, packet flow sampling, which consists of statistical
data gathered from individual flows, and counter sampling, which involves the periodic polling of
counters to gather interface data. Flow samples are then bundled into a datagram and the
datagrams are sent out to the collector using the default UDP port 6343. Counter sampling is done
at regular intervals to provide details about the interfaces, backplane, and so on. Communication
between the agent and the collector is bidirectional; the agent sends datagrams to the collector,
while the collector might configure some SNMP variables on the sFlow agent or might read some of
the SNMP Management Information Base (MIB) using UDP packets, as they work efficiently in times
of congestion.
Continued on next page.

18 www.juniper.net
 Monitoring and Troubleshooting
sFlow Monitoring: Part 1 (contd.)
Up to four collectors can be configured on each EX Series switch, and each collector can receive the
same set of sFlow data record samples. As mentioned earlier, the sFlow data record samples are
sent as UDP packets. You can change the UDP port being used by modifying the configuration. The
polling interval is also configurable and is defined as the interval between each port statistic polling
update message, which can range from 0 to 3600 seconds. The sample rate means one out of every
n packets in the traffic stream will be sampled. The range of sample rate is from 100 to 1 million.
Only network Gigabit Ethernet or 10-Gigabit Ethernet ports able to accommodate routed traffic can
be used for exporting sFlow data records from an EX Series switch towards the collector. Currently
EX Series switches cannot export sFlow data records out the management Ethernet interface (me0)
or virtual management interface (vme0).

LY
N
O
SE
U
AL
N
R
TE
IN

www.juniper.net 19
Monitoring and Troubleshooting

LY
N
O
SE
U
AL

sFlow Monitoring: Part 2

N

This slide provides an example scenario for configuring sFlow monitoring. The objective is to sample
traffic entering switch-1’s ge-0/0/1 interface and export the sFlow data records to the collector,
R

which has the IP address 10.10.10.254. The default configuration values have been used for the
polling interval, sample rate, and UDP port in this configuration example. Although not illustrated,
TE

switch-1 requires routing information for the 10.10.10.254 destination which in this case would be
reachable through ge-0/0/10.
IN

20 www.juniper.net
 Monitoring and Troubleshooting

LY
N
O
SE
U
AL

Port Mirroring: Part 1

N

The port mirroring feature allows you to analyze traffic passing through an EX Series switch. You can
use port mirroring to monitor traffic for such purposes as network usage policy enforcement and to
R

identify the source of problems on your network by locating abnormal or heavy bandwidth usage
from particular stations or applications. Port mirroring is needed for traffic analysis on a switch
TE

because a switch, unlike a hub, does not broadcast packets to every port on the device. The switch
mirrors and sends packets only out designated ports that you define. The mirrored packets are sent
to and analyzed on a connected device using a protocol analyzer application. The protocol analyzer
application can run either on a computer connected to the analyzer output interface or on a remote
monitoring station. You can configure port mirroring to send copies of unicast traffic to either a local
IN

analyzer port or an analyzer VLAN. A configuration example is provided on a subsequent slide.

We recommend that you disable port mirroring when you are finished troubleshooting and that you
define specific interfaces to mirror the traffic on instead of using the all keyword option. You can
also limit the amount of mirrored traffic by using statistical sampling, setting a ratio to select a
statistical sample, or using a firewall filter to mirror only packets matching certain criteria. Mirroring
only the necessary packets reduces any potential performance impact.
Continued on next page.

www.juniper.net 21
Monitoring and Troubleshooting
Port Mirroring (contd.)
You can use port mirroring on a switch to mirror any of the following:
• Packets entering or exiting a port: You can mirror the packets in any combination (on up
to 256 ports). For example, you can send copies of the packets entering some ports
and the packets exiting other ports to the same local analyzer port or analyzer VLAN.
• Packets entering a VLAN on an EX2200, EX3200, EX4200, or EX4500 switch: You can
mirror the packets entering a VLAN on these switches to either a local analyzer port or
to an analyzer VLAN. (On EX3200, EX4200, and EX4500 switches, you can configure
multiple VLANs (up to 256 VLANs), including a VLAN range and Private VLANs (PVLANs),
as ingress input to an analyzer.)
• Packets exiting a VLAN on an EX8200 switch: You can mirror the packets exiting a VLAN
on an EX8200 switch to either a local analyzer port or to an analyzer VLAN. You can

LY
configure multiple VLANs (up to 256 VLANs), including a VLAN range and PVLANs, as
egress input to an analyzer.

N
O
SE
U
AL
N
R
TE
IN

22 www.juniper.net
 Monitoring and Troubleshooting

LY
N
O
SE
U
AL

Port Mirroring: Part 2

N

This slide provides an example scenario for configuring port mirroring. The objective is to mirror all
incoming packets from both employee A and employee B. You begin by creating an analyzer profile,
R

in the example the profile name is employee-monitor. Next, you define the interfaces to be
monitored and add them as the input source for the analyzer profile. Note that the ingress keyword is
TE

used to indicate that incoming packets are to be mirrored. Finally, the output interface needs to be
specified. This interface is where the mirrored packets will be sent out to the packet analyzing
device.
Note that this is a basic configuration example and you can find additional examples of port
IN

mirroring in more complex situation by reviewing the technical documentation for your particular
version and device.

www.juniper.net 23
Monitoring and Troubleshooting

LY
N
O
SE
U
AL

Topology, Symptoms, and Relevant Information

N

This slide outlines the network topology, reported symptoms, and other helpful information. In this
case study, end users have reported reachability issues to a remote file server. One of the end users,
R

Employee A, is able to communicate with the gateway router, but not the remote router or file server.
It has been verified that R1 and R2 both have the required routes in place to the remote subnets but
TE

they cannot communicate with destination devices in those remote subnets or each other for that
matter. The switch, connecting R1 and R2, has been configured with port mirroring to capture all
incoming packets on ge-0/0/6 and ge-0/0/10 and to send those packets out ge-0/0/15 to the
analyzer (Laptop running packet capturing software).
IN

24 www.juniper.net
 Monitoring and Troubleshooting

LY
N
O
SE
U
AL

Interface Status
N

Start by verifying that the interfaces are up and functioning. This can easily be verified using the
show interfaces terse command. As illustrated on the slide the relevant interfaces are
R

Admin up and Link up. The interfaces are also configured for ethernet-switching which
indicates that it is operating at layer 2.
TE
IN

www.juniper.net 25
Monitoring and Troubleshooting

LY
N
O
SE
U
AL

Mirrored Packets
N

Next, a continuous ping is started on the Employee A device with the file server as the destination.
The slide displays the traffic captured and indicates that:
R

• The packets are all ICMP Echo requests sourced from 10.10.10.2 (Employee A device)
and destined to 12.12.12.2 (remote file server). Note that there is no return traffic.
TE

• All packets are being sent from R1 with a VLAN tag value of 105.
IN

26 www.juniper.net
 Monitoring and Troubleshooting

LY
N
O
SE
U
AL

Verify VLAN Assignments and Port Mode

N

Using the commands and generated output illustrated on the slide, you can see that ge-0/0/6.0 and
ge-0/0/10.0 are both associated with VLAN v105 which is assigned a VLAN tag of 105. You can also
R

tell from this output that both of these interfaces are active because of the inclusion of the asterisk
(*) next to both interfaces in the output from the show vlans command. One additional piece of
TE

information that may not be so obvious is that only ge-0/0/10.0 is a tagged interface. This value is
characteristic of interfaces configured for access mode (the default port mode). To allow ge-0/0/6.0
to receive tagged frames, it must be configured for trunk mode. We verify if changing the port mode
on ge-0/0/6.0 to trunk mode resolves the issue on the next slide.
IN

www.juniper.net 27
Monitoring and Troubleshooting

LY
N
O
SE
U
AL

Test Possible solutions

N

The next step is to test the possible solution. The slide shows the port is now configured for trunk
mode. The packet capture from the analyzer verifies that traffic from the Employee A device is now
R

reaching the file server. The capture displays packets being sourced from the employee as well as
return traffic which is sourced from the server.
TE
IN

28 www.juniper.net
 Monitoring and Troubleshooting

LY
N
O
SE
U
AL

Topology, Symptoms, and Relevant Information

N

This slide outlines the network topology, reported symptoms, and other helpful information. In this
case study, users connected to AS-1 and AS-2 have been complaining for some time now about
R

latency and congestion when accessing resources through the network. You and your team have
recently implemented MSTP to load balance traffic from the various user groups (VLANs). The recent
TE

change should distribute the traffic from the various user groups between two separate paths in the
network. One path should use DS-1 as the root bridge while the other path should use DS-2 as the
root bridge. The end users have observed no difference in performance since the configuration was
changed and continue to complain about congestion. You have been asked to investigate the
situation and ensure load balancing is in effect.
IN

www.juniper.net 29
Monitoring and Troubleshooting

LY
N
O
SE
U
AL

Verify Root Bridge Elections

N

One approach when troubleshooting this type of an issue would be to start from a point close to the
end users and work outward from that point. In this example we do just that and start by verifying
R

which devices are being elected as the root bridge for the different MSTI instances from AS-1’s
perspective. As shown in the sample output on the slide that is taken from AS-1, the root bridge for
TE

the user-defined instances is DS-2 (note that AS-1 connects to DS-2 using ge-0/0/10.0).
IN

30 www.juniper.net
 Monitoring and Troubleshooting

LY
N
O
SE
U
AL

Review the MSTP Configuration

N

To effectively troubleshoot this issue you must be familiar the protocol operations and requirements
for MSTP.
R

A quick look at the show spanning-tree mstp configuration output on AS-1 and DS-1
helps identify a potential issue. As shown on the slide, the configuration digests on AS-1 and DS-1 do
TE

not match. This digest must be the same across all device in the same region. The configuration
digest is comprised of the region name, revision level, and MSTI to VLAN-ID mappings. If you pay
special attention to the output, you can see that there is a VLAN member mismatch between the two
devices, which may be the cause of our current problem. We verify if changing the VLAN members
IN

associated with MSTI 1 fixes the issue on the next slide.

www.juniper.net 31
Monitoring and Troubleshooting

LY
N
O
SE
U
AL

Testing the Possible Solution

N

This slide shows the updated configuration used to test the theory identified on the last slide. Once
the illustrated configuration is in place on DS-1 all four switches illustrated in the diagram should
R

participate in the same MSTP region. Once all four switches are participating in the same MSTP
region, we should see DS-1 elected as root bridge for MSTI 1 which services VLAN-IDs 10 through 19.
TE

We verify the results of this configuration change on the next slide.

IN

32 www.juniper.net
 Monitoring and Troubleshooting

LY
N
O
SE
U
AL

Verify Results
N

Now that the four switches are configured to participate in the same MSTP region, we verify the root
bridge elections for the defined MSTIs using the show spanning-tree interface command.
R

The sample output shown on the slide now shows that AS-1 considers DS-1 as root bridge for MSTI1
(AS-1 connects to DS-1 using ge-0/0/8.0) and considers DS-2 as root bridge for MSTI2 (AS-1
TE

connects to DS-2 using ge-0/0/10.0). Now that DS-1 and DS-2 are functioning as root bridges for
their respective MSTIs, you should see end-user traffic distributed between the available paths and
the complaints about congestion should subside (at least for now).
IN

www.juniper.net 33