Miftah Rahman (Go)-Blog

Part 1 and Part 2

Let’s learn about another BGP Features like:

• Local-AS
• Next-Hop-Self
• Backdoor
• Multihoming (Load-Sharing)
• eBGP Multi-Hop

======================================

BGP Local-AS

Typically, this feature comes up when ISP A acquisitioning ISP B, but ISP C (or customers from ISP B) doesn’t want to change BGP Peering (change AS again, change neighbor, and so on)

Figure 1. initial network diagram

Figure 2. after acquisition form ISP A

Figure 3. initial BGP network from ISP C point of view

And then…ISP A bought ISP B, therefore all router in ISP B changed into AS 100 (ISP A)…but ISP C doesn’t want to change anything in their routers (too complicated they say…wkwkw)

So…let’s configure like this

Figure 4. local as configuration

ISP B Router says “I am AS 100 now, but…You (ISP C) can still recognize me as AS 200”

Let’s see in ISP C

Figure 5. ISP C still recognize ISP B AS 200

See…no problem at all, ISP C still thinks that ISP B is AS 200 (even though ISP A Bought it and change that ISP B AS into AS 100)

If, somehow, somebody with directly above your position as engineer say…”remove those AS 200 from the AS-Path, we don’t need it anymore”

Use this at ISP B… neighbor [ip neighbor] local-as [AS] no-prepend

The result is…for example 2.2.1.0 is via AS 100 only

But if you want to change the AS Path from 100 to 200 only, just add “replace-as” beside no-prepend keyword

neighbor [ip neighbor] local-as [AS] no-prepend replace-as

=========================================================

BGP Next-Hop-Self

Figure 6. Example topology

One of the BGP rules is “the next hop is always the IP address of the neighbor specified in the neighbor command”

R2 learns 1.1.1.1 via R1 through e-BGP, so next-hop to route to 1.1.1.1 in the R2 perspectives is through 12.12.12.1 (fa0/0 R1)

But when R2 advertise the 1.1.1.1 route to R3, R3 learns that next-hop to 1.1.1.1 is through 12.12.12.1 too (which is incorrect, it should be through 23.23.23.2 fa0/0 R2)

Figure 7. from R3

This is where BGP Next-Hop-Self is useful

We told R2 that he must advertise all route he learn, to neighbor 23.23.23.3 (which is R3) with next-hop directed to himself (R2)

Figure 8. change in R3

Another mention is when configuring BGP in multi-access network such as Ethernet

In topology above, R3 advertise 4.4.4.4 from R4 (let’s say acquired via OSPF) to R1

But, instead of advertising 134.134.134.3 (fa0/0 R3) next-hop to R2, R1 advertise next-hop to 4.4.4.4 is via 134.134.134.4 (fa0/0 R4)

Why ? because it make sense that R1,R3, and R4 is in the same network, same directly connected network, therefore R1 choose to most specific one to route

===========================================================

BGP Backdoor

The case is like this, both R1 and R2 run e-BGP to R3, but somehow R1 and R2 run IGP (like OSPF for example)

When R1 want to send packet to 2.2.2.2 (R2), he learn 2 paths

• Via R2, which is OSPF, with AD 110
• Via R3, which is BGP, with AD 20 (e-BGP)

The logic is…R1 sent packet via R3…but we don’t want to happen like this way

The solutions are 2 ways:

• Edit Administrative Distance, which is not recommended
• Run BGP Backdoor

The initial configuration are like this:

The result of those configurations is

R1 will sent packet to 2.2.2.2 via BGP not directly to R2 because AD difference

Now…lets configure the backdoor command

This means…for network 2.2.2.2..ignore the BGP AD, use the IGP AD

Result:

==================================================

BGP Multihoming

Right now we discuss about Multihoming with different AS (configuring multihoming with same AS is not much difference because common e-BGP configuration)

And also Load-sharing it (BGP can’t perform load balancing but it can perform load sharing)

Load sharing
is the ability to split the load (split packet) toward the same destination (host or IP) over multiple paths.

Load balancing
is the ability to distribute incoming/outgoing traffic over multiple paths

(thanks for correction, from Gangga Prima Yousya)

Configure all routers to e-BGP first…don’t forget to advertise 1.1.1.1 on R1 and 4.4.4.4 on R4

Example configuration on R1:

Maximum-path keyword is for load sharing

The result on R1 should be like this

Let’s ping and trace it…

Now we see…even though there are 2 path, R1 BGP only choose the first established one

How can we load-sharing it?!? Here’s the configuration example

Now it can perform Load Sharing

But here is the case I found, if the AS Path taken difference is too far between AS…the traffic load will cause some problem

Let’s see the example

Those configurations is just to simulate congestion that caused by longer AS Path the packet travels

The traffic share is still 1:1, this will cause problem with the packet that take longer path/bandwidth

So let’s configure dmzlink (for load sharing based on bandwidth)

Now the share is 1:10..1 traffic goes to R2 (bandwidth 10000) and 10 traffic goes to R3

Let’s take a look on Router CEF

======================================================

eBGP Multihop

eBGP multihop typically used when, somehow, a Router can’t form eBGP peering by connecting directly

so how we configure then?…look at this topology below

why we perform static routing? because initially, eBGP peers must connect directly right?

so…they perform peering via directly connected route in their routing table

that cause us to perform static routing (or via IGP) to make the BGP packet can travel to the other peer…

just look at above configuration…i’m not even touching R2 (except for ip addressing though…)

the keyword is ebgp-multihop

default “hop” for BGP packet is 1…that means BGP packet TTL (time to live) is only travel to directly connected router only

but if we use multihopping, lets say 2…after 1 hop (to directly connected router), that BGP packet have life to travel “one more time”

therefore, BGP packet from R1 (or R3) can reach each other

if we use ebgp-multihop without mentioning the ttl value…default value is 255 (that BGP packet can hop 255 times)

lets verify…