NetworkTalk & BGP

C.1.e) Traffic Analysis 5: Scenario E: Zone-D-E ingress/download traffic, primary link is still cut however secondary link ISP-B is restored.

C.1.e) Traffic Analysis 5:Scenario E: Zone-D-E ingress/download traffic, primary link is still cut however secondary link ISP-B is restored.

1. The most interesting scenario which described the following events through this order:

(a) ISP-D is cut. Ingress traffic for ZONE-D-E is coming back though ISP-B.
 
(b) ISP-D is cut, and then ISP-B is down too. Ingress traffic for ZONE-D-E is coming back through ISP-C to ISP-A.

(c) ISP-D is still cut, but this time only ISP-B’s link is restored. Will ingress traffic for ZONE-D-E stream back through ISP-B again?

2. We will be tempted to say, “yes of course ISP-B”. After all, this is how we defined our traffic engineering requirements. ISP-B is the secondary backup link for Zone-D-E ingress traffic.

However, in reality, traffic for Zone-D-E is still coming back through ISP-C and not ISP-B.

3. As a quick reminder when ISP-D and ISP-B links are down, we have:

(a) within the bgp table of ISP-D Ebgp speaker, the prefix 11.11.229.0/24 is learned by two ways:

i. 11.11.229.0/24, localpref 85, as-path: 400 – 1000.
best
ii. 11.11.229.0/24, localpref 85, as-path: 300 – 400 – 1000.
rejected(as-path longer)

(b) Within the bgp table of ISP-B Ebgp speaker, the route for prefix 11.11.229.0/24 is learned by 2 ways :

i. 11.11.229.0/24, localpref 86, as-path: 500 – 400- 1000.
rejected(as-path longer)
ii. 11.11.229.0/24, localpref 86, as-path: 400 – 1000.
best(shortest as-path)

(c) Within the bgp table of ISP-C Ebgp speaker, the route for prefix 11.11.229.0/24 is learned by 3 ways :

i. 11.11.229.0/24, localpref 70, as-path: 1000.
best
ii. 11.11.229.0/24, localpref 90, as-path: 300 – 400 – 1000.
rejected(as-loop issue)
iii. 11.11.229.0/24, localpref 90, as-path: 500 – 400 – 1000.
rejected(as-loop issue)

4. Now when ISP-B link is restored, ISP-A will advertise again the prefix to ISP-B with community value 300:80. Within the BGP table of ISP-B Ebgp speaker, the route for prefix 11.11.229.0/24 is learned:

(a) by the older ways:

i. 11.11.229.0/24, localpref 86, as-path: 500 – 400- 1000.
rejected(as-path longer)
ii. 11.11.229.0/24, localpref 86, as-path: 400 – 1000.
best(higher localpref)

(b) through ISP-A directly:

i. 11.11.229.0/24, localpref 80, as-path: 1000.
rejected(localpref value is lower, cannot preempt the route learned from ISP-C)

In fact, the order of the cuts is important. Within ISP-B network, the route for prefix-C 11.11.229.0/24 from ISP-C is older and has a higher LocalPref value which is 86. The new route from ISP-A comes after the older route received by ISP-C, and is installed later in the BGP table of ISP-B with a LocalPref value of 80. This value cannot preempt the value of 86.

5. To conclude, theory of traffic engineering setup could differ from the reality. It is important to test the various scenarios which can behave differently from the theory. This could avoid surprises. Tests redundancy cuts are recommended with looking glass consultation too.

 Figure C.5: Return Traffic of prefix-C 11.11.229.0/24 (Zone-D-E) when its primary link ISP-D is still cut but secondary link from ISP-B is restored.

top

Come back to Tutorial Index”