Huawei – Router on a Stick (Router and Switch Config)

How to Configure Huawei router-on-a-stick

Requirements: The range on the host broadcast domain of communication can be reduced by VLAN configuration to the switch on the LAN. You can use a router that supports 802.1Q to realize interoperability of VLAN on the condition that part of the hosts need to communicate among VLAN while the switches doesn’t support the huawei three-layer switch, which requires the establishment of a sub-interface on the Ethernet port, assignment of the IP address as the related VLAN gateway, and start 802.1Q at the same time.

Networking: Connect E0 port of the router with uplink trunk port (24th ports) of the switch on the router, and divide 3 VLAN on switch downward port with several hosts.

Router Config

interface Ethernet0/0/4
ip address 10.0.0.1 255.255.255.0

interface Ethernet0/0/4.1           
  ip address 172.16.1.1 255.255.255.0
  vlan-type dot1q vid 1

Specify the Ethernet sub-interfaces belonging to VLAN1, and this command is applied to the Ethernet sub-interface. Only this command is configured, the Ethernet sub-interface will be embedded VLAN tag in the Ethernet frame header according to the configuration of the VLAN ID number so that the switch port connected to the switch interface can deal with the received frame correctly only the command has been configured.             

interface Ethernet0/0/4.2                     
ip address 172.16.2.1 255.255.255.0
dot1q termination vid 2

interface Ethernet0/0/4.3
  ip address 172.16.3.1 255.255.255.0
  dot1q termination vid 3

interface Ethernet0/0/4
  undo shut
% Interface Ethernet0/0/4 is up

Connect the E0 port with the 24th port of S3026 with the network cable                             
%19:46:32: Interface Ethernet0/0/4 changed state to UP
%19:46:32: Line protocol ip on interface Ethernet0/0/4, changed state to UP
%19:46:32: Line protocol ip on interface Ethernet0/0/4.1, changed state to UP
%19:46:32: Line protocol ip on interface Ethernet0/0/4.2, changed state to UP
%19:46:32: Line protocol ip on interface Ethernet0/0/4.3, changed state to UP

 

Switch Config

vlan 1

vlan 2
interface eth 0/17
interface eth 0/18
interface eth 0/19
interface eth 0/22

vlan 3
interface eth 0/21

interface eth 0/24
port link-type trunk
port trunk permit vlan all

Check out the TRUNK port configuration
display port trunk    
Now, the following trunking ports exist:
Ethernet0/24

Check out the VLAN2 configuration
display vlan 2     
VLAN ID: 2
VLAN Type: static
Route Interface: not configured
Description: VLAN 0002

Tagged Ports:
Ethernet0/24

Untagged Ports:
Ethernet0/17 Ethernet0/18 Ethernet0/19 Ethernet0/22

Check out the VLAN3 configuration
display vlan 3     
VLAN ID: 3
VLAN Type: static

Route Interface: not configured
Description: VLAN 0003

Tagged Ports:
Ethernet0/24

Untagged Ports:
Ethernet0/21

Check the network connectivity on the workstation. This workstation is connected to the 21st port of S3026, belonging to VLAN2.

C:\Documents and Settings\Administrator>ipconfig
windows 2000 IP Configuration
Ethernet adapter             Local connection:
Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 172.16.2.22
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 172.16.2.1

C:\Documents and Settings\Administrator>ping 172.16.3.1

Pinging 172.16.3.1 with 32 bytes of data:

Reply from 172.16.3.1: bytes=32 time<10ms TTL=255
Reply from 172.16.3.1: bytes=32 time<10ms TTL=255
Reply from 172.16.3.1: bytes=32 time<10ms TTL=255
Reply from 172.16.3.1: bytes=32 time<10ms TTL=255

Ping statistics for 172.16.3.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

View the routing table on the Huawei router, can be found, as each of the network segments on the 172.16 are connected to the router directly, so the communication between the VLAN can be realized without starting the routing protocols or static routing.

[Router]display ip routing-table

Routing Tables:

Destination/Mask Proto Pref Metric Nexthop Interface

10.0.0.0/24 Direct 0 0 10.0.0.1 Ethernet0
10.0.0.1/32 Direct 0 0 127.0.0.1LoopBack0
127.0.0.0/8 Direct 0 0 127.0.0.1 LoopBack0
127.0.0.1/32 Direct 0 0 127.0.0.1 LoopBack0
172.16.1.0/24 Direct 0 0 172.16.1.1 Ethernet0.1
172.16.1.1/32 Direct 0 0 127.0.0.1 LoopBack0
172.16.2.0/24 Direct 0 0 172.16.2.1 Ethernet0.2
172.16.2.1/32 Direct 0 0 127.0.0.1 LoopBack0
172.16.3.0/24 Direct 0 0 172.16.3.1 Ethernet0.3
172.16.3.1/32 Direct 0 0 127.0.0.1 LoopBack0

Based On:

• http://www.huanetwork.com/blog/how-to-configure-huawei-router-on-a-stick/
• http://enterprise.huawei.com/ilink/enenterprise/download/HW_U_150647 – Huawei AR150&200 Config Guide

Related Links:

• http://www.h3c.com/portal/Technical_Support___Documents/Technical_Documents/Routers/H3C_SR6600_Series_Routers/Configuration/Operation_Manual/H3C_SR6600_OM-Release_2315(V1.09)/01/201212/765203_1285_0.htm#_Toc263351507
• http://labnario.com/index.php/18-labnario/how-to/81-how-to-configure-trunk-between-huawei-router-and-switch
• http://paperzz.com/doc/1656079/how-to-configure-trunk-between-huawei-router-and-switch--...

Boot Linux ISOs From Hard Drive ( GRUB )

How to Boot Linux ISO Images Directly From Your Hard Drive

Linux’s GRUB2 boot loader can boot Linux ISO files directly from your hard drive. Boot Linux live CDs or even install Linux on another hard drive partition without burning it to disc or booting from a USB drive.

We performed this process on Ubuntu 14.04 — Ubuntu and Ubuntu-based Linux distributions have good support for this. Other Linux distributions should work similarly.

Get a Linux ISO File

How to Configure the GRUB2 Boot Loader’s Settings
Ubuntu and most other Linux distributions now use the GRUB2 boot loader. You can change its settings to select a... [Read Article]

This trick requires you have a Linux system installed on your hard drive. Your computer must be using the GRUB2 boot loader, which is a standard boot loader on most Linux systems. Sorry, you can’t boot a Linux ISO file directly from a Windows system using the Windows boot loader.

Download the ISO files you want to use and store them on your Linux partition. GRUB2 should support most Linux systems. if you want to use them in a live environment without installing them to your hard drive, be sure to download the “live CD” versions of each Linux ISO. Many Linux-based bootable utility discs should also work.

Check the Contents of the ISO File

You may need to look inside the ISO file to determine exactly where specific files are. For example, you can do this by opening the ISO file with the Archive Manager/File Roller graphical application that comes with Ubuntu and other GNOME-based desktop environments. In the Nautilus file manager, right-click the ISO file and select Open with Archive Manager.

Locate the kernel file and the initrd image. If you’re using a Ubuntu ISO file, you’ll find these files inside the casper folder — the vmlinuz file is the Linux kernel and the initrd file is the initrd image. You’ll need to know their location inside the ISO file later.

Determine the Hard Drive Partition’s Path

GRUB uses a different “device name” scheme than Linux does. On a Linux system, /dev/sda0 is the first partition on the first hard disk — a means the first hard disk and 0 means its first partition. In GRUB, (hd0,1) is equivalent to /dev/sda0. The 0 means the first hard disk, while the1 means the first partition on it. In other words, in a GRUB device name, the disk numbers start counting at 0 and the partition num6ers start counting at 1 — yes, it’s unnecessarily confusing. For example, (hd3,6) refers to the sixth partition on the fourth hard disk.

You can use the fdisk -l command to view this information. On Ubuntu, open a Terminal and run the following command:

sudo fdisk -l

You’ll see a list of Linux device paths, which you can convert to GRUB device names on your own. For example, below we can see the system partition is /dev/sda1 — so that’s (hd0,1) for GRUB.

Create the GRUB2 Boot Entry

The easiest way to add a custom boot entry is to edit the /etc/grub.d/40_custom script. This file is designed for user-added custom boot entries. After editing the file, the contents of your /etc/defaults/grub file and the /etc/grub.d/ scripts will be combined to create a /boot/grub/grub.cfg file — you shouldn’t edit this file by hand. It’s designed to be automatically generated from settings you specify in other files.

You’ll need to open the /etc/grub.d/40_custom file for editing with root privileges. On Ubuntu, you can do this by opening a Terminal window and running the following command:

sudo gedit /etc/grub.d/40_custom

Feel free to open the file in your favorite text editor. For example, you could replace “gedit” with “nano” in the command to open the file in the Nano text editor.

Unless you’ve added other custom boot entries, you should see a mostly empty file. You’ll need to add one or more ISO-booting sections to the file below the commented lines.

Here’s how you can boot an Ubuntu or Ubuntu-based distribution from an ISO file. We tested this with Ubuntu 14.04:

menuentry “Ubuntu 14.04 ISO” {
set isofile=”/home/name/Downloads/ubuntu-14.04.1-desktop-amd64.iso”
loopback loop (hd0,1)$isofile
linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=${isofile} quiet splash
initrd (loop)/casper/initrd.lz
}

Customize the boot entry to contain your desiredmenu entry name, the correct path to the ISO file on your computer, and the device name of the hard disk and partition containing the ISO file. If the vmlinuz and initrd files have different names or paths, be sure to specify the correct path to those files, too.

(If you have a separate /home/ partition, omit the /home bit, like so: set isofile=”/name/Downloads/${isoname}”).

Important Note: Different Linux distributions require different boot entries with different boot options. The GRUB Live ISO Multiboot project offers a variety of menu entries for different Linux distributions. You should be able to adapt these example menu entries for the ISO file you want to boot. You can also just perform a web search for the name and release number of the Linux distribution you want to boot along with “boot from ISO in GRUB” to find more information.

If you want to add more ISO boot options, add additional sections to the file.

Save the file when you’re done. Return to a Terminal window and run the following command:

sudo update-grub

The next time you boot your computer, you’ll see the ISO boot entry and you can choose it to boot the ISO file. You may have to hold Shift while booting to see the GRUB menu.

If you see an error message or a black screen when you attempt to boot the ISO file, you misconfigured the boot entry somehow. Even if you got the ISO file path and device name right, the paths to the vmlinuz and intird files on the ISO file may not be correct or the Linux system you’re booting may require different options.

Taken From: http://www.howtogeek.com/196933/how-to-boot-linux-iso-images-directly-from-your-hard-drive/

Cisco – Modify / Fix Config via SNMP (SSH example)

Fixing SSH access on cisco via SNMP

Sometimes you may encounter a situation, when your SSH is not properly configured.  In this situation you might be lucky enough to have SNMP RW community string configured. In this situation you can fix literally everything.

 

Download the Config via SNMP

You may download current device’s config to tftp server, edit necessary lines and upload it back. You may upload it to either running config, startup config or a flash file.

To download running config:

snmpset -c san-fran -v 2c 192.168.1.23 1.3.6.1.4.1.9.9.96.1.1.1.1.2.111 i 1
snmpset -c san-fran -v 2c 192.168.1.23 1.3.6.1.4.1.9.9.96.1.1.1.1.3.111 i 4
snmpset -c san-fran -v 2c 192.168.1.23 1.3.6.1.4.1.9.9.96.1.1.1.1.4.111 i 1
snmpset -c san-fran -v 2c 192.168.1.23 1.3.6.1.4.1.9.9.96.1.1.1.1.5.111 a 192.168.1.252
snmpset -c san-fran -v 2c 192.168.1.23 1.3.6.1.4.1.9.9.96.1.1.1.1.6.111 s config_dsw1.txt
snmpset -c san-fran -v 2c 192.168.1.23 1.3.6.1.4.1.9.9.96.1.1.1.1.14.111 i 1

where:

• san-fran - is the community key of your cisco router.
• 192.168.1.23 - is the ip address of your Cisco device.
• 192.168.1.252 - is the ip address of your tftp server.
• config_dsw1 - is the name where the running configuration
• will be saved.
• 111 - random number

 

Commands Explained

1.3.6.1.4.1.9.9.96.1.1.1.1.2.111 i 1
ccCopyProtocol: The protocol file transfer protocol:

1 - tftp
2 - ftp
3 - rcp
4 - scp
5 - sftp
 
1.3.6.1.4.1.9.9.96.1.1.1.1.3.111 i 4
ccCopySourceFileType: Specifies the type of file to copy from:

1 - networkFile
2 - iosFile
3 - startupConfig
4 - runningConfig
5 - terminal
6 - fabricStartupConfig

1.3.6.1.4.1.9.9.96.1.1.1.1.4.111 i 1
ccCopyDestFileType: specifies the type of file to copy to:

1 - networkFile
2 - iosFile
3 - startupConfig
4 - runningConfig
5 - terminal
6 - fabricStartupConfig

1.3.6.1.4.1.9.9.96.1.1.1.1.5.111 a 192.168.1.252
ccCopyServerAddress: The IP address of the TFTP server

1.3.6.1.4.1.9.9.96.1.1.1.1.6.111 s config_dsw1.txt
ccCopyFileName: The file name (including the path) of the file.

1.3.6.1.4.1.9.9.96.1.1.1.1.14.336 i 1
ccCopyEntryRowStatus: The status of this table entry. Once is set to active, the associated entry cannot be modified until
the request completes (‘successful’ or ‘failed’) The object can be:

1 - active
2 - notInService
3 - notReady
4 - createAndGo
5 - createAndWait
6 - destroy

When enter this command, the router will send  the running configuration to the ftp-server!

 

Change the Config

If you encountered situation with SSH with no generated certificate, You config might look like this:

line vty 0 4
length 0
transport input ssh
line vty 5 15
transport input ssh
exit

You should fix it to:

line vty 0 4
length 0
transport input telnet
line vty 5 15
transport input telnet
exit

Some commands can be cancelled with “no ” statment before the command. Some, as in above case, not.

 

Upload the Config via SNMP

Upload it back by the following commands. Be careful! If you upload to startup-config, IOS will not merge the uploaded config and the startup one, it will replace it instead. Do not upload partial sets of commands!. To be on a safe side always I recommend to never upload partial configs. Only necessary lines should be added/cancelled/corrected and the whole config should be uploaded.

snmpset -c san-fran -v 2c 192.168.1.23 1.3.6.1.4.1.9.9.96.1.1.1.1.2.222 i 1
snmpset -c san-fran -v 2c 192.168.1.23 1.3.6.1.4.1.9.9.96.1.1.1.1.3.222 i 1
snmpset -c san-fran -v 2c 192.168.1.23 1.3.6.1.4.1.9.9.96.1.1.1.1.4.222 i 4
snmpset -c san-fran -v 2c 192.168.1.23 1.3.6.1.4.1.9.9.96.1.1.1.1.5.222 a 192.168.1.252
snmpset -c san-fran -v 2c 192.168.1.23 1.3.6.1.4.1.9.9.96.1.1.1.1.6.222 s config_dsw1.txt

where:

san-fran - is the community key of your cisco router.
192.168.1.23 - is the ip address of your Cisco device.
192.168.1.252 - is the ip address of your tftp server.
config_dsw1.txt - is the name where the running configuration will be saved.
222 - random number

 

Commands Explained

1.3.6.1.4.1.9.9.96.1.1.1.1.2.222 i 1
ccCopyProtocol: The protocol file transfer protocol:

1 - tftp
2 - ftp
3 - rcp
4 - scp
5 – sftp

1.3.6.1.4.1.9.9.96.1.1.1.1.3.222 i 1
ccCopySourceFileType: Specifies the type of file to copy from:

1 - networkFile
2 - iosFile
3 - startupConfig
4 - runningConfig
5 - terminal
6 - fabricStartupConfig
 
1.3.6.1.4.1.9.9.96.1.1.1.1.4.222 i 4
ccCopyDestFileType: specifies the type of file to copy to:

1 - networkFile
2 - iosFile
3 - startupConfig
4 - runningConfig
5 - terminal
6 - fabricStartupConfig

1.3.6.1.4.1.9.9.96.1.1.1.1.5.222 a 192.168.1.252
ccCopyServerAddress: The IP address of the TFTP server to copy the configuration file from.

1.3.6.1.4.1.9.9.96.1.1.1.1.6.222 s config_dsw1.txt
ccCopyFileName: The file name (including the path) of the file.

1.3.6.1.4.1.9.9.96.1.1.1.1.14.222 i 1
ccCopyEntryRowStatus: The status of this table entry.
Once is set to active, the associated entry cannot be modified until the request completes (‘successful’ or ‘failed’) The object can be:

1 - active
2 - notInService
3 - notReady
4 - createAndGo
5 - createAndWait
6 - destroy
 

Based On:

• http://tiamat.name/blogposts/fixing-ssh-access-on-cisco-via-snmp/
• http://www.ciscozine.com/send-cisco-commands-via-snmp/
• http://www.ciscozine.com/how-to-save-configurations-using-snmp/

Related Links

• http://www.cisco.com/c/en/us/support/docs/ip/simple-network-management-protocol-snmp/15217-copy-configs-snmp.html
• http://www.notarus.net/networking/cisco_snmp_config.html
• http://ccie20728.wordpress.com/2008/05/20/get-the-cisco-configuration-over-snmp/
• http://packetpushers.net/fixing-screwups-with-snmp-config-management

Spanning Tree – PVST / PVST+/ MST – Bridge ID and Root Selection

Spanning Tree Protocol: Bridge ID, Priority, System ID Extension & Root Bridge Election Process

Written by Arani Mukherjee. Posted in Spanning Tree Protocol (STP)

In this article we will examine the Spanning Tree Bridge ID structure, explain why it has increments of 4096, how VLAN information is embedded (for Per-VLAN Spanning Tree & multiple STP instances) via the System ID Extension and finally explain how the Spanning Tree Protocol Root Bridge Election occurs.

Understanding Bridge ID, Bridge Priority & System ID Extension

In our earlier article we discussed about the Spanning Tree Protocol, Rapid STP port costs and port states. Before STP decides which path is the best to the Root Bridge, it needs to first decide which switch has to be elected as the Root Bridge, which is where the Bridge ID comes into play. Readers interested can also read our STP Principles, Redundant Network Links & Broadcast Storms article.

Every switch has an identity when they are part of a network. This identity is called the Bridge ID or BID. It is an 8 byte field which is divided into two parts. The first part is a 2-byte Bridge Priority field (which can be configured) while the second part is the 6-byte MAC address of the switch. While the Bridge Priority is configurable, the MAC address is unique amongst all switches and the sum of these two ensures a unique Bridge ID.

The above Bridge ID assumes there is one Spanning Tree instance for the entire network. This is also called Common Spanning-Tree (CST).

As networks begun to grow and become more complex, VLANs were introduced, allowing the creation of multiple logical and physical networks. It was then necessary to run multiple instances of STP in order to accommodate each network - VLAN. These multiple instances are called Multiple Spanning Tree (MST), Per-VLAN Spanning Tree (PVST) and Per-VLAN Spanning Tree Plus (PVST+).

In order to accommodate the additional VLAN information, the Extended System ID field was introduced, borrowing 12 bits from the original Bridge Priority:

The Bridge Priority value and the Extended System ID extension together make up a 16 bit (2-byte) value. The Bridge Priority making up the left most bits, is a value of 0 to 61440. The Extended System ID is a value of 1 to 4095 corresponding to the respective VLAN participating in STP. The Bridge Priority increments in blocks of 4096 to allow the System ID Extension to squeeze in between each increment. This is clearly shown in the below analysis: We should note that the Bridge Priority Field can only be set in increments of 4096. This means that possible values are: 4096, 8192, 12288, 16384, 20480, 24576, 28672, 32768 etc. By default, Cisco’s Per-VLAN Spanning-Tree Plus (PVST+) adds this System ID Extension (sys-id-ext) to the Bridge Priority.

The two values (Bridge Priority + System ID Extension) together make up the Bridge ID used to elect the Root Bridge.

The Root Bridge Election Process

The election process uses several STP messages sent between switches which help each switch to decide, who is the Root Bridge. These messages are called Hello BPDU where BPDU stands for Bridge Protocol Data Unit. It is important to understand the information these BPDUs carry as it will help understand the election process itself.

Each BPDU carries several fields in it. The following table defines each field:

Field	Description
Root Bridge ID or Root BID	BID of the switch that the sender of this BPDU believes to be the root switch
Sender’s Bridge ID	BID of the switch sending this Hello BPDU
Cost to the Root Bridge	The STP cost between this switch and the current root
Timer values on Root Bridge	Hello Timer, Max Age Timer, Forward Delay Timer

For the purpose of this exercise, we will only concentrate on the first three fields.

Now, the election process itself is very simple. The switch with the lowest BID becomes the Root Bridge. Since the BID starts with the Bridge Priority field, essentially, the switch with the lowest Bridge Priority field becomes the Root Bridge. If there is a tie between two switches having the same priority value, then the switch with the lowest MAC address becomes the Root Bridge.

The STP Root Bridge election process starts with each switch advertising themselves as the Root Bridge and constructing the Hello BPDU accordingly. So each switch lists its own BID as the Root BID. The Sender Bridge ID is ofcourse the same as the Root BID, as it is again its own BID. With in BPDU, the Cost field is listed with a value of 0, because there is no cost between itself. The switches send out the Hello BPDU constructed as above, onto the network. They will keep on maintaining their status as Root Bridge by default, until they receive a Hello BPDU which carries a lower BID. This Hello BPDU then becomes a superior BPDU. Now the switch receiving this superior BPDU makes changes to the Hello BPDU it has been sending out. It changes the value of the Root BID to reflect the Root BID from the superior Hello BPDU. This process continues till every switch agrees on which switch has the lower BID, and hence deserves to be the Root Bridge.

Root Bridge Election Example

Let's look at this process using a three switch combination within a network. For the sake of simplicity, the MAC address of each switch has been changed to a simple value:

· Switch 1 (SW1). Has a priority of 32768 and MAC address of 1111.1111.1111. So its BID becomes 32768.1111.1111.1111. When SW1 creates its own BPDU, it sets both BID and Root BID to 32768.1111.1111.1111.

· Switch 2 (SW2). Has a priority of 32768 and MAC address of 2222.2222.2222. So its BID becomes 32768.2222.2222.2222. When SW2 creates its own BPDU, it sets both BID and Root BID to 32768.2222.2222.2222.

· Switch 3 (SW3). Has a priority of 32768 and MAC address of 3333.3333.3333. So its BID becomes 32768.3333.3333.3333. When SW3 creates its own BPDU, it sets both BID and Root BID to 32768.3333.3333.3333.

Now, the election process commences with the advertisement of the individual Hello BPDU's from each switch, as indicated by the arrows in our diagram. These BPDUs originate from each switch and end up at the other switches. Let's take up one switch at a time to see how it reacts to the BPDUs it receives from the other switches.

Switch 1 (SW1): It had sent out its own Hello BPDU with both BID and Root BID set to 32768.1111.1111.1111. When it receives the Hello BPDU from SW2, it checks for the Root BID value which is 32768.2222.2222.2222. SW1 discards the BPDU sent by SW2, as it still is the switch with the lowest BID. Same situation happens when it receives the Hello BPDU from SW3. SW1 is still the switch with the lowest BID. So it discards the Hello BPDU received from SW3 and keeps on advertising itself as the Root Bridge.

Switch 2 (SW2): Just like SW1, SW2 generates and sends its own Hello BPDU with both BID and Root BID set to 32768.2222.2222.2222. When it receives the Hello BPDU from SW1, it checks for the Root BID value which SW1 has set to 32768.1111.1111.1111. This being lower than SW2's own BID, makes the Hello BPDU received from SW1, a superior BPDU. So in its own BPDU, SW2 changes the value of the Root BID from 32768.2222.2222.2222, to 32768.1111.1111.1111, and starts advertising this revised Hello BPDU. SW2 now considers SW1 as the Root Bridge. Now, when it receives the Hello BPDU from SW3, it will obviously discard the BPDU as it is not superior in Root BID value. So for SW2, SW1 remains as Root Bridge, even after receiving the Hello BPDU from SW3.

Switch 3 (SW3): SW3 will send out its own Hello BPDU with both BID and Root BID set to 32768.3333.3333.3333. Depending on which Hello BPDU it receives first i.e. from SW1 or SW2, it will end up changing the Root BID value in its Hello BPDU because both SW1 & SW2 have lower MAC addresses. So if it received the Hello BPDU from SW2 first, then it will change the Root BID from 32768.3333.3333.3333 to 32768.2222.2222.2222 and consider SW2 as new Root Bridge. Once it receives the Hello BPDU from SW1, this BPDU supersedes the BPDU sent by SW2. So SW3 changes the Root BID from 32768.2222.2222.2222 to 32768.1111.1111.1111 and now considers SW1 as new Root Bridge.

At this point, all switches have received each other's BPDU and have agreed that SW1 has the lowerst BID address and is therefore the rightful Root Bridge of the network. Both SW2, and SW3 now agree that SW1 is Root Bridge, and start organizing their respective links into Root Ports and Designated Ports.

What if we wanted Switch 3 to be the Root Bridge?

In most real-life cases, we need to configure the Root Bridge to ensure that no matter the switch that joins the network, our initial Root Bridge will remain. To achieve this, we simply configure the Bridge Priority so that it is always smaller than the default value of 32768.

In our example, if we wanted Switch 3 to become the new Root Bridge, we would set its Bridge Priority to 4096. By doing so, we change its BID to 4096.3333.3333.3333 making it the lowest amongst our network switches.

Configuring a new BID in a production network is not recommended unless every caution has been taken to ensure network downtime is eliminated. When the BID of a switch changes to make it a Root Bridge, the whole network (switches) will react upon this and begin recomputing the new information. Depending on where the new Root Bridge is located, switch uplinks and redundant links might be blocked.

This article analysed the Spanning Tree Protocol Bridge ID structure and its importance. We saw how the Bridge Priority and System ID Extension fields play a primary role in the Root Bridge election within a network.

Taken From: http://www.firewall.cx/networking-topics/protocols/spanning-tree-protocol/1054-spanning-tree-protocol-root-bridge-election.html

Spanning Tree – STP / RSTP - Port Costs and States

Spanning Tree Protocol, Rapid STP Port Costs - Port States

Written by Arani Mukherjee. Posted in Spanning Tree Protocol (STP)

Spanning Tree Protocol, Rapid STP port costs and port states are an essential part of the STP algorithm that affect how STP decides to forward or block a port leading to the Root Bridge.

In our previous article that covers Understand STP Principles, Redundant Network Links & Broadcast Storms we encountered some key issues related to switching that causes degradation in network performance.

Those issues were broadly categorised as follows:

· Broadcast storm

· Unstable MAC Table in switches

· Multiple duplicate frames arriving at hosts

In order to avoid the above situations, Spanning Tree Protocol or STP is implemented. The aim of this protocol and its deployment is to provide a single path of communication between each Ethernet segment (e.g a link between two switches). Since the issues discussed in our previous article, and STP itself only relates to switching, our discussion will only refer to switches. It is worth noting that both bridges and switches make use of the STP protocol.

To create a single path between each Ethernet segment, for to and fro communication, STP decides on the state of each Ethernet interface. An interface can only be in two states, Forwarding state or Blocking state. STP employs its algorithm and puts certain interfaces in a Forwarding state. All other interfaces not put in a forwarding state are placed in a Blocking state.

Now before we start looking into what criteria STP uses to put a port in Forwarding or Blocking state, let’s understand certain terminologies using the network diagram below:

Root Bridge: A switch with all its ports placed in Forwarding state is a root bridge. The Root Bridge is often called Root Switch.

Another way to think of the Root Bridge is as the Master Switch (for loop avoidance matters), for which only one active path must exist from all other switches, effectively avoiding any possible network loops.

Root Port: For a non–root switch, the port that connects this switch to the root switch, with the least cost, is called the root port.

Designated Port: A non – root port, which is forwarding away from the root switch, and has the lowest cost in that Ethernet segment, is called the designated port.

Cost: A port cost is defined by the speed at which the port operates. The cost of a port is inversely related to the associated bandwidth and therefore a port with a low cost value (greater bandwidth-speed) is more preferable than a port with high cost value (lower bandwidth-speed).

Note: The process of the Root Bridge election, Designated and Root Ports is covered in great detail in our Spanning Tree Protocol: Bridge ID, Priority, System ID Extension & Root Bridge Election Process articles.

The table below was published by the IEEE group in 1998 and represented the cost against bandwidth:

The original STP Cost-Bandwidth table - Year 1998

The cost value (column marked “Range”) supported a 16-bit value (1 – 65535) while the root path cost was assigned a 32bit value embedded within the Bridge Protocol Data Unit (BPDU) field. BPDU's are special STP packets that contain all necessary information about the network's Spanning Tree topology.

In 2004, the revised 802.1D had its 16- bit path cost increased to a 32-bit value, providing more granularity:

STP uses the following criteria to decide whether to place a port in a Forwarding state or Blocking state

1. STP elects a Root Bridge, and then puts all its working interfaces in a Forwarding state

2. All other switches are now non–root switches. STP now looks at all the Root Ports from these switches, and finds the one with the Least Cost. Once this is found, STP places that interface in a Forwarding state.

3. Now STP finds all the Designated ports on the non–root switches, and places them in a Forwarding state.

4. Then STP places all other ports in a Blocking state.

It is absolutely essential to understand that the process of the Root Bridge and non-root switches election along with the port selection is performed only on working interfaces. Any failed/down interface i.e. no cables connected, or an interface which has been shutdown administratively, is parked into an STP Disabled state. Such ports are not considered during STP algorithm deployment.

Now let’s summarise what has been established previously:

Port Description	STP State	Important Observation
All ports on root switch	Forwarding	Root switch is always the designation switch on all Ethernet segment
Root ports on non – root switches	Forwarding	These are the ports that non – root switches use to reach the root switch
Every LAN’s designation port	Forwarding	The non – root port, that forwards away from the root switch, with lowest cost
All other working ports	Blocking	These ports are not used for forwarding, and any frames received on these interfaces are not forwarded as well.

The following table shows the available Port states for the original STP (802.1D) and newer Rapid STP (802.1w) designed to provide faster convergenceto topology changes. We should note that the three states Disabled, Blocking & Listening from STP (802.1D) have merged into one state, Discarding, for Rapid STP (802.1w):

STP (802.1D) Port State	RSTP (802.1w) Port State	Is Port Included in Active Topology?	Is Port Learning MAC Addresses?
Disabled	Discarding	No	No
Blocking	Discarding	No	No
Listening	Discarding	Yes	No
Learning	Learning	Yes	Yes
Forwarding	Forwarding	Yes	Yes

Support of Rapid STP (RSTP) in Cisco Catalyst Switches

This table shows the support of RSTP in Cisco Catalyst switches, and the minimum software required for that support. As a general rule of thumb, all newer Catalyst switches provide support for RTSP.

Catalyst Platform	MST w/ RSTP	RPVST+ (also known as PVRST+)
Catalyst 2900 XL / 3500 XL	Not available.	Not available.
Catalyst 2940	12.1(20)EA2	12.1(20)EA2
Catalyst 2950/2955/3550	12.1(9)EA1	12.1(13)EA1
Catalyst 2970/3750	12.1(14)EA1	12.1(14)EA1
Catalyst 3560	12.1(19)EA1	12.1(19)EA1
Catalyst 3750 Metro	12.1(14)AX	12.1(14)AX
Catalyst 2948G-L3/4908G-L3	Not available.	Not available.
Catalyst 4000/2948G/2980G (CatOS)	7.1	7.5
Catalyst 4000/4500 (IOS)	12.1(12c)EW	12.1(19)EW
Catalyst 5000/5500	Not available.	Not available.
Catalyst 6000/6500	7.1	7.5
Catalyst 6000/6500 (IOS)	12.1(11b)EX, 12.1(13)E, 12.2(14)SX	12.1(13)E
Catalyst 8500	Not available.	Not available.

In this article we covered Spanning Tree Protocol, Rapid STP port costs and port states. In our next article, we will start looking at how STP deploys the criteria. So, we will understand how STP decides which switch will be the Root Bridge , how it elects the Root Ports and Designated Ports. We will also investigate how STP reacts to any changes to the network topology and incorporates the changes in its algorithm.

Back to Spanning Tree Protocol Section

Taken From: http://www.firewall.cx/networking-topics/protocols/spanning-tree-protocol/1045-spanning-tree-protocol-port-costs-states.html

Spanning Tree – Principles

Spanning Tree Protocol – Understand STP Principles, Redundant Network Links & Broadcast Storms

Written by Arani Mukherjee. Posted in Spanning Tree Protocol (STP)

One of the most used terms in network is LAN (Local Area Network). It’s a form of network that we encounter in our daily lives, at home, at work, study, and in various other areas of life. Unless working specially in the field of Wide Area Networks (WAN), you will come across a LAN pretty much everyday. A key protocol used to maintain efficiency within a LAN is the Spanning Tree Protocol (STP), which is standardized as IEEE 802.1D. Without this protocol our LANs would rapidly become congested, with frames looping throughout the network infinitely, making network devices unstable. This protocol is implemented on switches, as switches deal with network data at the frame level. But before going ahead with a full blown explanation of what STP is, it is important to understand the ‘problem’ that STP prevents and how it improves a LAN’s performance. Let’s go through some salient features of a LAN first.

One of the most important devices within a LAN is a switch. All standard switches are Layer 2 devices i.e. they work at the level of frames. A frame is the unit of transmission in a link layer protocol and consists of a link-layer header followed by a packet. Without going into too much detail, a switch communicates in terms of frames. Users interested learning more about frames, can visit our Ethernet Frame Formats section where they'll find plenty of useful information and 3D representations of the various Ethernet frames. Apart from the higher layer data encapsulated by the frame, it carries two other important pieces of information, the Source MAC Address and the Destination MAC Address. It’s important to make a note of this as it becomes vital in our understanding of how a switch works and for STP itself.

How Does a Switch Work?

It must be noted that, before starting on this tutorial, it is best to have an understanding of how a switch works. If not then all is not lost. Users can always look up existing switch principles covered under the Switches & Bridges article.

Understanding of the following topics is essential for STP:

· How a switch finds MAC Addresses of new hosts

· How a switch populates its MAC Address tables

· How a switch deals with an incoming frame when it doesn’t know which outgoing interface to switch it to (due to no entry for a destination MAC Address in the switching table)

If the above fundamental principles are clear, learning about STP becomes simple.

Within permissible limits it might be said that STP is introduced within the LAN to prevent complications and network related problems caused by the way a switch functions. The flaw does not lie with how a switch works, it lies with the repercussions and manifestations of traffic because of it. Now let us run through some of the major issues encountered within a LAN.

Problems with Switches & Redundant Links

Just like our lives, LANs becomes big and complicated and cater to a huge number of devices. To provide interconnectivity and redundancy, sometimes switches are connected between themselves to ensure data streams are always maintained between network hosts. In an ideal world, a simple network would only have a router, a switch, and ‘n’ number of hosts connected to that switch, depending on how big the switch is. But just like Utopia, this ideal world doesn’t exist and networks have multiple switches, and sometimes these switches have interconnections. It’s done to provide redundant paths to various parts of the network to which these switches provide connectivity.

But by virtue of how a switch functions, there can be a few rather alarming issues cropping up very quickly when switches have more than one way of connecting various parts of the network. To visualise this concept, here’s a setup that has two hosts connected via two switches. For the sake of simplicity the router has been left out of this equation. Since STP is all about effective switching, let’s not involve ourselves in routing. The switching layout is, then, as follows:

To simplify this layout, please consider the following

· There are two switches, SW1 and SW2

· There are two hosts, PC1 and PC2, connected to SW1 and SW2 respectively

· MAC Address of PC1 is PC1-MAC1 and that of PC2 is PC2-MAC2

· SW1 and SW2 are connected to each other via 2 links, LINK 1 and LINK 2. These are redundant links

· For LINK1, the interface used on SW1 is SW1-MAC1, and the interface used on SW2 is SW2-MAC1

· For LINK2, the interface used on SW1 is SW1-MAC2, and the interface used on SW2 is SW2-MAC2

Now let’s look at a condition where both switches have an empty MAC address table. PC1 sends out a frame whose destination is PC2. This frame reaches SW1. Right now SW1 does not know which interface to use to forward this frame to PC2, so it does a broadcast. By virtue of frame forwarding, the source address of this frame now changes. Since this broadcast will go out through both LINK 1 and 2, the outgoing broadcast frames will have different source addresses.

Let us consider the frame from SW1 going out on LINK 1. Its destination address still reads PC2-MAC2. But its source address now reads SW1-MAC1. When this frame reaches SW2, SW2 does not know which interface to use to forward this frame to PC2-MAC2, so it does a broadcast. By virtue of a broadcast from a switch, this frame will not go out on LINK 1 again. This broadcasted frame goes out to PC2 and also goes out on LINK 2. Once PC2 receives this broadcast, it acknowledges receipt and SW2 learns the interface to use to forward a frame whose destination MAC Address says PC2-MAC2. But what about the broadcast frame that went out on LINK 2? This now reaches SW1, and its destination MAC Address still reads PC2-MAC2. SW1, for the second time, does not know which interface to use to forward this frame. So guess what it does? It does a broadcast again, causing PC1 to receive a frame it sent out in the first case.

So you see, an innocent frame that was destined for just one host on the other end of this simplified network, ended up with the host that sent it out in the first place. This is what is known as a broadcast storm. Now this process will keep on going till the network becomes congested with multiple duplicate frames, thus reducing its performance.

This is not the only issue on this LAN. What happens in the background is that the MAC table within both switches becomes extremely unstable. This is caused by the effect of the frame with the same destination MAC Address approaching the two switches with different source MAC Address. Hence the MAC table on each switch keeps getting updated without achieving any stable state. Not to mention the fact that due to this broadcast storm the hosts keep receiving multiple duplicate frames.

So to sum up, the issues encountered in the above situation are now made clear:

· Broadcast storm

· Unstable MAC Table in switches

· Multiple duplicate frames arriving at hosts

STP is aimed at resolving all the above issues. This is discussed in the next tutorial, Spanning Tree Protocol, Rapid STP Port Costs - Port States, where we will start discovering the working principle of this protocol, along with some key features and associated terms.

Back To Spanning Tree Protocol Section

Taken From: http://www.firewall.cx/networking-topics/protocols/spanning-tree-protocol/1042-spanning-tree-protocol-fundamentals.html

Cisco NAT – Port Forwarding a Range of Ports

One question that comes up very often is “How do I port forward a range of ports?” Normally the answer is that you can’t or that you need to input one translation rule for each port manually

I tested this in my lab and everything worked great. Here is the topology:

He is the config for forwarding a range of ports (1-1024) from R2 public IP address (200.0.0.1/24) to the server internal IP address (10.0.0.1/24).

!-- IFs Config ------------------
interface FastEthernet0/0
ip address 10.0.0.254 255.255.255.0
ip nat inside
      
interface FastEthernet0/1
ip address 200.0.0.1 255.255.255.0
ip nat outside

!-- NAT - Port Range Forward --
ip nat pool PORTFWD 10.0.0.1 10.0.0.1 netmask 255.255.255.0 type rotary

ip nat inside destination list 100 pool PORTFWD
access-list 100 permit tcp any any range 1 1024

This config at glance looks a pretty stardart NAT configuration except for the “…type rotary” on the NAT pool.

Cisco’s definition for this feature is the following:

“Perform this task to configure server TCP load balancing by way of destination address rotary translation. The commands specified in the task allow you to map one virtual host to many real hosts. Each new TCP session opened with the virtual host will be translated into a session with a different real host.” [cisco]

So, the normal usage of this feature is to distribute TCP sessions for the public IP of R2 (200.0.0.1/24) across multiple internal servers as a way to do TCP Sessions Load Balancing:

you can find an example of this here.

In order to achive the port forwarding of a range of ports, instead of having a range of servers (private IPs), we only have one:

ip nat pool PORTFWD 10.0.0.1 10.0.0.1 netmask 255.255.255.0 type rotary

so all the TCP sessions are load balanced into a single host, thus achieving the port range forwarding.

Tested this on a 2691 router on GNS3.

 

For more information check out these Links: 

• Port Range: http://evilrouters.net/2010/05/25/port-forwarding-a-range-of-ports-on-cisco-ios/
• Port Range: http://ciscovoiceguru.com/tag/ios/
• Definition: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat/configuration/12-2sx/nat-12-2sx-book/iadnat-addr-consv.html#GUID-D4F13BC2-3855-4E3B-AB03-1FC22B9FDEDC
• Real Usage: https://sites.google.com/site/amitsciscozone/home/nat/tcp-load-distribution-using-rotary-nat
• Real Usage: http://www.netcraftsmen.net/resources/archived-articles/427-network-address-translation.html

 

Please check out my DIY community at:

• https://www.facebook.com/BragaLab

click “Like” to suport it.