Ericsson Is the Latest to Join Intel Network Builders
Intel Network Builders gets a big-name boost.
The Ultimate SDN Forum: The 2015 Open Networking Summit
The promise of SDN, problems encountered by developers in the industry, and many more topics will be discussed at the 2015 Open Networking Summit.
iBGP Fall-over Trick
BGP fall-over is a neat BGP convergence optimisation technique whereby BGP peering is brought down as soon as the route to neighbor disappears from a routing table.
The difference between external and internal BGP is that the former usually peers over a directly-attached interface so that when the interface to neighbor is disconnected,
route is withdrawn from the routing table which triggers eBGP fall-over to bring down the neighborship.
iBGP, on the other hand, normally uses device loopbacks to establish peering sessions. What this means is if a summary or a default route is present in the routing table (either static or learned
via IGP), there is always a route to iBGP neighbor. In this case BGP has to wait for default 180 seconds (3 x keepalive timer) to bring down the neighborship and withdraw all the routes learned from dead neighbor.
To overcome that there’s a route-map option for a neighbor fall-over command which allows user to specify the exact prefix for which to look in the routing table. In the example below, the router will
look for specific host routes representing neighbor’s loopbacks and will trigger reconvergence as soon as those routes disappear.
Rethinking Centralization
In general, my line of thinking here is this: some things work well when they’re distributed, others work well when they’re centralized. Our bodies have a “central nervous system,” which is tied to a single point of failure (the brain), though our brains turn out to have some redundancy. On the other hand, other systems in our bodies are distributed, such as our reaction to being cut (and bleeding to death). What we need to start doing is thinking through what works well where, and figuring out how to move each one to that specific destination.
Another parallel in this space is what we’re facing now in application development. We like to say that we’re moving towards the cloud — which means thin clients and thick servers. The reality is, though, services are being broken down into microservices and distributed, and a lot of the processing that takes place does so on the client side by code pushed there from the server. In other words, our belief that the cloud “centralizes everything” is an oversimplification.
Taking one step back, we can always build centralized systems that scale to today’s requirements — the challenge is that we don’t know what tomorrow’s Continue reading
Structured Approach to Troubleshooting of L3VPN Networks
With the amount of configuration involved in a typical L3VPN configuration, troubleshooting process can get pretty chaotic, especially in a time-constrained environments like CCIE lab. That’s why it is extremely important to have a well-structured approach to quickly narrow down the potential problem area. I used the below algorithm while preparing for my lab exam. Like most of the networking problems, troubleshooting of L3VPNs can and must be split into two different phases - control plane and data plane. All steps must be done sequentially with each next step relying on the successful verification of all previous steps.
- Problem definition
- CE-1 (10.0.0.1) can not reach CE-2 (10.0.0.2)
vArmour Releases Free Visibility Tool for Data Center Security
Visibility is the first step toward data center security, vArmour reasons.