- Notifications
You must be signed in to change notification settings - Fork 5
/
Copy pathsetting-no-export-bgp-community.html
13 lines (11 loc) · 2.36 KB
/
setting-no-export-bgp-community.html
1
2
3
4
5
6
7
8
9
10
11
12
---
url: /2012/10/setting-no-export-bgp-community/
title: "Setting NO-EXPORT BGP Community"
date: "2012-10-31T06:52:00.000+01:00"
tags: [ Internet,BGP ]
---
<p>A reader of my blog <ahref="/2011/10/bgp-and-route-maps/#c2840746556571289253">experienced problems setting <em>no-export </em>BGP community</a>. Here’s a quick how-to guide (if you’re new to BGP, you might want to read <ahref="/2008/02/bgp-essentials-bgp-communities/">BGP Communities</a> and <ahref="/2011/10/bgp-and-route-maps/">BGP and route maps</a> posts first).<!--more--></p>
<p>The <em>no-export </em>BGP community is defined in <ahref="http://tools.ietf.org/html/rfc1997">RFC 1997</a>: “<em>A</em><em>ll routes received carrying a </em><em>[BGP] </em><em>communities attribute</em><em></em><em>containing this value MUST NOT be advertised outside a BGP</em><em></em><em>confederation boundary</em>” (i.e. outside our own AS, or across regular EBGP sessions).</p>
<p>If you want to use the <em>no-export </em>community to ensure some of your prefixes are never announced to routers outside of your AS, then the router originating the prefix should set the community with a <strong>network route-map </strong>or <strong>redistribute route-map </strong>BGP router configuration command. This design is commonly used in <ahref="http://demo.ipspace.net/get/D1%20Large%20Scale%20Network%20Design%20Guidelines.mp4">large ISP networks that propagate provider aggregatable customer prefixes in BGP</a>.</p>
<p>If you want to use the <em>no-export </em>community to prevent the upstream AS (your ISP) from propagating a BGP prefix to the rest of the Internet (example: <ahref="/2012/10/is-layer-3-dci-safe/">advertising two /25s for traffic engineering purposes</a>), then you MUST NOT set the community with the <strong>network </strong>or <strong>redistribute</strong> command – the default filters applied to every EBGP session would never allow such a prefix to be propagated to EBGP peers. </p>
<p>In this case you MUST attach the <em>no-export </em>community to the BGP prefixes you’re advertising with a <strong>neighbor route-map </strong>command (or <strong>neighbor default-originate route-map</strong> command – see the comment by Jose Jara) because the route map attached to a BGP neighbor gets executed (and the <em>no-export </em>community attached to BGP prefixes) after the default filters have already been applied.</p>