I2RS and Remote Triggered Black Holes
In our last post, we looked at how I2RS is useful for managing elephant flows on a data center fabric. In this post, I want to cover a use case for I2RS that is outside the data center, along the network edge—remote triggered black holes (RTBH). Rather than looking directly at the I2RS use case, however, it’s better to begin by looking at the process for creating, and triggering, RTBH using “plain” BGP. Assume we have the small network illustrated below—
In this network, we’d like to be able to trigger B and C to drop traffic sourced from 2001:db8:3e8:101::/64 inbound into our network (the cloudy part). To do this, we need a triggering router—we’ll use A—and some configuration on the two edge routers—B and C. We’ll assume B and C have up and running eBGP sessions to D and E, which are located in another AS. We’ll begin with the edge devices, as the configuration on these devices provides the setup for the trigger. On B and C, we must configure—
- Unicast RPF; loose mode is okay. With loose RPF enabled, any route sourced from an address that is pointing to a null destination in the routing table will Continue reading
The infamous Mirai was the likely culprit.
Swisscom will use OpenStack to develop its own cloud platform.
Service providers want reduced costs while the enterprise looks for flexibility.
These breaches are now affecting millions and sometimes hundreds of millions of people.
In the move to the telco cloud and NFV, there are a number of risks associated with implementing a fully virtualized system.
