Customer to ISP Static Routing

March 16, 2008 Leave a comment


OVERVIEW 

Generally Load sharing for both outgoing and incoming traffic is difficult to realize because this require that the direct-customer ISP change some routing policies inside the AS to provide a relatively good load sharing and if the ISP doesn’t provide such service level it will be very difficult to make them change their routing policy for your company.

The topology (picture1) realized in this lab include a customer network, its direct ISP autonomous system and an upstream autonomous system.

Picture1: topology

PLANNING

Routing policy:
The routing policies represented in table1 will be used even if we do not need to deploy all of those service levels.

Table1: ISP routing policies

Advertise Customer Routes

Backup link

QoS type 

Route tag 

Community values 

Local preference

Weight

(local significance)
NO (PA addresses)  YES Gold  1001 55003:31001 no-export 50 0
*NO (PA addresses)  YES Normal  1002 55003:31001 no-export 50 0
NO (PA addresses)  NO Gold 1003 55003:31001 no-export 100 (default) 32768(default)
*NO (PA addresses) NO Normal  1004 55003:31001 no-export 100 (default) 32768(default
YES (PI addresses)  No Gold 2001 55003:31002 100 (default) 32768(default
YES (PI addresses)  No Normal 2002 55003:31002 100 (default) 32768(default
YES (PI addresses)  YES Gold 2003 55003:31002 50 0
YES (PI addresses)  YES Normal 2004 55003:31002 50 0

* corresponds to our customer

Address scheme:

Picture2: address scheme

Picture 2 depicts the address scheme deployed in this Lab.

– The address block 10.10.0.0/16 is assigned to ASN55003 with the following subnetting:

  • 10.10.20.128/27 advertised by BGP.
  • 10.10.254.200/30, 10.10.21.204/30, 10.10.20.208/30 for point-to-point interconnections.
  • 10.10.253.2/32, 10.10.253.3/32, 10.10.253.4/32 and 10.10.253.5/32 respectively for R2, R3, R4 and R5 BGP ID.

– ASN55002 (upstream ISP) is assigned 20.20.0.0/16 with 20.20.20.64/27 advertised through BGP.

– The customer network assigned 10.10.10.0/24 subnetted into:

  • 10.10.10.196/30, 10.10.10.200/30 and 10.10.10.204/30 for point-to-point interconnections.
  • 10.10.10.204/30 and 10.10.10.208/30 for both links to the direct ISP AS 55003.
  • 10.10.10.128/27 advertised by BGP.

ANALYSIS 

This method doesn’t differ a lot from the one inspected for customer-to-ISP static routing with primary and backup links, except that in our case there is no need for floating static.

The tag assigned to the static route corresponds to a service level without QoS, no backup and not exported as depicted in the table1.

On R5:

router bgp 55003
…
redistribute static route-map STATIC_TO_iBGP
…
ip route 10.10.10.0 255.255.255.0 Serial1/0 tag 1004

on R4:

router bgp 55003
…
redistribute static route-map STATIC_TO_iBGP
…
ip route 10.10.10.0 255.255.255.0 Serial1/0 tag 1004

With equally defined and propagated default static routes on both customer-edge routers R6 and R8 the customer network can consider a certain load sharing that will still depend on the local metric of route, load sharing is much more easier with IGP such as OSPF or EIGRP.

The following is the route-map used in both provider edge routers that face the customer networks.

route-map STATIC_TO_iBGP permit 10
match tag 1001
set community no-export 55003:31001
set local-preference 50
set weight 0
route-map STATIC_TO_iBGP permit 15
match tag 1002
set community no-export 55003:31001
set local-preference 50
set weight 0
route-map STATIC_TO_iBGP permit 20
match tag 1003
set community no-export 55003:31001
route-map STATIC_TO_iBGP permit 25
match tag 1004
set community no-export 55003:31001
route-map STATIC_TO_iBGP permit 30
match tag 2001
set community 55003:31002
route-map STATIC_TO_iBGP permit 35
match tag 2002
set community 55003:31002
route-map STATIC_TO_iBGP permit 40
match tag 2003
set community 55003:31002
set local-preference 50
set weight 0
route-map STATIC_TO_iBGP permit 45
match tag 2004
set community 55003:31002
set local-preference 50
set weight 0

According to the configuration so far, there is no preference for one link over the other nevertheless this is not enough because outgoing/incoming load sharing will depend on the topology.

The closest device to a customer edge will use this one rather than the other edge router (picture3), of course for load sharing it’s ideal to have all internal routers, that in the common segment, on equal distance from edge routers but it’s not always the case.

Picture3: Customer topology

EIGRP provide load sharing feature between many unequal paths, this is very useful with non-symmetric customer topology.

Let’s test out topology with a trace route from R7 to R1 back and forth:

R7#trace
Protocol [ip]:
Target IP address: 20.20.20.65
Source address: 10.10.10.129
<default parameters omitted>
Tracing the route to 20.20.20.65
1 10.10.10.197 28 msec 60 msec 40 msec
2 10.10.10.205 168 msec 44 msec 96 msec
3 10.10.254.209 120 msec 200 msec 212 msec
4 10.10.254.213 220 msec * 324 msec
R7#

The outgoing traffic pass through R7àR6àR5àR2àR1

R1#trace
*Mar 1 00:47:42.691: %SYS-5-CONFIG_I: Configured from console by ajn on console
Protocol [ip]:
Target IP address: 10.10.10.129
Source address: 20.20.20.65
<default parameters omitted>
Tracing the route to 10.10.10.129
1 10.10.254.214 212 msec 68 msec 72 msec
2 10.10.254.210 260 msec 212 msec 216 msec
3 10.10.10.206 [AS 55003] 188 msec 260 msec 212 msec
4 10.10.10.198 [AS 55003] 332 msec 380 msec 288 msec
R1#

And traffic back take the path through R1àR2àR5àR6àR7

The result “no load sharing”! The result is expected first because the customer network is not symmetric to both edge routers and because OSPF is used in which even if injected default routes are E2 types (only external cost, not internal) R7 will take the shortest path to reach one of the two ASBR.

Later in this lab we will deploy EIGRP in the customer network and see what is the effect on load sharing, for now let’s focus on load sharing the traffic back through the ISP.

Indeed, there is two method to implement load sharing in the ISP service providers:

– for IOS >= 12.2, possible iBGP multipath load sharing.

– implement special policy to advertise customer network depending on the topology of the latter.

Indeed, there is two method to implement load sharing in the ISP service providers:

– for IOS >= 12.2, possible iBGP multipath load sharing.

– implement special policy to advertise customer network depending on the topology of the latter.

Method 1:

The algorithm, depicted in picture4, used by BGB select one best path because the last criterion is BGP router ID which is always unique.

To implement iBGP multipath load sharing the following criteria are required:

==> ALL ATTRIBUTES MUST BE THE SAME BETWEEN ALL MULTI-PATHS (weight, local-preference, AS-PATH, ORIGIN, MED and IGP cost).
– AS-PATH attributes should be equal in length and value.
– IGP costs to next hop must be equal.
==> ALL MULTIPATHS MUST HAVE DIFFERENT “NEXT-HOP” ATTRIBUTES

So we have to slightly change out ISP topology to be compliant to the first criteria (picture5), Router R2 should be at the same distance to R5 and R4 for all attributes to be the same:

picture5:Modified ISP topology

Be careful a multipath reserve approximately 350 bytes so this is not recommended for low-end or full BGP routers. Also Route Reflectors disable load balancing and advertize only the best path.

The BGP command required to achieve iBGP load balancing is as follow:

R2(config)#router bgp 55003
R2(config-router)#maximum-paths ibgp 2

In occurrence a maximum of two multipath is configured.

Let’s inspect the behavior of the topology, R2 receive two paths for the prefix 10.10.10.0/24:

R2(config)#do sh ip bgp
BGP table version is 5, local router ID is 10.10.253.2
…
Network Next Hop Metric LocPrf Weight Path
* i10.10.10.0/24 10.10.253.4 0 100 0 ?
*>i 10.10.254.210 0 100 0 ?
*> 20.20.20.64/27 20.20.21.1 0 0 55002 i
R2(config)#

Still no load balancing!

Remember that all attributes and IGP costs to next-hops must be equals which is not the case here:

R2(config)#do sh ip route 10.10.253.4
Routing entry for 10.10.253.4/32
Known via “eigrp 2345”, distance 90, metric 409600, type internal
Redistributing via eigrp 2345
Last update from 10.10.254.218 on Ethernet0/3, 04:23:17 ago
Routing Descriptor Blocks:
* 10.10.254.218, from 10.10.254.218, 04:23:17 ago, via Ethernet0/3

Route metric is 409600, traffic share count is 1
Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
R2(config)#do sh ip route 10.10.254.210
Routing entry for 10.10.254.208/30
Known via “connected”, distance 0, metric 0 (connected, via interface)
Redistributing via eigrp 2345
Routing Descriptor Blocks:
* directly connected, via Ethernet0/1

Route metric is 0, traffic share count is 1

The difference in route metric between the two routes to NEXT-HOP attribute values makes the two paths not equals, this difference is due to the fact that neighbor relationship between R2 and R5 use the direct link ip addresses whereas R2-R4 use loopback interfaces.

Let’s change R2-R5 BGP neighbor:

On router R5:

no neighbor 10.10.254.209 remote-as 55003
neighbor 10.10.253.2 remote-as 55003
neighbor 10.10.253.2 update-source Loopback0

On router R2:

no neighbor 10.10.254.210 remote-as 55003
no neighbor 10.10.254.210 next-hop-self
neighbor 10.10.253.5 remote-as 55003
neighbor 10.10.253.5 update-source Loopback0
neighbor 10.10.253.5 next-hop-self
R2(config-router)#do sh ip bgp
BGP table version is 6, local router ID is 10.10.253.2
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
* i10.10.10.0/24 10.10.253.5 0 100 0 ?
*>i 10.10.253.4 0 100 0 ?
*> 20.20.20.64/27 20.20.21.1 0 0 55002 i
R2(config-router)#do sh ip route 10.10.253.5
Routing entry for 10.10.253.5/32
Known via “eigrp 2345”, distance 90, metric 409600, type internal
Redistributing via eigrp 2345
Last update from 10.10.254.210 on Ethernet0/1, 00:01:48 ago
Routing Descriptor Blocks:
* 10.10.254.210, from 10.10.254.210, 00:01:48 ago, via Ethernet0/1

Route metric is 409600, traffic share count is 1
Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
R2(config-router)#do sh ip route 10.10.253.4
Routing entry for 10.10.253.4/32
Known via “eigrp 2345”, distance 90, metric 409600, type internal
Redistributing via eigrp 2345
Last update from 10.10.254.218 on Ethernet0/3, 00:13:30 ago
Routing Descriptor Blocks:
* 10.10.254.218, from 10.10.254.218, 00:13:30 ago, via Ethernet0/3

Route metric is 409600, traffic share count is 1
Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
R2(config-router)#
R2(config-router)#do sh ip bgp 10.10.10.0
BGP routing table entry for 10.10.10.0/24, version 9
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Multipath: iBGP
Flag: 0x800
Advertised to update-groups:
1
Local

10.10.253.5 (metric 409600) from 10.10.253.5 (10.10.253.5)
Origin incomplete, metric 0, localpref 100, valid, internal, multipath
Local

10.10.253.4 (metric 409600) from 10.10.253.4 (10.10.253.4)
Origin incomplete, metric 0, localpref 100, valid, internal, multipath, best
R2(config-router)#
R2(config-router)#do sh ip route
…
C 192.10.104.0/24 is directly connected, Ethernet0/2
20.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
S 20.0.0.0/8 is directly connected, Serial1/0
B 20.20.20.64/27 [20/0] via 20.20.21.1, 05:02:08
10.0.0.0/8 is variably subnetted, 9 subnets, 3 masks
B 10.10.10.0/24 [200/0] via 10.10.253.5, 00:01:09
[200/0] via 10.10.253.4, 00:01:09
C 10.10.254.216/30 is directly connected, Ethernet0/3
C 10.10.254.212/30 is directly connected, Serial1/0
C 10.10.254.208/30 is directly connected, Ethernet0/1
C 10.10.254.204/30 is directly connected, Ethernet0/0
D 10.10.254.200/30 [90/307200] via 10.10.254.218, 00:27:49, Ethernet0/3
[90/307200] via 10.10.254.206, 00:27:49, Ethernet0/0
D 10.10.253.5/32 [90/409600] via 10.10.254.210, 00:18:30, Ethernet0/1
D 10.10.253.4/32 [90/409600] via 10.10.254.218, 00:27:58, Ethernet0/3
C 10.10.253.2/32 is directly connected, Loopback0
R2(config-router)#
R2#trace 10.10.10.129
Type escape sequence to abort.
Tracing the route to 10.10.10.129
<default parameters omitted>
1 10.10.254.210 16 msec
10.10.254.218 176 msec ——————à R4 (e1/0)
10.10.254.210 68 msec ——————à R5 (e0/0)
2 10.10.10.210 116 msec
10.10.10.206 236 msec ——————à R7 (s1/0)
10.10.10.210 212 msec ——————à R8 (s1/0)
3 10.10.10.198 212 msec
10.10.10.202 404 msec ——————à R9 (e0/0)
10.10.10.198 164 msec ——————à R7 (e0/0)
R2#

Now the traffic is balanced equally between the two paths R2==>R5==>R6 and R2==>R4==R8

Method 2:

The second method use a tricky way to provide load balancing but less straightforward than the first method.

A relatively good load balancing can be achieved depending on how the customer will separately advertize two parts of its network through the two links to the service provider.

For example let’s suppose that the customer will advertize 10.10.10.128/27 and 10.10.10.196/30 through the first link and 10.10.10.204/30 and 10.10.10.200/30 through the second link, and this will be implemented by the service provider through static routes.

In the same way, to guarantee redundancy, the entire customer block address 10.10.10.0/24 must be advertized through both links.

on R5:

ip route 10.10.10.0 255.255.255.0 Serial1/0 tag 1004
ip route 10.10.10.128 255.255.255.224 Serial1/0 tag 1004
ip route 10.10.10.196 255.255.255.252 Serial1/0 tag 1004

on R4:

ip route 10.10.10.0 255.255.255.0 Serial1/0 tag 1004
ip route 10.10.10.204 255.255.255.252 Serial1/0 tag 1004
ip route 10.10.10.200 255.255.255.252 Serial1/0 tag 1004

on R2:

R2(config-router)#do sh ip bgp
BGP table version is 33, local router ID is 10.10.253.2
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete
Network Next Hop Metric LocPrf Weight Path
* i10.10.10.0/24 10.10.253.5 0 100 0 ?
*>i 10.10.253.4 0 100 0 ?
*>i10.10.10.128/27 10.10.253.5 0 100 0 ?
*>i10.10.10.196/30 10.10.253.5 0 100 0 ?
*>i10.10.10.200/30 10.10.253.4 0 100 0 ?
*>i10.10.10.204/30 10.10.253.4 0 100 0 ?
*> 20.20.20.64/27 20.20.21.1 0 0 55002 i
R2(config-router)#

So the achieved load balancing is the result of a particular routing policy between the customer and the provider not the result of a special feature.

R1#trace
Protocol [ip]:
Target IP address: 10.10.10.129
Source address: 20.20.20.65
<default parameters omitted>
Tracing the route to 10.10.10.129
1 10.10.254.214 160 msec 292 msec 140 msec
2 10.10.254.210 308 msec 140 msec 144 msec —————-à R5
3 10.10.10.206 [AS 55003] 260 msec 308 msec 240 msec —————-à R6
4 10.10.10.198 [AS 55003] 284 msec * 388 msec —————-à R7
R1#trace
Protocol [ip]:
Target IP address: 10.10.10.206
Source address: 20.20.20.65
<default parameters omitted>
Tracing the route to 10.10.10.206
1 10.10.254.214 92 msec 116 msec 140 msec
2 10.10.254.218 188 msec 216 msec 212 msec —————-à R4
3 10.10.10.210 [AS 55003] 280 msec 308 msec 260 msec —————-à R8
4 10.10.10.202 [AS 55003] 380 msec 284 msec 404 msec —————-à R9
5 10.10.10.206 [AS 55003] 300 msec * 392 msec —————-à R7
R1#

Filed under BGP