Saturday, September 23, 2017

Port Priority based Root Port Election in STP

This is a concept which is misunderstood by many people. It is really because of the topologies they use to learn this concept.

When the switch has two interfaces connecting to the same switch, and the cost to reach the root bridge is the same it will use the interface with the lowest number as the root port..

For an example, let's say SW-A has the lowest MAC address hence SW-A will be the Root..

What will be the Alternate Port here?
Is it the e0/1 of SW-B?
Yes

By just looking at the port numbers, we can say that..
What will be the Alternate Port here?
Is it the e0/3 of SW-B?
No
E0/1 of SW-B will be the Alternate Port..




This is where most people will answer incorrectly.. The port priority which is considered is not the port priority of the of the SW-B. It is the port priority of the BPDU sender. Which in this case is the Root Bridge (SW-A).. Sender's port priority is what matters..

If we look at the output of show spanning-tree; (I use actual hardware from here)
































Because the priority is 128 default which is equal in all ports it has boiled down to the port number.. Lower port number will be the root port..

Let's change the port priority manually on SW-A..

SW-A(config-if)#int fa0/2
SW-A(config-if)#spanning-tree port-priority 16

































Now you can see the Alternate Port is changed to Fa0/3 of SW-B..

Additional Note:-
Decision making process of STP is like the following..

(1) Lowest bridge ID: the switch with the lowest bridge ID becomes the root bridge.
(2) Lowest path cost to Root Bridge: when the switch receives multiple BPDUs it will select the interface that has the lowest cost to reach the root bridge as the root port.
(3) Lowest sender bridge ID: when a switch is connected to two switches that it can use to reach the root bridge and the cost to reach the root bridge is the same, it will select the interface connecting to the switch with the lowest bridge ID as the root port.
(4) Lowest sender port ID: when the switch has two interfaces connecting to the same switch, and the cost to reach the root bridge is the same it will use the interface with the lowest number as the root port.

Tale of 2 BPDUs & Their Propagation in Classic STP

There are 2 types of Bridge Protocol Data Units (BPDUs)

(1) Configuration BPDUs
(2) Topology Change Notification BPDUs (TCNs)

Using these 2 types of frames, STP does it's everything..

A BPDU frame has the following format..






















Let's see a normal operation..

Configuration BPDUs are generated from the Root Bridge (Root Switch) and flow outward along the active paths and move away from the Root Bridge. Which means Non-root switches will receive these from their Root ports & Block ports and forwards out only from their Designated ports..

Each designated switch changes the Root Path Cost, Bridge ID & Port ID of the BPDU they receive before they send them downstream..

Following image shows the propagation of the Configuration BPDUs in a switching network..





















Let's see what happens when a link goes down..

For example, let's assume a link on S-5 (not the link connected to S-3) goes down.
Here is where the TCNs (PBDUs which can go upstream) were introduced.

TCNs are generated normally from Non-root switches and flow upstream towards the Root Bridge to inform the Root Bridge that the network topology has changed. Which means Non-root switches will forward out these only from their Root ports and receive only from their Designated ports..

The TCN is a very simple BPDU that contains absolutely no information that a bridge sends out every Hello Time seconds (this is locally configured Hello Time, not the Hello Time specified in configuration BPDUs which were set by the Root Bridge).

The designated bridge acknowledges the TCN by immediately sending back a normal configuration BPDU with the topology change acknowledgement (TCA) bit in Flag field set. The bridge that notifies the topology change does not stop sending its TCN until the designated bridge has acknowledged it.

Note that TCA is not a new BPDU.. It's just a Configuration BPDU with a bit changed..

Propagation of TCNs are indicated in red and the propagation of TCAs are indicated in green..





















Once the TCNs hit the Root, it also acknowledges the designated switch and it starts to send out its Configuration BPDUs with the topology change (TC) bit set.

These BPDUs are relayed by every bridge in the network with this bit set. As a result all bridges become aware of the topology change situation and it can reduce its CAM table Aging Time to Forward Delay.

Bridges receive TC BPDUs on both forwarding and blocking ports because they are actually Configuration BPDUs.

TC BPDUs are propagated like the following way.. They are also not a new BPDU type. Just the Configuration BPDUs with a bit change.





















These TC BPDUs are sent for a period of Max Age + Forward Delay seconds, which is 20+15=35 seconds by default. Here is why..

We deal with 4 timers in STP..

(1) Hello Time
(2) Max Age
(3) Forward Delay
(4) Aging Time

You can see those 4 timers in  the show spanning-tree output..

















Hello Time is the time frequency which the Configuration BPDUs are sent.. Default is 2s.
Max Age is the time which a BPDU is considered valid by a switch.. Default is 20s.
Forward Delay is the time which it takes to move from Listening State to Learning State and Learning State to Forwarding State.. Default is 15s.
Aging Time is the time which a CAM table entry will be valid.. Switches flush the MAC Address entry from it's CAM table after this time expires.. Default is 300s.

The reason for the TC BPDUs are sent for a period of Max Age + Forward Delay is that it will force the switch to flush the old remembered BPDUs and clear the MAC address table.

You can see the CAM Aging Time changes to Forward Delay on show spanning-tree output by entering the following debug command and unplugging a port of a switch..
S-1-ROOT#debug spanning-tree events




















Note:- You will not see the receipt of TC BPDUs on debug, but all the switches in the network will receive them silently and change their timers and relearn the MAC addresses..

We found 4 BPDUs in the above STP process.

(1) Config BPDU
(2) TCN
(3) TCA
(4) TC

But there are actually only 2 types which are Config BPDUs & TCNs. TCAs & TCs are just Config BPDUs with only a bit changed in the Flag field of the frame..

Wednesday, September 20, 2017

Concept of Transparent ASA

Default mode of operation for Cisco ASA is the Routed Mode. It can also operate in a mode called "Transparent Mode" which allows ASA to monitor traffic while forwarding in Layer 2 domain.

IP address of the PC: 192.168.10.10
Gateway (e0/0 of R): 192.168.10.1

We are going to put an ASA in between PC and Gateway, which will not change any configuration in Gateway.. This is the use case of Transparent ASA. It will not be discovered by other devices in the network. 

Let's see how it is configured..

Remember to backup your configurations before changing the ASA mode from Router to Transparent as it will clear all the current configuration.

Enter the following command to change the firewall mode to Transparent.
ciscoasa(config)#firewall transparent

Create a BVI, to know more about BVIs please go here.
ciscoasa(config)#interface BVI 1
ciscoasa(config-if)#ip address 192.168.1.150 255.255.255.0

Configure inside interface grouping to the BVI,
ciscoasa(config)#int gig 1
ciscoasa(config-if)#security-level 100
ciscoasa(config-if)#nameif INSIDE
ciscoasa(config-if)#bridge-group 1
ciscoasa(config-if)#no shut

Configure outside interface grouping to the BVI,
ciscoasa(config)#int gig 0
ciscoasa(config-if)#security-level 0
ciscoasa(config-if)#nameif OUTSIDE
ciscoasa(config-if)#bridge-group 1
ciscoasa(config-if)#no shut

As soon as you enter the above commands, it will be displayed in the int ip brief output like the following..










Now the configuration is over. PC will forward the general traffic to internet via the gateway without knowing there is an ASA in between. But the icmp pings will not work until you configure your ASA to inspect them.. You can do it either by ASDM or CLI..
Following are the commands to do it in CLI,
ciscoasa(config)#policy-map global_policy
ciscoasa(config-pmap)#class inspection_default
ciscoasa(config-pmap-c)#inspect icmp

Note:- If there are switches in both sides of ASA, you will have to use Ethertype ACLs to allow BPDUs. By default ASA will not forward BPDUs..
If there are routers in both sides which uses a routing protocol like OSPF, you will have to allow multicast traffic in order to make adjacencies.
If you configured a DHCP in Gateway and PC is a DHCP client, you will have to do additional configuration in ASA to allow broadcast traffic.
You will not be able to terminate VPNs in this mode of ASA because the interfaces work as L2 interfaces..

You can view the current mode of ASA by the following command..
ciscoasa#show firewall

You can change the ASA  back to routed mode by the following command..
ciscoasa(config)#no firewall transparent