Tuesday, October 11, 2011

CSTP & RSTP

Nowadays, all geeks are well know about CSTP common spanning tree protocol and it did great help to manage a loop free switching only network. It well known for it steable and flexible for all sorts of network enviroment. This is all about some one do not know RSPT, a improved version of STP!


STP algorithm
1.       root bridge selection
2.       root port selection
3.       designated port selection


      
Root bridge selection phase
1.       bridge priority and system ID (VLAN ID) extension (optional, used in PVST and PVST+, used to calculate STP for each VLAN)
2.       system ID (SW MAC address)
Root port selection phase
1.       The cost to the root bridge
2.       directly connected bridge ID, the lower the better
3.       port ID
Designated port selection phase
1.       The cost to the root bridge, designated ports are always reverse to the root bridge.
2.       Directly connected bridge ID, the lower the better
3.       port ID

Tips:
1.       If the convergence is done, only Root Bridge will propagate BPDU.
2.       Every STP operation is based on BPDU and some system timers (hello interval, hold timer etc.)


BPDU format
























STP Timers
Hello Timer This is how often the root bridge will send out BPDUs. These BPDUs get relayed down the spanning-tree to all the other switches. The default is 2 seconds.
Max Age Timer This is how often a bridge will actually save the BPDU information it receives from other switches. Think of it as sort of a hold timer. The default is 20 seconds, and it helps prevent against loops in the event of indirect link failures.
Forward-Delay This determines how long a switch will spend in each of the listening and learning states of STP. The default is 15 seconds, which means that out of the box we spend 15 seconds in listening and 15 seconds in learning.
The different states of STP are as follows:

STP States
Blocking In the blocking state the port is essentially shut down. The switch discards frames received on the interface. It will receive BPDUs from the DP on the segment but will not pass them along to other switches. The important thing to note, and that we will see in this blog through actual logs is that the blocking state is not something that a port goes into every single time it comes up. A switch will go through the blocking state when it is first initialized (boots up) and it will place ports that could cause L2 loops into blocking when necessary. This does not mean that every single time you plug a device into the switch that the port goes into blocking before going to listening and learning. As we will see later, the blocking state is typically only seen during indirect link failures.

Listening In listening state the port is starting to transition into doing something. In this state, the switch will actually process the BPDUs it receives on the port although we are still discarding frames at this point. Note that per the RFC Listening and Learning MUST be the same amount of time. There is no way to tweak one or the other. If you change one, you change the other.

Learning In the learning state the port continues its transition by learning MAC addresses on the port, continuing to receive and process BPDUs, and transmitting BPDUs on to neighboring switches. Note that per the RFC Listening and Learning MUST be the same amount of time. There is no way to tweak one or the other. If you change one, you change the other.

Forwarding In the forwarding state the port is up and running. At this point the port actually forwards frames and continues to monitor BPDUs

Disabled This isn't really a state of STP. This means STP is essentially turned off.

The beauty of this algorithm is, STP could automatically calculate a loop free topology for our network, but there are several drawbacks for calculating:

1.        The max_age timer: if topology changed, an indirect block port will wait for its “max_age” expires to enable it to listening state, by default, it will wait @ 20 secs on cisco switches.
2.        Accesses ports do not need to participate in STP calculating, because it directly connected to end-devices.
3.        Even the STP radius is smaller than default (7 switches), the STP port will wait a whole rtt time to proceed to forwarding state ( 15sec for sending, 15 secs for receiving) no feedback solution

Because of above reasons, we need to wait at least 50 secs to re-converge into a new STP network, which is totally unendurable for some critical business env. So a btr version 802.1W RSTP.

Rapid transition is the most important feature introduced by 802.1w. The legacy STA passively waited for the network to converge before it turned a port into the forwarding state. The achievement of faster convergence was a matter of tuning the conservative default parameters (forward delay and max_age timers) and often put the stability of the network at stake. The new rapid STP is able to actively confirm that a port can safely transition to the forwarding state without having to rely on any timer configuration.
There is now a real feedback mechanism that takes place between RSTP-compliant bridges.

Since there are so many good materials about RSTP features and they have already done an excellent explication so I won’t write anything on it, instead I will put some very great references, after read thru those docs, you will totally fall in love with that. Hope you will enjoy the new RSTP worldJ



Saturday, October 8, 2011

PAC and DNS requests annoyed problem

there are serveral functions that are not working properly as we expected, they always perform DNS request to DNS servers which we do not like to see:

isResolvable(host);

isInNet(host, "999.99.9.9", "255.0.255.0");

If those functions are invoked, a numerous DNS requests are generated from the client, so the clients just dully wait for the responses for those requests, therefore to the end-users, it just like the broswer is dreadfully dead there.



if (isResolvable(host))
 return "DIRECT";
 else
 return "PROXY 172.30.19.190:8080";

this, the "isResolvable" evil cuased a lot of troubles to our broswers, we did not expect the client initiate DNS request, instead, we would work everything with proxy, every request is and should be performed by proxy. Unfortunately, our PAC script is not that clever, since it is a locally functioned script, it cannot ask proxy server to the "isResolvable" functionality, it has to be done by the broswer which employs so many useless DNS requests to us. In order to avoid this scenario happens to us, we should avoid to use those functions.

Here below is my solution, I know, it's really far away from perfect, if you have any better ideas, just share it!


 if (isPlainHostName(host)
     || dnsDomainIs(host, "companydomain.com")
     || (url.substring(7, 12) == "192.10.") //for ftp
     || (url.substring(7, 12) == "192.11.")
     || (url.substring(8, 13) == "192.11.") //for http
     || (url.substring(8, 13) == "192.10.")
     || (host == "127.0.0.1"))
 return "DIRECT";
 else
 return "PROXY proxy:8080";