Showing posts with label bgp. Show all posts
Showing posts with label bgp. Show all posts

Friday, March 8, 2024

BGP Stream: An Analysis of One Year of BGP Incidents


By Alejandro Acosta, R&D Coordinator at LACNIC

LACNIC presents the first webpage designed to show incidents and an analysis of Border Gateway Protocol (BGP) measurement data in Latin America and the Caribbean.

MAIN INCIDENTS. In addition to a summary of the information, the page shows three main types of events: possible network hijacks, BGP outages, and route leaks.

Possible hijacks refers to the illegitimate takeover of groups of IP addresses by corrupting Internet routing tables. This typically occurs when an Autonomous System announces a prefix that it does not originate.

Outages refers to the loss of visibility of network prefixes by a majority group of sensors.

Route leaks, as the name suggests, refers to the —potentially— unintentional announcement of a network prefix via BGP. For example, in a private peering traffic exchange, when one of the participants announces the peer’s prefix to the Internet. This case is the most difficult for algorithms to detect, so some of these incidents are not identified.

How is the data obtained?

This initiative uses Cisco BGP Stream, an automated process that selects the largest and most important incidents, providing information on the nature of the event and the ASNs involved.

The information is openly published, as LACNIC believes that it is important for engineers, network administrators, and organizations to gain insights into the most common incidents in the region and raise awareness about the situation.

This allows quickly investigating events, the rapid development of complex prototypes and tools, as well as large-scale monitoring applications (e.g., detecting connectivity outages, attacks, or BGP hijacks).

Using a system developed by LACNIC’s R&D department, raw data is collected, plotted, identified, cleaned, stored in a database, and later used to produce statistics and graphs. This occurs automatically every 24 hours.

RESULTS. During the study period —February 2023 to February 2024— we found the results shown in the charts below, which compare BGP events worldwide vs BGP events in our region.

A comparison between the global chart and the chart specific to the LAC region shows a similar pattern in the order of the most common incidents, with outages being the most frequent type of incident, followed by possible hijacks, and finally prefix leaks. It should also be noted that outages represent a higher percentage of the total number of incidents in our region than at the global level.

An analysis of the results table showing worldwide BGP events vs BGP events in our region reveals the following:

TOP 5 countries in our region with the highest number of BGP outages


TOP 5 countries in our region with the highest number of possible Hijacks

Expected CCDetected CCEvents

TOP 3 countries in our region with the highest number of route leaks

Origin CCLeaker CCEvents


In this first year of operation, LACNIC has observed a reduction in BGP incidents. Several reasons for this have been identified, including a) the deployment and adoption of Resource Certification (RPKI), b) LACNIC’s Internet Routing Registry (IRR), and the adoption of RFC 9234 (Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages).

The adoption of these tools is being driven by better operator practices and ISOC’s promotion of MANRS.


Possible hijacks, outages, and route leaks are the most common types of BGP incidents. During the initial year of data collection, a decrease in the number of cases was observed. However, it is expected that they will not disappear entirely in the near future. Implementing robust redundancy and resiliency measures in networks is crucial, as is the early detection and prevention of possible hijacks to ensure the integrity and reliability of Internet routes.

At LACNIC, our goal is to raise awareness and encourage ISPs and organizations to be prepared to handle these incidents efficiently when they occur.


Thursday, February 1, 2024

A Much-Needed BGP RFC: AS Path Prepending


The Border Gateway Protocol (BGP) plays a critical role in building and maintaining Internet routing tables, so much so that it is considered the “glue” that holds the Internet together. In this context, a long-standing and very popular technique known as ‘AS Path Prepending’ has been devised as a key strategy for influencing route selection and optimizing an AS’s inbound and outbound traffic.

In this document, we will navigate through the IETF draft titled “AS Path Prepending” [1], which includes several ideas and concepts that are of great value to the community.

About draft-ietf-grow-as-path-prepending

This draft has been under discussion within the Global Routing Operation (GROW) Working Group since 2020 and is currently on version 10. The document has seven co-authors: M. McBride, D. Madory, J. Tantsura, R. Raszuk, H. Li., J. Heitz, and G. Mishra. It predominantly received support on the discussion list (including my own). You can read the draft here.

What is AS Path Prepending?

AS Path Prepending is a technique that involves repetitively adding one’s autonomous system identifier (ASN) to the list of ASs in a BGP route path (AS_PATH). Its goal is to influence route selection by making certain paths less attractive to inbound/outbound traffic. In other words, it consists of adding our autonomous system to the AS_PATH and therefore artificially “lengthening the path” to a prefix on the Internet.

In the figure above, without prepends, Router A prefers to go to C via B. However, when three prepends are added on B, router A decides to reach C via D.

Why is AS Path Prepending used and what is it used for?

AS Path prepending is used for multiple reasons. The main reason is undoubtedly traffic engineering, which in turn is used to influence an AS’s inbound and outbound traffic. It is very likely that the AS wishes to achieve one of the following goals:

  • to distribute traffic among two or more upstream providers, or
  • to have an upstream backup provider.
  • Whatever the case, the goal is traffic engineering.

To prepend or not to prepend, that is the question

Prepending is a bit like NAT in that it is often a necessary evil. As we will explain, its excessive and sometimes unnecessary use can become a vulnerability with significant implications for network stability.

What’s wrong with using AS Path Prepending?

We all know that AS Path Prepending is a very common technique to influence BGP decisions. However, its excessive, incorrect, and sometimes unnecessary use can have negative consequences. For example:

  • Creation of suboptimal traffic flows. In other words, we may achieve our goal of distributing traffic in the immediate links; however, beyond our immediate upstream, traffic is not optimized to reach our autonomous system and vice versa.
  • Prefix de-aggregation. When implementing traffic engineering, it is very common to de-aggregate prefixes, which affects the Internet ecosystem.
  • In the event of a route-leak, under normal circumstances, the as-path of our advertisements would be shorter than that of the leaked route. However, if we artificially lengthen the path by prepending, the as-path of the leaked routes may be shorter than those we are legitimately announcing for our legitimate prefix, which would have lower preference, leading to potential route hijacking, attacks, and a long etcetera.
  • Memory consumption. As expected, these AS Path Prepends are learned by BGP Speakers, thus increasing their memory usage. To this I would add that prepending introduces a small additional CPU usage penalty for each prefix.

Given that AS Path Prepend is no longer recommended, what alternatives are available?

There are many techniques for performing traffic engineering in BGP. I will mention some that appear in the draft:

  • Leveraging BGP communities. In addition to the well-known BGP communities, I recommend talking to your BGP peers to optimize traffic. There are numerous BGP communities implemented by providers, which might certainly benefit your setup.
  • Announcing more specific routes to your main upstreams.
  • Manipulating the AS Origin Code. Remember that this attribute is also found in the BGP route selection algorithms.
  • Using Multi Exit Discriminator (MED), a non-transitive attribute that can be used with excellent results for manipulating inbound traffic when we have several links to the same provider
  • Using Local-Preference, another non-transitive attribute, perfect for influencing the traffic that leaves our autonomous system

This is all well and good, but I still need to use AS Path Prepending. Any suggestions?

The draft mentions the best current practices when using AS Pat Prepending, which I will summarize below:

  1. Only use AS Path Prepending if it is absolutely necessary.
  2. Due to some traffic manipulation techniques, when using AS Path Prepending, we may not see significant changes in the traffic distribution, which is why it is important to talk to our peers to see if they will honor the prepends.
  3. Use local-preference on our network.
  4. Don’t prepend ASNs that you don’t own.
  5. Don’t prepend if you are connected to a single ISP using a single link, i.e., single homed (this one is not included in the draft).
  6. If we prepend a prefix, it might not be necessary to use that prepend for all our peers.
  7. There is no need to use more than five prepends. The reason for this is that more than 90% of path are five ASs or fewer in length.

Final Considerations

The use of AS Path Prepending is a valuable strategy but should be used only when necessary and with caution, following best practices. Excessive use of prepends may cause unforeseen events that may affect our autonomous system from a traffic and a security perspective.

We invite you to read the full draft (available here and to join the discussion on the LACNOG mailing list.

We also encourage you to comment on this post to let us know if you are prepending your ASN, as well as why and what you are using this for.



Tuesday, December 5, 2023

BGP: IPv6 Only example between OpenBGPD and FRR


show run

frr# sh run 

Building configuration...

Current configuration:


frr version 8.1

frr defaults traditional

hostname frr

log syslog informational

service integrated-vtysh-config


interface l0

 ipv6 address 2001:db8::1/128



router bgp 65001

 bgp router-id

 no bgp ebgp-requires-policy

 neighbor 2001:db8:12::2 remote-as 65002


 address-family ipv6 unicast

  redistribute connected

  neighbor 2001:db8:12::2 activate

  neighbor 2001:db8:12::2 soft-reconfiguration inbound





Archivo: /etc/bgpd.conf

# macros


fib-update yes

log updates

# global configuration



network 2001:db8::2/128

network inet6 connected

neighbor 2001:db8:12::1 {

    descr "epa"

    remote-as 65001

    announce IPv6 unicast


deny from any

deny to any

allow from 2001:db8:12::1

allow to 2001:db8:12::1


(please note the blank space between the last line and the second to last line)

Thursday, December 1, 2022

An Interesting Change Is Coming to BGP

A route leak is defined as the propagation of routing announcement(s) beyond their intended scope (RFC 7908). But why do route leaks occur? The reasons are varied and include errors (typos when entering a number), ignorance, lack of filters, social engineering, and others.

Although there are several ways to prevent route leaks and, in fact, their number has decreased over the past three years (thanks to RPKI, IRR, and other mechanisms), I will try to explain what I believe BGP configurations will look like in the future. To do so, I will talk about RFC 9234, Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages. And the part I would like to highlight is “role detection” as, after this RFC, in the future, we will assign roles in our BGP configurations.

To understand what we want to achieve, let’s recall some typical situations for an ISP: 

a new customer comes along with whom we will speak BGP,

a connection to an IXP,

the ISP buys capacity from a new upstream provider,

a new private peering agreement.

In all these cases decisions need to be made. There are multiple ways to configure BGP, including route maps, AS filters, prefix lists, communities, ACLS, and others. We may even be using more than one of these options.  

This is where RFC 9324 enters the picture: the document establishes the roles in the BGP OPEN message, i.e., it establishes an agreement of the relationship on each BGP session between autonomous systems. For example, let’s say that I am a router and I speak to another router and tell them that I am a “customer”; in turn, the other router’s BGP session can say “I am your provider.” Based on this exchange, all configurations (i.e., filters) will be automatic, which should help reduce route leaks.

These capabilities are then negotiated in the BGP OPEN message.

The RFC defines five roles:

Provider – sender is a transit provider to neighbor;

Customer – sender is a transit customer of neighbor;

RS – sender is a Route Server, usually at an Internet exchange point (IX);

RS-client – sender is client of an RS;

Peer – sender and neighbor are peers.

How are these roles configured?

If, for example, on a relationship in a BGP session between ASes, the local AS role is performed by the Provider, the remote AS role must be performed by the Customer and vice versa. Likewise, if the local AS role is performed by a Route Server (RS), the remote AS role must be performed by an RS-Client and vice versa. Local and remote AS roles can also be performed by two Peers (see table).

An example is included below.

BGP Capabilities

BGP capabilities are what the router advertises to its BGP peers to tell them which features it can support and, if possible, it will try to negotiate that capability with its neighbors. A BGP router determines the capabilities supported by its peer by examining the list of capabilities in the OPEN message. This is similar to a meeting between two multilingual individuals, one of whom speaks English, Spanish and Portuguese, while the other speaks French, Chinese and English. The common language between them is English, so they will communicate in that language. But they will not do so in French, as only one of them speaks this language. This is basically what has allowed BGP to grow so much with only a minor impact on our networks, as it incorporates these backward compatibility notions that work seamlessly.

This RFC has added a new capability.

Does this code work? Absolutely. Here’s an example in FRR:

Strict Mode

Capabilities are generally negotiated between the BGP speakers, and only the capabilities supported by both speakers are used. If the Strict Mode option is configured, the two routers must support this capability.

In conclusion, I believe the way described in RFC 9234 will be the future of BGP configuration worldwide, replacing and greatly improving route leaks and improper Internet advertisements. It will make BGP configuration easier and serve as a complement to RPKI and IRR for reducing route leaks and allowing for cleaner routing tables.

Click here to watch the full presentation offered during LACNIC 38 LACNOG 2022.

Monday, July 8, 2019

BGP: To filter or not to filter by prefix size. That is the question


In order to write these post the R+D team and the WARP team joint together after analyzing some security incidents related with BGP, network accessibility, network hijacks and network visibilities.

As you probably know, in the BGP world, there are dozen of ways to filter prefixes. The goal of this post is to show some recommendations in order to have a more stable network, keep the visibility of your prefixes as much as possible and of course reduce the calls to the NOC


Many ISPs around the world can not (or do not wish) to receive the full routing table (DFZ) which by the time of writing this text is about 750.000 prefixes (IPv4)

  • The above description could be due to some -not limited- of the following causes:
  • The routers does not have enough RAM to learn all the prefixes (please also note that there could be also several BGP session at the same time)
  • The network admin wants to save CPU cycles in their devices
  • The upstream providers is not announcing the full routing table
  • The network admin wishes to keep his network simple and easy

Anyhow, in the end of the story, the router is not learning the full routing table.


Not learning the full routing table can bring many partial inconveniences that in the end brings connectivity problems, users complaints, issues accessing some web sites and more.


Please try to imagine the following case

  1. I have a router (property of EXAMPLE) in Internet that is ONLY learning a partial DFZ
  2. The routers mentioned in “1” is only learning “big network”, over /20. I mean, the router learns /20, /19, /18, etc. (of course, we are talking about IPv4)
  3. Based in the configuration indicated in number “2”, the router is not going to learn prefixes such as /21, /22, /23 nor /24
  4. So far so good. However, somewhere in Internet, some people hijacked an /21 to the company ACME (hijack, bad configuration, whatever)
  5. ACME decides to perform more specific prefix advertisements, so, he takes his /21 and announces 8 /24 prefixes to the DFZ.
  6. Because of the filters configured by EXAMPLE, he will never learn the legitimate /24 prefixes advertised by ACME
  7. EXAMPLE will keep learning the hijacked /21 which obviously will bring connectivity problems aim to the legitimate owner of the network


The following diagram represents the hypothesis presented in the previous point in a graphic manner to facilitate its understanding.


The following recommendations only for networks that CAN NOT LEARN the full DFZ. One more time, they were found after studying many cases of connectivity problem and network hijacks.:

  • Do not filter more specific network,. We mean, it’s better to learn more specific networks such as: /24, /23, /22 (IPv4 world)
  • Filter using AS_PATH (like, 2,3 or 4 deep ASs)
  • Please create your ROS and use RPKI

Some examples (Cisco like)1. Learning only /22, /23 or /24:

router bgp 65002
  neighbor remote-as 65001
  neighbor route-map FILTRO-IN in
ip prefix-list SMALLNETWORKS seq 5 permit ge 22 le 24
route-map FILTRO-IN permit 10
  match ip address prefix-list SMALLNETWORKS

2. Only learning two AS beyond us:

router bgp 65001
  neighbor remote-as 65002
  neighbor route-map ASFILTER-IN in

ip as-path access-list 5 permit ^[0-9]+_$
ip as-path access-list 5 permit ^[0-9]+ [0-9]+_$
route-map ASFILTER-IN permit 10
  match as-path 5

More information

Prefix hijack demonstration 1 / 2 (in Spanish):

Prefix hijack demonstration 2/2 (in Spanish):

BGP Prefix-Based Outbound Route Filtering

Ejemplo de configuración de BGP con dos prestadores de servicio diferentes (conexiones múltiples)

Certificación de Recursos (RPKI)

Información General sobre Certificación de Recursos (RPKI)


Dario Gomez (

Alejandro Acosta (

Monday, February 29, 2016

Read a BGP live stream from CAIDA

  Read a BGP live stream from CAIDA and insert them into a BGP session

What do we need
  bgpreader from the bgpstream core package provided by Caida obtained in github

  We will read the BGP live stream feed using bgpreader, then the standard output of it will be redirected to a pipe file (mkfifo) where a perl script called bgpsimple will be reading this file. This very same script will established the BGP session against a BGP speaker and announce the prefixes received in the stream.

LAB Topology
  The configuration was already tested in Cisco & Quagga
  The BGP Speaker (Cisco/Quagga) has the IPv4 address
  The BGP Simple Linux box has the IP

How does it works?
  bgpreader has the ability to write his output in the -m format used by libbgpdump (by RIPENCC), this is the very same format bgpsimple uses as stdin. That's why myroutes is a PIPE file (created with mkfifo).



First install general some packages:
apt-get install apt-file libsqlite3-dev libsqlite3 libmysqlclient-dev libmysqlclient
apt-get install libcurl-dev libcurl  autoconf git libssl-dev
apt-get install build-essential zlib1g-dev libbz2-dev
apt-get install libtool git
apt-get install zlib1g-dev

Also intall wandio
git clone


cd wandio
./configure && ./make && ./make install

to test wandio:

Download bgp reader tarball from:

#ldconfig (before testing)

#mkfifo myroutes

to test bgpreader:
./bgpreader -p caida-bmp -w 1453912260 -m
(wait some seconds and then you will see something)

# git clone

Finally run everything
In two separate terminals (or any other way you would like to do it):

./bgpreader -p caida-bmp -w 1453912260 -m > /usr/src/bgpsimple/myroutes
./ -myas 65000 -myip -peerip -peeras 65000 -p myroutes

One more time, what will happen behind this?
bgpreader will read an online feed from a project called caida-bmp with starting timestamp 1453912260 (Jan 27 2016, 16:31) in "-m" format, It means a libbgpdump format (see references). The stardard output of all this will be send to the file /usr/src/bgpsimple/myroutes which is a "pipe file". At the same time, will create an iBGP session againts peer (a bgp speaker such as Quagga or Cisco). will read myroutes files and send what it seems in this file thru the iBGP Session.

Important information
- The BGP Session won't be established until there is something in the file myroutes
- eBGP multi-hop session are allowed
- You have to wait short time (few seconds) until bgpreaders start to actually see something and starts to announce to the BGP peer

References / More information:
-Part of the work was based on:

- Caida BGP Stream:

- bgpreader info:

- RIPE NCC libbgpdump:

- Introduction of "Named Pipes" (pipe files in Linux):

Thursday, February 21, 2013

Advertising IPv6 Routes Between IPv4 BGP Peers (Cisco)

I want to advertise IPv6 networks / prefixes over IPv4 eBGP session
Although not common, this case may occur in some situations. 

  For example, in this moment, I have a Cisco router with IPv6 support (routing) but do not support BGP IPv6 neighbors
Error (just in case):
  (Probably you are receiving the message below) 

*Mar  1 02:05:00.663: BGP: Advertised Nexthop ::FFFF: Non-local or Nexthop and peer Not on same interface
*Mar  1 02:05:00.663: BGP(1): rcv UPDATE w/ attr: nexthop ::FFFF:, origin i, metric 0, originator, path 1, community , extended community
*Mar  1 02:05:00.667: BGP(1): rcv UPDATE about 2001:db8::/32 -- DENIED due to:
*Mar  1 02:05:00.667: BGP(0): Revise route installing 1 of 1 route for -> to main IP table
*Mar  1 02:05:00.771: BGP(0): computing updates, afi 0, neighbor version 0, table version 25, starting at

Fortunately BGP support carrying routing information for different protocols (ie. IPv6). Therefore it is possible to exchange prefixes IPv6 over eBGP IPv4 sessions.
In this basic scenario with R1 <--> R2 connected back-to-back the configuration is as follows (the prefix announced by R1 is learned by R2).

 interface Ethernet1/0
 ip address
 ipv6 address 2001:db8::1/64
 ipv6 enable
router bgp 1
 no synchronization
 bgp router-id
 bgp log-neighbor-changes
 neighbor remote-as 2
 neighbor ebgp-multihop 2
 no auto-summary
 address-family ipv6
 neighbor activate
 network 2001:db8::/32
 no synchronization
 redistribute static
ipv6 route 2001:db8::/32 Null0

 interface Ethernet1/0
 ip address
 ipv6 address 2001:db8::2/64
 ipv6 enable
router bgp 2
 no synchronization
 bgp router-id
 bgp log-neighbor-changes
 neighbor remote-as 1
 neighbor ebgp-multihop 2
 no auto-summary
 address-family ipv6
 neighbor activate
 neighbor route-map IPv6-NextHop in
route-map IPv6-NextHop permit 10
 set ipv6 next-hop 2001:db8::1

"The trick":
* The session must be eBGP multihop, if not, R2 will not learn the prefix (the same error as seen above). I admit I do not get 100% why it happens however after readings some documents it looks like the router complains that the next-hop IP address and the way it was configured are in different subnet (make sense, one is IPv6 and IPv4 another!).
* In R2 (who receive the prefix) there must be a route-map applied (in) forcing the next-hop IPv6 address of R1
After applying ebgp-multihop (everything works):
* Mar 1 02:01:42.539: BGP (1): rcvd UPDATE w / attr: nexthop :: FFFF:, origin i, metric 0, path 1* Mar 1 02:01:42.539: BGP (1): rcvd 2800:26 :: / 32* Mar 1 02:01:42.543: BGP (0): Check route installing 1 of 1 route for -> to main IP table* Mar 1 02:01:42.543: BGP (1): Check for installing route 2001: db8 :: / 32 -> 2001: db8 :: 1 (::) to main IPv6 tableMore information:-

I hope it's useful!

Friday, January 4, 2013

Cisco clear line does not work

When performing a "clear line" in a Cisco Router/Switch to disconnect a Telnet or SSH session does not work. The user still in the vty.


IMP# sh user
Line User Host (s) Idle Location
2 vty 0 idle 00:00:01 abcd aacosta
* 4 vty 2 idle 00:00:00 pepe xx.yy.zz.dd

We want to disconnect aacosta:
IMP# clear line vty 2

and still appearing:

IMP# who
Line User Host (s) Idle Location
2 vty 0 idle 00:00:39 abcd aacosta
* 4 vty 2 idle 00:00:00 pepe xx.yy.zz.dd

Procedure and solution:
There are two ways to do it:

a) Quickly and 99% sure it will works (and less likely to damage something else).
Instead of using "clear line vty" use "clear tcp line":

So (again to disconnect pepe):

IMP# clear tcp line 2

b) And the second way more drastically:

We have to search for the TCP connections in the router at that time. We use the command "show tcp brief". We filter port 23 (Telnet) or 22 (SSH) as applicable.  
For example:

IMP# show tcp brief | i \ 23 _
63820270  n.n.n.n.23        a.b.c.d.56691     ESTAB
637E1AC0  x.x.x.x.23             xx.yy.zz.dd.39431   ESTAB

The value on the left in the memory addrees within the TCB (TCP Block), this is precisely the TCP connection we will have to remove.
The command is:

IMP# clear tcp tcb 637E1AC0

NOTE: Please be sure of the value before deleting the TCP session, remember that the router may have HTTP, BGP, HTTPS and other important TCP connections.

Good luck, I hope it was useful,

A website like will provide you with the highest quality in the industry.