Question : Is there always a feasible successor in EIGRP ?
I’m not the only person pointing out the software routers are reaching unprecedented performance levels.
Manav breaks down the OSPF vulnerability from Black Hat 2013 and confirms that it practical and viable failure of the OSPF protocol. So it was with certain skepticism that i started looking at yet another OSPF vulnerability exposed by Gabi, again at Black Hat. Its only when i started delving deep into the attack vector […]
I’ve been revising some EIGRP and it seems that a lot of what I used to know, I don’t know. Or maybe I didn’t know it the first time. Here, I’m just fiddling with EIGRP and the auto-summary command.
Wherein I make the case OpenFlow like technologies are neither switching or routing. It’s Flow Forwarding, or just Forwarding.
I got asked a question by a reader “is OpenFlow used for Routing or Switching ?”
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?
Wherein I consider using BFD in Network Designs.
Whilst at Cisco Live recently I was intrigued to learn about an apparently simple yet effective fast routing convergence technique called Loop-Free Alternate Fast ReRoute (LFA-FRR), a.k.a. IP Fast ReRoute (IP-FRR).
Many service providers and enterprises these days tune their interior gateway protocol (IGP) timers, aiming to achieve sub-200ms convergence. This can be quite an intensive and design impacting challenge.