One of the most common issues we have seen when onboarding customers to our DDoS Protection for Networks service is when a customer’s ISP implements a high local preference. This prevents the Internet from recognizing that Imperva is the best path.
Local Preference
Local preference is one of the highest tiebreakers in the BGP (Border Gateway Protocol) best path selection algorithm. The idea for the ISP set local preference is to send traffic directly to the customer as quickly as possible and also to prevent possible misconfiguration in policy that might lead to an increase in latency. There might also be a preference for one ASN over the other due to peering agreements. One example would be when an ISP would prefer using a free peering link vs. a paid peering link to route traffic. This is one of the biggest challenges for our customers, as the configuration is neither controlled by Imperva nor by customers themselves, and the ISP might or might not be willing to adjust their routing policy for our customers.
One important note about local preference is that it is local within the ISP autonomous system(AS) and will not carry over to external AS. The local preference settings are generally being set at the import policy and carry over within the ISP network. One ASN cannot change how another ASN handles the traffic. If an ISP has a higher local preference set toward the customer than the route learned from Imperva, Imperva cannot change how an ISP is learning that route. More detail follows in the example below.
Examples
Let’s take a look at an example of what would happen if ISP1 set a local pref toward the customer – this is commonly done by the ISP to make sure the customer route isn’t leaked to another transit ASN. We will use similar topology as the AS prepend example, but this time, the customer would only have a single connection to ISP1 (AS701).
- GRE tunnel is established between Customer (AS1) and Imperva (AS19551).
- ISP1 would set local pref for customer import policy at 300.
- ISP3 would set local pref to ISP1 with local pref of 200. Assuming this is the cheaper/ more preferred link. Sometimes ISPs would do this with their peering link as there are paid vs. free peering links, so they would put local pref on the cheaper link to direct more traffic that way.
- A customer would advertise 123.1.1.0/24 to both Imperva without prepend and to ISP1 with 4x prepend.
Let’s take a look at each ISP and see their routing table:
ISP1:
ISP1 shows that the most preferred path is coming directly from the customer with a local pref of 300. It has been selected as the best path even though the AS path is longer with AS prepend applied.
ISP2:
ISP2 selects Imperva as the best path, since local pref are all equal at 100. It will use the shortest AS path, which is routing through Imperva (AS19551).
ISP3:
ISP3 is not taking Imperva as the best path either. This is due to ISP3 having a more preferred path from ISP1 with local pref of 200 vs. local pref of 100 from ISP2. ISP1 is saying the path directly from the customer is more preferable; therefore, the ISP3 is also thinking they should go through ISP1 and get to the customer, so they will not be protected by Imperva either.
So What’s the Next Step?
At this point, what options does the customer have in order to advertise their protected prefix to Imperva as the best path? The first and more obvious option is for the customer to contact their ISP (in this case ISP1) and have them equalize or lower the local pref of the WAN interface of their connection. By doing so, local pref is no longer a factor and AS path will be the tie-breaker for the best path algorithm, and we have shown that as long as the customer does AS prepending towards ISP1, it should elect Imperva as the best path.
However, sometimes these local pref settings are standard policy for ISPs and they might not want to change the policy for each customer on a case-to-case basis. Therefore, larger ISPs will sometimes use a tool called BGP communities to let customers adjust routes without changing import policy on the ISP side. These communities must be predefined by the ISP already, so customers must have an understanding of the communities’ attributes before applying them to their network.
Let’s go back to take a look using the same example, but this time where ISP1 has implemented a community member of 100:90 to allow the customer to adjust the local pref to 90 if they receive a community string. Without the community, by default, ISP1 is still putting a local pref of 300 coming from the customer.
Let’s take a look at the customer’s advertised route to make sure they are sending a 100:90 community string to ISP1.
Customer:
Now let’s take a look at ISP1, where we should expect to see the 100:90 community coming in.
ISP1:
We should expect that the route with prepend now has a local pref of 90 instead of 300 like we saw earlier:
As expected, Imperva (AS19551) is now the best path. Lastly, let’s take a look at ISP3, where we did not change any configuration.
ISP3:
ISP3 is still preferring ISP1 over ISP2 due to its local preference setting of 200; however, we can see now that Imperva is now in the path and will therefore be protected in case of DDoS attack.
Notice Imperva (AS19551) has not done nor can do anything to change the routing of the ISPs. All the traffic adjustments are done either by the customer or by the ISP and this is certainly the case in real life as well. However, we are well-versed in the methods our customers can use In order for us to best protect them. We can help to find a way to advertise their protected range(s) to Imperva (AS19551) as the best path and can talk through this during onboarding to our service. This is a very common challenge that customers face when trying to onboard DDoS protection for networks. Imperva’s onboarding team will work to help customers identify and walk through the necessary steps to get this issue resolved so their network will be protected from attacks.
Try Imperva for Free
Protect your business for 30 days on Imperva.
