In a network where Service Providers run customers’ VLAN traffic over their backbone network, there is a possibility of VLAN crushing if different customers use overlapping VLAN IDs. With Q-in-Q Tunneling Providers can segregate different customers’ VLAN traffic on a link (for example, if the customers use overlapping VLAN IDs) or bundle different customer VLANs into a single service VLAN.

With Q-in-Q tunneling, providers can segregate or bundle customer traffic into fewer VLANs or different VLANs by adding another layer of 802.1Q tags. Q-in-Q tunneling is useful when customers have overlapping VLAN IDs because the customer’s 802.1Q (dot1Q) VLAN tags are prepended by the service VLAN (S-VLAN) tag.

This makes it a suitable solution for service providers since it gives them freedom on which S-VLANs to use without changing customers’ C-VLANs and customers can use any VLANs they want.

How Q-in-Q Tunneling Works

In Q-in-Q tunneling, as a packet travels from a customer VLAN (C-VLAN) to a service provider’s VLAN (S-VLAN), a customer-specific 802.1Q tag (Customer’s S-VLAN tag) is added to the packet. This additional tag is used to segregate traffic into service-provider-defined service VLANs (S-VLANs). The original customer 802.1Q tag (C-VLAN(s) tag(s)) of the packet remains and is transmitted transparently, passing through the service provider’s network. As the packet leaves the S-VLAN in the downstream direction, the extra 802.1Q tag (Customer’s S-VLAN tag) is removed.

This solution has been illustrated on a Juniper EX-2300-C Switch with Enhanced Layer 2 Software (ELS) support.

There are multiple ways Q-in-Q tunneling maps C-VLAN(s) to S-VLAN(s).

1. All-in-one bundling
2. Many-to-one bundling
3. Many-to-many bundling
4. Mapping a specific interface

In this tutorial, only “All-in-one bundling” will be covered.

Continue reading “Q-in-Q Tunneling for ELS support on Juniper Switches” →

Virtual private LAN service (VPLS) multihoming enables you to connect a customer site to two or more PE routers to provide redundant connectivity. A redundant PE router can provide network service to the customer site as soon as a failure is detected. VPLS multihoming helps to maintain VPLS service and traffic forwarding to and from the multihomed site in the event of the following types of network failures:

• PE router to CPE device link failure
• PE router failure
• MPLS-reachability failure between the local PE router and a remote PE router

Ideally, each customer should have dedicated physical connections to PEs, but this kind of setup is expensive for service providers to maintain. Therefore, a new approach of Sub Rings connecting different customers with the use of different VLAN-IDs has been lately utilized as shown below. This makes each CPE logically appear as if it’s connected directly to PEs.

However, VPLS Multihoming was designed to detect failures when the physical interface it’s running on goes down and with this kind of setup, if CPE-2 is multihomed between PE-01 and PE-02 as primary and backup respectively, and the link between CPE-2 and CPE-1 goes down, PE-01 will not notice that failure, therefore, VPLS multihoming will not failover to PE-02 and hence fail-over will not be achieved.

In this blog, we shall cover the set up and configuration of VPLS Multihoming with BGP signaling in a Sub-ring scenario to address the challenge mentioned above.

Continue reading “VPLS Multihoming in a Sub-ring setup using rpm and event-handlers for Juniper” →

INTRODUCTION

Cisco Nexus 3000 Series Switches are designed for data center top-of-rack deployments by providing 24 to 128 ports offering flexible connectivity, high performance, and a comprehensive feature set. It usually runs on multiple versions of OS images including 6.2a, 6.3a, 6.8, 7.3 and many others.

Figure 1: Nexus 3000 series switch

TFTP (Trivial FTP), is a file-transfer protocol geared towards a much simpler, and thus less robust, set of needs as far as file transfers go. TFTP is ideal for transferring of firmware updates, moving system images around, and other tasks that require far more functionality than the traditional FTP. It operates on UDP port 69.

In this article, we are going to recover a Cisco Nexus 3000 Series Switch using images installed on a TFTP server.

SIGNS OF A FAULTY NEXUS SWITCH

• Continuous booting,
• Cannot load Operating system image,
• Cannot read USB drives.

PREREQUISITES

• In this article, the TFTP server IP address is 168.10.10/24.
• Ensure the kickstart and main images are stored in the TFTP server and set the TFTP server to use the directory or folder where the files are located.
• In this article, we shall use n3000-uk9-kickstart.6.0.2.U5.3.bin as our kickstart image and n3000-uk9.6.0.2.U5.3.bin as our file image.

SETTING UP THE TFTP SERVER.

In this article, a Debian-based Linux server with UFW firewall was used to set up the TFTP server as root user.

NB: The configuration on the server IP address is beyond the scope of this article.

• Install the TFTP server.

# apt-get -y update && apt-get install -y tftp-hpa

• Configure the TFTP server.

# echo ‘TFTP_USERNAME=”tftp”‘ > /etc/default/tftpd-hpa

# echo ‘TFTP_DIRECTORY=”/srv/tftp”‘ >> /etc/default/tftpd-hpa

# echo ‘TFTP_ADDRESS=”0.0.0.0:69″‘ >> /etc/default/tftpd-hpa

# echo ‘TFTP_OPTIONS=”–secure”‘ >> /etc/default/tftpd-hpa

• Copy the Cisco recovery images (assuming they are in the current working directory) to the TFTP directory

# cp -n n3000-uk9-kickstart.6.0.2.U5.3.bin /srv/tftp

# cp -n n3000-uk9.6.0.2.U5.3.bin /srv/tftp

• Start the TFTP service

# systemctl start tftpd-hpa

• Allow traffic to the TFTP port.

# ufw allow to any port 69

RECOVERING THE NEXUS SWITCH

• Connect the switch’s Management (MGMT) port (by the power supply) to the network where the TFTP server resides.
• Configure the switch’s IP reachability using the management port to be able to communicate with the TFTP server.

loader> set ip 192.168.10.4 255.255.255.0

loader> set gw 192.168.10.1

• Boot the kickstart image file from the TFTP server.

loader>boot tftp://192.168.10.10/n3000-uk9-kickstart.6.0.2.U5.3.bin

• After a successful boot, you will be directed to the (boot)# From here, you can check whether the boot flash is empty. If empty, copy the files (kickstart image, main image, and license file) over from the TFTP server.

1. NB. You may need to format the bootflash in case of corrupted condition.

• If all is well, then copy the kickstart and main image files using the following commands:

switch(boot)#copy tftp://192.168.10.10/n3000-uk9-kickstart.6.0.2.U5.3.bin bootflash:/n3000-uk9-kickstart.6.0.2.U5.3.bin

switch(boot)#copy tftp://192.168.10.10/n3000-uk9.6.0.2.U5.3.bin bootflash:/n3000-uk9.6.0.2.U5.3.bin

• Verify that both images are in the bootflash using the command:

switch(boot)#dir bootflash:

• See if the switch is able to boot up using the main image.

switch(boot)#load bootflash:/n3000-uk9.6.0.2.U5.3.bin

• During the boot, you will be asked whether you would like to enter the initial configuration mode, type This will lead you to the basic configuration, you can then verify your configuration present using the command “show running configuration” in configuration mode.

switch#show running-config

• Go ahead and reload the switch to ensure that the switch is able to boot up normally.

switch#reload

FURTHER READING

• http://www.confignotes.com/2018/04/cisco-nexus-3000-loader/
• https://www.cisco.com/c/en/us/products/switches/nexus-3000-series-switches/index.html
• https://www.ittsystems.com/best-free-tftp-servers-windows/

Ping Plotter

This is a tool used by the RENU community to troubleshoot network issues. Once an institution is facing problems they are prompted to share their results with the NOC for interpretation. The big question is do you understand these graphs.

This write-up covers the basic features of the graphs and their interpretation.

You’ve captured something in PingPlotter that looks like evidence of a network problem. Let’s take a closer look and see what the graph tells us about the source of your network problem.

Understanding PingPlotter graphs begins with the final destination. That’s the target you’re testing. PingPlotter represents the final destination with the bottom row of the trace graph.

Check for packet loss

Take a look at your PingPlotter results. Do you see a red bar? If so, that means some data was lost between your computer and the target. This effect is known as packet loss, and if you’re seeing it on the final destination, there’s a good chance you captured a problem.

Check for latency

What about the black line? It shows how long it takes data to travel to your target and back. This measurement is known as latency. It’s another network problem indicator. The further to the right the black line is the longer it takes for data travel around the network. If you see high latency on your final destination, you’ve probably captured a network problem

Follow the pattern to the source

When you have an idea of what’s happening on the final destination, it’s time to look at the rows leading up to the final destination. Do you notice any patterns leading up to the final destination?

Where the pattern begins, helps you understand the source of the problem. If the pattern starts on the first row in the graph (your router), you’re probably dealing with an internal network problem.

Figure 1 Internal problems begin on the first hop

If the pattern originates somewhere in between the first and last row, the problem is probably outside your local network then contact the NOC it could be problems on the international circuit

Figure 2 Problems outside your network begin in the middle.

.It’s time to make a diagnosis. Do you think the source of your problem is on your local network, or it is it outside your local network?

Wireless Problems

Sometimes other devices interfere with your wireless network. If you connect with ethernet (the cable) and the problem goes away, you probably have a wireless issue.

Bandwidth

Bandwidth problems happen when your network usage exceeds your capacity. If your network problem happens during network-intensive activities like gaming, downloading, or multiple users, there’s a good chance you have a bandwidth issue.

Hardware

When network devices fail, it’s a hardware problem. If you don’t think you’re dealing with bandwidth or wireless issue, it’s time to start looking into hardware.

All the examples above can be categorised as Internal network issues. If you suspect more that the problem is outside your local network contact the NOC.

 

Optical Bypass Switches

A bypass switch (or bypass TAP) is a hardware device that provides a fail-safe access port for an in-line active network device such as an intrusion prevention system (IPS), next-generation firewall, network switch etc. if the device loses power, experiences a software failure, or is taken off-line for updates or upgrades, traffic can no longer flow through the critical link. The bypass switch or bypass tap removes this point of failure by automatically ‘switching traffic via bypass mode’ to keep the critical network link up.

A bypass switch has four ports. Two network ports create an in-line connection in the network link that is to be monitored. This connection is fully passive; if the bypass switch itself loses power, traffic continues to flow unimpeded through the link.

Two monitor ports are used to connect the in-line device. During normal operation, the bypass switch passes all network traffic through the network (CPE) switch as if it were directly in-line itself. But when the switch (CPE) loses power, is disconnected, or otherwise fails, the bypass switch passes traffic directly between its network ports, bypassing the CPE, and ensuring that traffic continues to flow on the network link.

A bypass switch monitors the health of the CPE by sending heartbeats to the network switch (CPE) as long as the network device/switch is on-line, the heartbeat packets will be returned to the optical bypass switch and the link traffic will continue to flow through the CPE.

If the heartbeat packets are not returned to the Optical Bypass Switch (CPE has gone off-line), the Optical Bypass will automatically bypass the CPE and keep the link traffic flowing. The Optical Bypass also removes the heartbeat packets before sending the network traffic back onto the critical link.

Cacti is a free network graphing tool that is used to visualize the time series data obtained by the Round-Robin database tool (RDD tool).

The tool polls network devices like switches and routers via SNMP and then graphs their data. Some of the data that are polled are CPU load, temperature, uptime and network bandwidth utilization.                                                                                                                                        

Here we shall focus on how you can monitor your bandwidth from the cacti graphs.

Continue reading “Using cacti to monitor bandwidth consumption” →

After OS upgrade on Junos MX5, you are hit with following notice upon reboot;
— JUNOS 13.3R9.13 built 2016-03-01 07:16:35 UTC
— NOTICE: System is running on alternate media device (/dev/da1s1a)

This error is as a result of various scenarios and below are the possible causes:
1.) A software failure/error on the primary media (flash)
2.) A hardware failure on the primary media (flash)
3.) A request issue reboot on the secondary media (disk)

Continue reading “Junos MX5 error after OS upgrade: System is running on alternate media device (/dev/da1s1a)” →

Traffic Analysis is a critical component in network planning, security and troubleshooting. For you to perform traffic analysis, you need to collect network traffic flows from the different aggregation points in your network such as routers and switches.

In Juniper, they take advantage of ‘sampling’ packets and frames going through a switch or router. The sampled flows can used by third party applications such as nfsen and ntop.

This configuration solution was done on a Juniper Mx 5 Router using ipfix .

Create a sampling instance at the chassis level in this case it was named ‘1to1’
set chassis tfeb slot 0 sampling-instance 1to1

Place the flow table size at the chassis level on tfeb for both IPv4 and IPv6
set chassis tfeb slot 0 inline-services flow-table-size ipv4-flow-table-size 5
set chassis tfeb slot 0 inline-services flow-table-size ipv6-flow-table-size 5

Continue reading “Traffic Flow Sampling in Juniper Mx-5 and Mx-480 Routers IPv4 and IPv6” →

Problem Statement

There are times when a router/switch can only boot up in ROMmon. This happens when the router/switch has no valid Cisco IOS software or bootflash image to boot from. This disaster recovery situation arises when, for example, the Cisco IOS software on the router/switch is corrupted or has crashed.

There are also cases where the router/switch has no USB port, or where it is not possible to set up a network connection with the router/switch, and hence using the Trivial File Transfer Protocol (TFTP) is not a solution.

Continue reading “Uploading Cisco IOS using XMODEM” →