This week we're checking in with Josh Drake of Zimperium. With exploitation of Stagefright via Josh's sweet, sweet exploit you'd think the mother of all worms is coming. Well, probably not. Later versions of Android are tricky to exploit, and the diversity of hardware in earlier versions means coming up with one exploit to rule them all isn't really feasible. We'll drill down into that with Josh in a little while.
IBM is open ... for business!
Competition from the cloud is pushing Ethernet service providers toward virtualization and automation.
It’s been five years since I started this blog! Time flies and a lot has happened since. Thanks for being along for the ride. What better way to celebrate than a blog post?
This post is going to be short and to the point.
Many of us run HSRP or VRRP. It is quite common to run it in a topology where you have dual routers and dual exits to the WAN and you don’t want to black hole your traffic.
One traditional way of achieving this is by tracking the interface that goes towards the WAN. There are a couple of drawbacks to this approach though:
The next option is to use IP SLA that sends ICMP Echo towards the next-hop of the WAN or some destination further into the network. Ehanced Object Tracking (EOT) can then be used to create a track object that decrements the priority of the HSRP active router when the ICMP Echo probe fails. This works better but there are still some drawbacks to this approach:
Security threats are evolving, so protection methods need to change, too. Register for the Skyport DemoFriday to learn how.
Be first to learn about security innovations in the protection of SDx Infrastructure: Data Centers and Cloud, Enterprise Campus and Branch and IoT
As I’ve written about previously (The Importance of BGP NEXT_HOP in L3VPNs), the BGP NEXT_HOP attribute is key to ensuring end to end connectivity in an MPLS L3VPN. In the other article, I examine the different forwarding behavior of the network based on which of the egress PE’s IP addresses is used as the NEXT_HOP. In this article I’ll look at the subnet mask that’s associated with the NEXT_HOP and the differences in forwarding behavior when the mask is configured to different values.
There is a lot of (mis-)information on the web stating that the PE’s loopback address — which, as I explain in the previous article, should always be used as the NEXT_HOP — must have a /32 mask. This is not exactly true. I think this is an example of some information that has been passed around incorrectly, and without proper context, and is now taken as a rule. I’ll explain more about this further on in the article.
Here’s the example network:
Note that R2 and R7 are the PEs and they each have a /24 mask on their loopback0 interfaces. The PEs are peering via their loopbacks. OSPF is running between R2, Continue reading