NetworkTalk & BGP

B.1.a) Choice of BGP tools and practices for return traffic: as-path prepend, LocalPreference or BGP communities?

B.1.a) Choice of BGP tools and practices for return traffic: as-path prepend, LocalPreference or BGP communities?

1. It is very regular for a customer ISP to be connected to several ISPs, and by so, desires to have the return traffic for a particular zone of customers, arriving specifically through a link as active (primary ISP) and the other one as passive (because capacity is lower or used for others networks pools).

When connections to multiple providers are required, it is important that BGP selects the optimal route for traffic to use. Still, the optimum/best route may not be what the network designer intended to base on design criteria, administrative policies, or corporate mandate. Commonly, return traffic enters the customer’s AS by using the shortest as-path as its selection criterion. This of course, does not arrange the network designer’s aims, and so bring him to modify his Ebgp structure.

2. In order to control return traffic, three main ideas will come in mind:

a. The customer can ask to the backup ISP to change its routing policy. The change should cause the backup ISP to prefer reaching the customer’s AS via the AS or network of the primary ISP (through local preference or med manipulations).
The backup ISP must implement this change in its own AS. However, the backup ISP might be reluctant to change the configuration for a single customer. Within Tier1 and Tier2 ISPs, network administrators are most likely busy of doing other tasks than tailoring router configurations that are based on the demand of a customer.

b. Then comes the case for the customer to use another BGP feature: the as-path prepending tool which allows influencing the selection of the primary ISP. We can manipulate as-paths by prepending as-number to existing as-paths. Normally, we can perform as-path prepending on outgoing Ebgp updates through the non-desired return path.
Since the as-paths sent out over the non-desired link, become longer than the as-path directed to the preferred path, the non-desired link is now less likely to be used as the return path.

c. Last choice is the use of communities, which allow the customer to manipulate the LocalPref about their advertised networks inside the ISP’s network (paragraph A.2.c).

3. We agree that the first solution is unsuitable. So we will hesitate between as-path and communities uses. However, the choice of using as-path prepend tool will not work in this practical example of ISP-A, because of the way on how ISP-B, ISP-C and ISP-D exchange their traffic among them.

We remember that BGP route selection uses the following selection criteria:

i. Prefer the higher-value weight.

ii. Prefer the higher-value local preference.

iii. Prefer routes that the router originated.

iv. Prefer shorter length of AS paths.

v. Etc.

If within the ISP, both weights and the local preference parameters are left at their default settings, the configuration causes the route selection process to continue down the list of selection criteria. Normally, the 4th criterion will apply; because the as-paths have different lengths (the 3rd criterion for selection will not influence route selection in this scenario, because none of the routes originated at the router which is performing the route selection.)

Nevertheless, the fact is that the local-preference parameter is changed within our upstream providers. As we notice for ISP-B, ISP-C and ISP-D, local-preference value is lower for peer partner (86, 90 and 85 respectively) and for the customers is set up to 100 by default.

That means that if ISP-A prepends the as-path for a pool of network, the manipulation will be useless. Traffic return path will depend first about the local-preference value within the ISP and its origin (LocalPref is set to 100).

To clarify the subtlety, let’s give a look to the following illustration:

• Prefix-B belongs to ISP-A’s as-number. ISP-A as a customer, desires for prefix-B’s end-users to have their return traffic flows exclusively through ISP-B. It announces the prefix-B 11.11.233.0/24:

i. to ISP-B and tags with nothing (meaning LocalPref for prefix-B within ISP-B’s network has been set to 100, the default value)

ii. and to ISP-D by prepending the as-path.

See below Figure B.1: Return traffic for prefix-B 11.11.233.0/24, tagged to ISP-B 300:100 and prepended to ISP-D 5 times.

 

• We can prefigure that return traffic for the prefix-B 11.11.233.0/24, will come back through ISP-B but also over ISP-D (but not exclusively through ISP-B), because:

i. Within ISP-B’s network, prefix-B will be present through two BGP routes (at least) :

• 11.11.233.0/24

(a) as-path: 300 1000 with LocalPref 100

(b) as-path: 300 500 1000 1000 1000 1000 1000 with LocalPref 86

• Since LocalPreference has priority on as-path length, packets will be sent to route (a) which is the best, directly to ISP-A.

ii. Within ISP-D’s network, prefix-B will be present through two Ebgp routes (at least) :

• 11.11.233.0/24

(a) as-path : 500 1000 1000 1000 1000 1000 with LocalPref 100

(b) as-path : 500 300 1000 with LocalPref 85

• LocalPreference has priority on as-path length. Packets will then be sent to route (a), directly to ISP-A, even if here the as-path is longer.

4. The solution in order to make the ingress traffic for prefix-B to return exclusively across ISP-B, is to announce the prefix-B to ISP-B with a community value 300:100 and to ISP-D with a community value 500:80. This will make us come back in the same situation described in paragraph A.2.c.
Clearly we need to use BGP communities allowing local-preference manipulations within the ISP, instead of as-prepend tools.
However, again, we repeat that the communities are not limited to local-preference manipulations; regarding many other features can be proposed by your ISP to control your inbound and also outbound traffic.

See below Figure B.2:  Return traffic path for prefix-B 11.11.233.0/24 when community values are set to 300:100 and 500:80

 

5. Summary (see also on Internet RFC1998):

Plz click on the illustration below, you will find another view of the interaction bettween ISPs thta happens ofthen.

See below Figure B.3: control of ingress/download traffic: ask its ISP to change its routing policies (localpref)
See below Figure B.4: control of ingress/download traffic tools: use of as-prepend tool?
See below Figure B.5: control of ingress/download traffic tools: change LocalPref through bgp community uses?

top

Come back to Tutorial Index”

Advertisements