What is the purpose of Route Origination/Route Advertisement?
- How is Route Origination different from Always Available Service?
- How can it be configured?
The Route Origination feature (RO), labeled Route Advertisement in the portal, gives Silverline the ability to advertise a customer's public prefix at the time of attack. This lets customers to have a standardized / static configuration on their routing equipment and to activate DDoS scrubbing services via Silverline when needed.
The Route Origination feature changes the way that "Always Available" configurations work. The key difference is that with the Route Origination feature configured, customers should ALWAYS advertise their public subnets to Silverline AND to their local carriers. The configuration of Route Origination places a filter within Silverline that prevents the customer's route advertisement from being broadcast through Silverline to the Internet. This allows the Route Origination feature to be used to advertise a customer's routes for DDoS scrubbing at time of attack.
Customers that wish to configure Route Origination should ensure the following:
- Customers should advertise their public subnets to their local carriers / ISPs
- Customers should advertise their public subnets to Silverline via the configured GRE & BGP configurations
Public Prefix Caveats:
The Route Origination feature creates some caveats to customer configurations and route advertisements to the Internet. What Route Origination is essentially doing is advertising a customer's prefix(es) from both Silverline while leaving the existing route advertisement from the customer to their ISP(s) in place. To make this solution effective, the route advertisement from Silverline should be preferred over the customer's advertisement to their carrier.
Summary Route Example:
If a customer has a summary route for their public address space (ex. 184.108.40.206/22), they should advertise this route to their ISPs all the time. The should also advertise this route to Silverline all the time.
When a customer comes under attack, they would notify the Silverline SOC of the specific prefix under attack and when the Silverline Route Origination feature is activated, only that specific /24 prefix (ex. 220.127.116.11/24) would be advertised. Because this prefix is more specific than the summary route advertised by the customer, it will be preferred globally and all traffic destined for it will go to Silverline.
IMPORTANT: The summary route advertised to Silverline is used to return traffic to the customer via the GRE tunnels. A check is done to determine whether the route is not in place as otherwise when the Route Origination feature is activated, Silverline will blackhole all the traffic for this specific, advertised prefix. Customer has the option to override this route check, which would be handy when their Internet pipe is full and their GRE tunnels and BGP peering with Silverline is down. Once the route advertisement is successful and the attack traffic is routed to Silverline, their GRE tunnels and BGP peers would be back up to receive clean traffic.
When Route advertisement is invoked over API, its customer's responsibility to make sure there is a route in place to deliver clean traffic to their network.
Non-Summary Route Example:
If a customer does not have a summary route and instead has a collection of /24 prefixes (ex. 18.104.22.168/24 and 22.214.171.124/24) the configuration becomes more complex and requires additional work by the customer.
The primary consideration for this configuration is that the /24 prefix advertised by the customer will be preferred (BGP Local-Pref) within their carrier and possibly any intermediate carriers between the customer's ISP and Silverline's transit providers. This means that when Silverline activates Route Origination for the customer's prefix, the prefix will have equivalent preference on the Internet and traffic will be split unevenly between going through Silverline and going direct to the customer.
This configuration can be solved through use of BGP communities between the customer and their ISPs. Most ISPs have a list of available BGP communities that can be used by customers to influence route prioritization for customer routes learned directly over the customer's ISP connection and through peering through to Silverline's carriers.
NOTE: It is the customer's responsibility to evaluate the correct BGP community configurations with their ISPs to create an effective configuration that will divert traffic to Silverline at the time of Route Origination activation.
NOTE: In working with customers and ISPs, the use of AS-path Pre-Pending to influence route preference is often ignored by ISPs when evaluating routes learned within their network against routes learned through their peering.
The risk of not solving this configuration is that the traffic steered through Silverline will be "best-effort" on the Internet and there will certainly be some portion of traffic that does go through Silverline, but no guarantees can be made that this will be enough of the traffic to mitigate the volumetric attack on the customer's infrastructure. For some customers this is sufficient; for others, the additional effort of ensuring accurate route advertisement at time of attack is critical.
If a customer is using routing preferences via BGP Communities, it is important to note that any changes to the BGP session while a prefix is originated will not take effect immediately. In order for BGP updates to take effect when a prefix is originated, it is necessary to withdraw and re-announce the prefix for changes to take effect.
For example, if a customer wants to stop advertisements from their side when a prefix has been originated via the Silverline Portal by sending the community "no-export" to the Silverline BGP neighbors, the BGP updates will not propagate until a withdrawal and re-announcement is made.
It is strongly recommended that the customer perform test activations of the Route Origination service in a maintenance window to validate that all configuration points are working as designed.