BGP comunity no-export

[Steph1963]

Hi,

I would like to have a better understanding of the BGP community no-export. I read somewhere that this is typically used to prevent that a company using more than one internet connection to different ISP from becoming a transit path for ISP traffic.

My problem is that I do not find this behaviour when I simulated the following network:

The utilisation of the BGP community no export in AS 100 prevent traffic from AS400 to AS500 from going into the AS100 (transit path) but does not prevent traffic from AS200 to AS300 from transiting in AS100. AS 200 and AS 300 does not announce routes whith BGP community no-export but still used these routes.

In order words, routes from AS300 announce by AS100 into AS200 are installed and used within the Autonomous System. Samething on the other side, routes from AS200 announce by AS 100 into AS300 are installed in used. This means that if you are in AS200 and you want to reach a AS300 routes, you will go through AS 100 in spite of thte utilisation of BGP community no export. Similar behaviour for AS300

My questions is does this behaviour is normal and why is it like this? What would be the real way to prevent ISP transit traffic.

Thanks for your help

Stéphane

[Richard Burts]

Stéphane

It is not clear to me where and how you are using the no-export community. If you could post specifics of where it is applied and how it is applied then perhaps we could provide better answers about whether the behavior is normal.

In my perspective the no-export community is more a tool for enforcing policy where you advertise routes to external neighbors but want to limit how far the routes propagate and not necessarily a tool to prevent becoming a transit network. I believe that the most effective tool to prevent becoming a transit network is to configure an AS path list which permits only ^$ and apply the path list as a filter on outbound advertisement to external neighbors. This will permit advertisement only of routes which originated in your own AS.

HTH

Rick

[Steph1963]

Hi Rick,

I thought that the no-export community, base on what I read in Cisco BGP case,  was strictly used when we wanted to prevent an AS from becoming a transit path.

My test and what you are saying kind of indicate that no export is used to prevent from anouncing a route into another AS but do not forbid to used this route locally.

Can I say that that the no advertise community is similiar to the no-export but is used in the same AS instead of a different AS.

Thanks for your help

Stéphane

[Richard Burts · Accepted solution]

Stéphane

In doing some Google searches I do find some articles that talk about using the no-export as part of a strategy for not becoming a transit AS. So that may be one of its uses, but it certainly has other uses. For example here is a paragraph which talks about no-export used for another purpose: "NO-EXPORT is commonly used within an AS to instruct routers not to export a prefix to eBGP neighbors. For instance, subnets of a larger block can be advertised to influence external AS best-path selection, and those not required for this traffic engineering purpose may be tagged NO-EXPORT to prevent them from being leaked to the Internet (and thus contributing to unnecessary global routing table growth). If a neighboring AS accepts this community, it can be used to selectively leak more specifics for traffic engineering but limit their propagation to just one AS."

So no-export is not strictly for transit AS. It can be used as part of a strategy for route aggregation, for not become transit AS, or for other purposes. For more detail you can try this link:

http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_6-2/bgp_communities.html

I believe that the use of an as path filter is a much better way to prevent becoming a transit AS.

The no-advertise community is similar to the no-export in that both identify prefixes that should not be advertised. But the difference is that no-advertise says do not advertise this to any other router. And no-export says do not advertise to external neighbors, but is ok to advertise to internal neighbors.

HTH

Rick

[Steph1963]

Hi Rick,

Very helpful, thanks for your help

Stéphane

[marikakis · Accepted solution]

Hi Stephane,

The behavior that you described in your original post can be explained if you have set the community as no-export *outbound* from AS100 towards AS200 and AS300. If RTC/AS200 originates and advertises a route towards RTA/AS100, then route reaches RTB/AS100. If you set the community as no-export when RTB/AS100 advertises routes to RTD/AS300, then RTD/AS300 receives the route with the community no-export. This means that the route will be used inside AS300, but will not go any further. Which agrees with what you observe. Similar things hold in the other direction (i.e. for a route originated say in RTD/AS300 and advertised towards RTB/AS100 with the community set outbound on RTA/AS100 towards RTC/AS200).

If you want AS100 to NOT advertise the routes it receives from AS200 and AS300 to AS300 and AS200 respectively, then try setting the community as no-export *inbound* on the eBGP sessions of the border routers of AS100. This way you set the community at the point where the external routes get in AS100. (You could also set the community inbound or outbound on the iBGP session of AS100 too, but it's a bit ugly). If you set the community at the borders as routes go out, it's too late (routes are on their way out, they just get "tagged" with the community on their way out to the peer AS, and peer AS will act upon them according to the communities contained in them, if these are not overridden by the local policies of the peer AS).

The use of the no-export community can serve various scenarios, but the basic mechanism is that of stopping an advertisement from crossing an AS border. You just need to define to which AS border this applies by setting the community at an appropriate point in your BGP configurations. An example scenario where the no-export community is used is the case of remote-triggered blackhole filtering (as one of the possible safety measures that help avoid a leaking of specific routes that blackhole specific IP addresses from the AS that decides to blackhole them towards other AS's). In this case the community is set at the point where the blackhole routes are redistributed into BGP. In your case it is probably convenient to do this inbound on the eBGP sessions of AS100, as it can be done unconditionally to serve the purpose of the routes not being advertised to other AS's. If you do it e.g. on the iBGP sessions, then you might need additional filters to exclude the locally originated routes of AS100 from the no-export policy (or exclude anything else that must be advertised to external neighbors).

Kind Regards,
Maria

[Steph1963]

Hi Maria,

This is great info...

Many thanks for your help

Stéphane