Router Packet Forwarding

The Term packet switching is use to describe the routing of a packet from incoming interface on router to outgoing interface

                                                      Let’s now consider what’s going on inside of router architecturally as say, packet flows in the input, the ingress interface on a router and get routed to output or egress interface on a router.

We have different frame forwarding option: -

We wanna look at 3 major one in this topic: -

Process Switching: - With Process switching is we going to see, the router processor the CPU (Central Processing unit) gets involved with every packet forwarding decision. It gets quite a bit more efficient with fast switching. In Process switching router architecture dividing into two Plane “Control Plane and Data Plane”

The Data Plane is where our traffic is actually flowing through the router

The Control Plan is gonna be handling behind the seems tasks and we have a CPU the router processor that can do working both of these planes.

                                                      However, if the CPU became involved in every single packet forwarding decision. That’s not terribly efficient. We could overwhelm CPU with too much traffic. However, that’s exactly what processing switch does. This is the oldest approach to forwarding packet to router.

                                                         Let’s imagine that we have a packet coming in to this router incoming interface or the ingress interface. With Process Switching every single packet has to go up to CPU.

And we ask the CPU “how do we route this packet” and CPU has to take a look the routing table and say “that packet is gonna go out of this particular interface” So the CPU is gonna direct the packet to leave via the outgoing interface.

That’s Process switching and because of CPU is involved in every single packet, routing, packet switching, decision. It is not very efficient

Let’s look at much more efficient approach that’s called “Fast Switching”

With Fast Switching we have another architecture component. The “Route Cache”.

That can learn how we have previously routed a packet to a specific network.

                                            For example, let’s say “A packet comes into the router and its destined for a network that, we have not yet routed the packet too. Since we never done it before, we go ask CPU “how we route to his network”

The CPU is gonna do lookup its IP Routing Table and says” To go out this egress interface”. But here what happened. The CPU is going to cause that entry that says” to go to this network go out of this interface”. That information is gonna be written into the Route Cache.

And that first packet it is gonna be routed out to the destination network.

But now that information has been stored in to Route Cache. What happened, if second packet comes in and destined for that network. Since we done it before, since we learned, since we cache the information. That say’s” packet going to this network go out of this interface”. We don’t need to ask CPU, we can simply query the Route Cache and says “how do we route traffic”, going to this network”.

And Route Cache says” Oh! Yaw, I seen that before we gonna go out of this interface”.

That’s the concept of “Fast Switching”

Interestingly There is more efficient approach: - 

With CEF (Cisco Express Forwarding), we don’t have to ask the CPU for first time we trying to route a packet to a specific destination network, because with CEF, the CPU is going to proactively populate the FIB (that’s the Forwarding Information Base, that’s the Layer 3 information).

It essentially got the IP Routing table information in memory in this FIB, and very efficient table structure, where lookup information very very rapidly. That’s Layer 3 information but we also need some Layer 2 information, that will allow us to quickly foam a frame header. So for example, the FIB says “to go to this network, go to this next-hop ip address”. Well the Adjacency Table can say “To get to that next-hop ip address” we need to go out this interface, we gonna be using this “encapsulation type”, and here is destination mac-address.

So Adjacency Table and FIB Table, they provide all of the information we need to route a packet. The Packet comes in incoming interface even, if we never routed to this network before. We don’t ask the CPU how to get there, we just go to ask the FIB and Adjacency Table.

We ask CEF, and CEF has learned all this information, and CEF is gonna be directly out this appropriate egress interface.

                                                              This is gonna be most efficient approach to doing Packet Switching, because we never had to ask the CPU how I had get to the destination network. By the way There is change in network, if there is change in ip routing table then CEF it gonna be updated through reflect that

So CEF is a very CPU friendly approach to Packet Switching 

Click Here To Download The PDF File

If You Like the Post. Don’t forget to “Subscribe/Share/Comment”. Thank You.

Read More

DHCP Snooping

First let’s review how DHCP operate normally

                                                              We got a laptop for example DHCP Client and when it comes up on the network it needs ip address information. It might need an “IP address, Subnet mask, a DNS server and Default gateway and might need another piece of information

DHCP uses something called the “DORA” Process

There are four different messages exchanged between DHCP Client and DHCP Server

DORA
D	Discover
O	Offer
R	Request
A	Acknowledgement

                                          Here Just assume that DHCP server and client in same subnet and we going to send broadcast “it’s says “DHCP Discover” broadcast and that’s received by the DHCP Server and it respond within Offer “DHCP Offer “that’s the “O” in DORA process. The offer is identifying this specific DHCP server. At this point the client knows the ip address of this “Corporate DHCP Server”. Then we would complete the DORA process, the client would send the “R” the “Request” saying “hey can I have some ip address information”, then the “A” in DORA is the “Acknowledgement”

                                 The big point there is that the “D” in DORA process is to send a broadcast and the broadcast goes everywhere within Vlan by default 

What if we have malicious user introduce a “Rouge DHCP Server” on the network.

                                                   When this DHCP Client sends out its DHCP Discover message. The “Legitimate(True) DHCP Server” and the Rouge DHCP Server would get that, and they both respond, what if the rouge DHCP Server responded quicker, then the corporate DHCP Server. Well our client its gonna go whichever server responded quicker

                                                       If we did have Rouge DHCP server on the network. Statically it would respond before the corporate DHCP Server at certain percentage of time, and we would have these DHCP Clients learning their ip address information from the rouge DHCP Server and what harm could cause

                                                           Well this rouge DHCP Server could be sending information “saying that the default gateway for client” is actually the attacker device. The attacker could be intercepted all these traffic coming from the client, and then they would forward traffic on its way, so though the client didn’t realize anything wrong. That’s the one way of launching the “Man in Middle Attack” where the attacker is convincing the client to send traffic through the attacker device

Way to Prevent that, is to use feature Cisco gives us on over cisco catalyst switches called “DHCP snooping”

What we can do is, go in and say “which ports are “Trusted” and which ports are “Untrusted”

                                           We would say that “we wanna to trust ports that were uplink ports that’s guide us to our legitimate(True) DHCP server” But we would not trust other ports. That way when DHCP client send out its Discover message

And which received by the legitimate(True) DHCP server and Rouge DHCP server. 

                                                         When the Rouge DHCP server responded within offer, it would be rejected by that untrusted port running a DHCP snooping.

                                                          Meanwhile the legitimate(True) DHCP Offer message would make it back to the client and client would get authenticated information

Configuration of DHCP Snooping in Cisco Catalyst Switch

Now Add one extra layer of Protection

                                                     In addition to having Rouge DHCP server on the network, another DHCP Threat called DDOS(Denial-of-Service) Attack. We can have somebody that start flooding our legitimate(True) DHCP server with overwhelming number of DHCP discover message. We can do our untrusted ports typically we can limit maximum amount of dhcp traffic going to be allowed that port. We can set DHCP rate limit on untrusted port.

Verification:-

Conclusion: - That’s a look how we can add a couple of layer of DHCP Protection to our network using great little feature “DHCP Snooping”

Cilck Here To Download The PDF File

Read More

StackWise

Cisco gives us huge favor by giving us a feature called “Stackwise”

With Stackwise we have all of the switches virtually appear as a single chasse. Logically its look like a modular switch and each of these physical switch chassis, they appear to be a different modular. We can manage this entire stack of switches with a single management ip address. We don’t have to be bouncing back and forth between one console and another console. We get mange all of them in one place

You notice that back of switches we got a couple of special connectors, a stack1 and stack2 connector, and we those connector to interconnect all of the switch using the interconnect cable. That’s allow the switches to appear to be in the same virtual switch chasse

Benefits of Stackwise

Ø  Scalability prospective we have many as many 9 switches in a single stack

Ø  Also we can manage all nine switches in as stack using single management ip address

Ø  We have Redundant connection between switches

Ø  And also there is going to be one switch that automatically elected as the master switch from the stack. If that switch goes down, their gonna be automatic reelection for another master switch.

ü  That means we got redundancy in case of interconnected cable issue.

ü  We have redundancy in case of switch failure

ü  And truly ease of administrative burden 

Few different flavor of Stackwise

Ø  Stackwise and Stackwise Plus: - We find these feature on cisco catalyst 3750-E and X series switches and cisco catalyst 3850 series switch. These model of switches support Stackwise and Stackwise plus

ü  Stackwise Plus: - is an enhancement that the allow us to do local switching. If we have stack of 9 switches with ingress and egress ports on same physical chasse. There is a no need to send that traffic of over that virtual backplane. It stays on local switch that’s gonna keep unnecessary traffic of those interconnect cable

ü  Stackwise Plus is a technology that allow us to use that virtual backplane officially

Ø  Stackwise-480:- it available on cisco catalyst 3850 series switches. This increase the virtual backplane speed interconnecting our switches in the stack and speed in 480 Gigabit per second as name suggest. They all are multilayer switches

Ø  Cisco does have a Stackwise like feature for L2 switches and it’s called “Flex Stack”. We can find these on cisco catalyst 2960-s Series switches. In that Flex Stack we can manage 4 of these switches.

Verify StackWise Operation

Ø  Output of this command gives us a lot’s of information about

ü  The status of a virtual Stackwise switch

ü  Status of stack

ü  The status of Stack Port

ü  The Mac-address being used by stack

ü  And stack manger version

Conclusion:- Stackwise is a way to logically combine multiple chassis into a single virtual chasse

ü  With redundancy of our interconnected cables

ü  And redundancy in case of one of physical chasse were fail

ü  And the Stack will continue to operate 

Click Here To Download The PDF File

Read More

SPAN and RSPAN

Let’s imagine the topology where we have their client and server and they exchanging traffic back and forth

                       

                                        If we trying to do maybe some troubleshooting, something going on between client and server. We want to do packet capture and analyses the packet going back and forth. What if we connected to Sniffer to the switch?

                              And we turned on packet sniffing software like “Wireshark”, and we trying to sniff the packet going back and forth between client and server. Unfortunately it is not gonna work is it because the switch is doing his job of only forwarding frames where they need to go  and according to mac address table inside the switch those frames do not need to go down to our sniffer.

                         Fortunately cisco give us feature called “SPAN (Switched Port Analyzer)” 

With span enable we can tell the switch port that we want to make a copy of traffic going out or coming into switchport. We waana make a copy of that traffic, and then send that copy out of this, other port this SPAN destination port, That’s were we doing here. Server is sending traffic and, we monitoring the port to which the client is connected. We are saying we want to get copy of traffic going out or coming into that port to which the client is connected, and we want to send that copy down to our sniffer

                                    In addition to doing that, there is another option, were we can monitor a vlan. We can see traffic appearing on all ports of vlan, and send all of that traffic out of our sniffer, that’s the basic theory of How SPAN Function work

Setting up Local SPAN

We have a client and server attached to Switch Sw1, and they sending information back and forth between themselves. However our “sniffer” (The Laptop running network analyzer software) is on Switch Sw2. How we had a copy of that traffic over Sw2?

                                               

                                   Cisco gives us solution is called RSPAN (Remote Switched Port Analyzer). If we have a trunk between these two switches. In this case one on the vlans that we want to carry across that trunk between our switches, is a vlan that carrying this SPAN information.

                                          Here we setup a span session on each switch. On switch SW1 we can say that the span source, is port to which the client is attached, and span destination is a vlan, specifically we gonna called a remote vlan, and when we send a copy of traffic appearing on the clients port over to this vlan, that vlan traffic goes across the trunk and appearing on Switch SW2, then on Switch SW2, we setup span session there , and we say that the source of span session is this remote vlan, and the destination is the port attached to the sniffer, in once we do that. Now traffic appearing on the clients port is gonna be copied and sent to this vlan , that we designated as a remote vlan, and we just gonna flow over the trunk, it’s going to appear on SW2, where we have another span session that says traffic appearing on this remote vlan send copy out this port attached to a sniffer.

Setup:-

Click Here To Download The PDF File

Read More