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…
Miftah Rahman (Go)-Blog 