BGP Prevent Transit AS

Hi Rene,

In your example shown below:

I would personally add in an explanation like the one i have included below as it was confusing as to why it allowed locally significant AS’s.

The string “^$” says to match the beginning of the string (“^”), and then immediately match the end of the string (“$”) this means that the string is null.

Within the scope of BGP the only time that the AS-Path is null is when you are looking at a route within your own AS that you or one of your iBGP peers has originated. Hence this matches locally originated routes

Hello Matthew

Thanks for the valuable suggestion, I will forward this to Rene for consideration and modification.

Thanks again!


Hello Rene,

In that case, as we mention in the no export, how will the neighbors know as we are not telling them?

I mean when we use OUT it tells ISP that you can know these prefixes from me, but when we use IN it only tell the prefixes inside the AS how to go out.

Can you please elaborate on your explanation?

Hello Kaza

In this particular case, we want to ensure that the prefixes that are being sent from the ISP routers to R1 will not be advertised again by R1. In other words, prefixes received from ISP1 should not be re-advertised to ISP2, and those received from ISP2 should not be advertised back to ISP1.

By using the in direction, the prefix learned from ISP1 (in an inward direction) is placed in the BGP table, but it is also associated with the no-export community, therefore, it is not re-advertised to ISP2. The opposite is also true. This is confirmed by looking at the BGP tables of ISP1 and ISP2.

I hope this has been helpful!


I would like to filter out this route that my friend is advertising. Is there a way to filter incoming routes?

I’ve tried using an access-list, a prefix-list, and a route-map to filter out the route, but none have worked so I’d like to know if I’m doing something wrong or if filtering incoming routes is not possible. I understand that my friend could use a prefix-list to filter out the routes he’s advertising to me, but I’m curious to see if I can do it on my end. Thank you.


 show ip bgp neighbors received-routes

Network          Next Hop            Metric    LocPrf       Weight Path
*>                                0       65000 65515 i
*>                                0       65000 65515 i

Hello Brian

You can indeed use prefix list filtering as well as distribute list filtering to achieve what you want. Take a look at the prefix-list section of this lesson:

Now in the lesson, the prefix list is applied on an outbound direction from the remote router. In order to apply it on your local device, you must apply it in an inbound direction.

For example, you can do this:

R1(config)#ip prefix-list NO-GoogleDNS deny
R1(config)#router bgp 1
R1(config-router)#neighbor prefix-list NO-GoogleDNS in

This should filter out the specific prefix.

I hope this has been helpful!


1 Like

Thank you @lagapidis. I used the suggested prefix-list IN and that suppressed the route.

1 Like

The option with no-export community can be a problem if AS 1 (R1 in this case) itself is a small ISP and has customers who need partial/full internet feed. One would argue that why would a customer of a small ISP need full internet feed. But there can be times when they do. For example:

  1. For research purposes - I had one customer which was a small university and just wanted internet feed for research.
  2. Even if you are small ISP today you might end up being a large ISP one day.

AS path filtering option seems to be a good option.

Other option is to use send community only with uplink routers.

Hello Muhammad

Yes, you are correct, and thanks for sharing your thoughts. These methods that are depicted in this lesson, including the no-export community method, are primarily used for preventing an enterprise’s edge routers from becoming transit ASes. Such devices are deployed specifically for serving an enterprise’s traffic needs, are should never route transit traffic.

Of course, if you are an ISP, even a small one, it is only logical that you will have some transit traffic in your network. If that is the case, then you should choose a method that is able to correctly filter out the transit traffic you want to block, and allow the traffic you want to serve. In such a case, the other three options, with the appropriate configuration, should be sufficient to employ this.

I hope this has been helpful!


Hi Rene,

Many thanks for explaining BGP Transit AS topic very well.
I have a query other than transit AS, can’t we use Filter AS path access list instead of prefix list creation in eBGP for routes export or import, where there are thousnads of routes we need to import

Nitin Arora

Hello Nitin

As stated in the lesson:

There are 4 methods how you can prevent becoming a transit AS:

  • Filter-list with AS PATH access-list.
  • No-Export Community.
  • Prefix-list Filtering
  • Distribute-list Filtering

Prefix-lists or distribute-lists will work but it’s not a very scalable solution if you have thousands of prefixes in your BGP table. The filter-list and no-export community work very well since you only have to configure them once and it will not matter if new prefixes show up.

So yes, you can use either Filter lists with AS PATH access lists or use the no-export community when you have thousands of routes that need to be imported. These two solutions are more scalable than prefix-lists and distribute-lists.

I hope this has been helpful!


Hello Laz

As you guys explain we want to influence our local AS to do not advertise prefixes from the other ISP, why on the filter-list 1 out as i know we want to influence our AS why is not in inbound direction ?I still get confused sometimes on this things :((



Hello Metodija

Remember that when you apply filter lists or route lists as part of a BGP neighbor command, the “in” or “out” does not refer to the direction of user traffic (data plane), but it refers to the direction of the BGP messages shared between BGP peers (control plane). In this particular case, the goal of the filter list is to ensure that only prefixes of the local AS are advertised with the ISP.

The filter list is applied in an outbound direction because it filters the ASes included in the BGP update messages sent out from the Fa0/0 and Fa0/1 interfaces of R1 to ISP1 and ISP2.

That way, ISP1 and ISP2 will only be informed of the prefixes found in R1’s AS, and will not learn about the ASes advertised by the other ISP router.

Take a look at this NetworkLessons note on the direction with which route maps (and filter maps) are applied to BGP neighbors.

I hope this has been helpful!


Hello Laz

Yes :+1: , i made it clear already :slight_smile: , i finally got it . By the way i had nice interview with Verizon i hope i will get the job .

Regards !

1 Like

Hello Rene,

R1(config)#route-map NO-EXPORT
R1(config-route-map)#set community no-export

R1(config)#router bgp 1
R1(config-router)#neighbor route-map NO-EXPORT in
R1(config-router)#neighbor route-map NO-EXPORT in

In the config above, since we are advertising why is it “in” instead of “out”?

Thanks in advance.

Hello Leoncio

Let’s reexamine what the goal is in this particular case. We want the prefixes that are advertised from ISP1 and ISP2 towards R1 to be tagged with the no-export community. That means that any BGP updates traveling from ISP1 to R1 or from ISP2 to R1 would enter into R1 in an inbound direction. So the NO-EXPORT route map should be applied in an inbound direction.

Remember, the “in” keyword indicates the direction of the BGP updates that we want to modify and not the actual user traffic being sent.

I hope this has been helpful!


1 Like

how would I configure an AS 200 ISP to only advertise I’m a little confused

ip prefix-list NO-TRANSIT permit

neighbor prefix-list TRANSIT out

Hello Jaime

In this particular lesson, the prefix list is being used to filter out what R1 advertises to ISP1. Only the subnet is being advertised to ISP1. So if you look at the BGP table of ISP1, you will see only appear in the BGP table with a next hop of which is the IP address of R1.

Now in your case, when you say “how would I configure an AS 200 ISP to only advertise” it really depends upon your topology. If you have an ISP router that exists within AS200, and you want it to advertise only the network, then you would indeed use the commands that you placed in your post.

This would result in the ISP router advertising only to your neighbor. However, the prerequisite to this is that the network is already in your local BGP table.

I hope this has been helpful!



A quick question. Could we also use the NO-ADVERTISE BGP community in order to prevent our organization from becoming a transit AS? Would it cause any problems?

Thank you in advance for your help.


Hello David

The BGP NO-ADVERTISE community is a well-known BGP community that prevents the advertisement of routes to any peer, internal or external. Using the NO-ADVERTISE community will prevent an AS from advertising specific routes to any other AS.

However, it’s important to clarify that this doesn’t directly prevent your organization from becoming a transit AS. A transit AS is an Autonomous System that allows traffic from other ASes to pass through it. Whether an AS acts as a transit AS is more a matter of its peering arrangements than of its routing advertisements.

If you want to prevent your AS from becoming a transit AS, you need to ensure that your AS doesn’t have agreements to forward traffic for other ASes. That’s where the four methods Rene mentioned in the lesson come in.

However, if you don’t want to advertise certain routes to peer ASes to reduce the chance of becoming a transit AS for those specific routes, you could use the NO-ADVERTISE community. But this is by no means a general solution for the issue, but a specific one for the particular routes that are prevented from being advertised.

I hope this has been helpful!


1 Like