Routing Protocols and Computation in Silicon

I got this question and I guess it may not be obvious to everyone so I’ll have a shot at answering it.

Technology advances in ASIC hardware have resulted in substantial improvements in switching performances of routers and switches. However, the routing processes are still dependent on CPU speeds. What are the existing limitations in router/switch models which prevent route computations from being performed in hardware?

EIGRP Goodbye Message

Found this in the Cisco IOS 15.1M manuals today

IP Routing: EIGRP Configuration Guide, Cisco IOS Release 15.1M&T

Goodbye Message

The goodbye message is a feature designed to improve EIGRP network convergence. The goodbye message is broadcast when an EIGRP routing process is shut down to inform adjacent peers about the impending topology change. This feature allows supporting EIGRP peers to synchronize and recalculate neighbor relationships more efficiently than would occur if the peers discovered the topology change after the hold timer expired.

PacketShaper and Flow Directions

I stumbled across an old diagram I made a long time ago about the direction of flows on a BlueCoat PacketShaper. Since I’ve been looking for it for about three years, I’ve diagrammed it quickly so that it is here for future reference when I’m working PacketWise in the future. PacketShaper PacketWise is one of my very favourite tools for managing traffic flows, and much preferable to PHB QoS aka DiffServ for many types of use cases.

An TCP flow has four possible directional attribute related to the use of a inside and outside networks, and whether the flow was initiated from the client to server which sets the “direction” of the flow relative to the Packeteer. The flow is determined by who initiated the three way handshake. For purposes here, the Client always initiates the TCP connection, and the Server terminates the connection.

TCP Session and Direction

Most people understand the three way handshake, but not many consider the direction of the session.
Packet shaper flow directions 0

The connection from the client to the server is outbound, but is inbound on the server. And vice versa, the server outbound session is inbound on the client.

Packet shaper flow directions 0 1
That’s not very useful for being able to define the direction of flows.

Why is direction important ?

Direction of flows is important if you want to configure asymmetric rules. That is, not all protocols require symmetic bandwidth. For example, HTTP traffic is usually a 10:1 ratio for reply to request. That is, a request for this webpage is about 10KB, but the reply with the data, images and javascript is more than 100KB.

Packet shaper flow directions 0 2

For an FTP upload server, you might have the reverse condition where the inbound traffic is far more than the outbound.

To make the most of your Internet connection for this case, you could configure the inbound bandwidth on your Internet connection to be 80% FTP, 20% HTTP and the outbound bandwidth to be 20% FTP and 80% HTTP. This gives a far better utilisation, especially in regards to better TCP Windowing and overall TCP goodput.

Why firewalls don’t have Telnet or SSH Clients

I found this on Cyber Corner blog:

Another missing ASA-feature: telnet and ssh client: ” Every single decent Cisco-device on earth has the ability to make an CLI-user jump to another device with telnet or ssh. Except the ASA. I really wish that this feature could be added. Right now I am troubleshooting a firewall and from where I am right now the only way in is to SSH to the ASA. I can do whatever I want inside the firewall from my SSH-window, but I need to access a router inside of that firewall, and if this feature wasn´t missing i could simply run ‘ssh ip-address’ to jump to the switch´s CLI.

Am I the last CLI-.guy on this planet? Please, Cisco?