Setting the NO-EXPORT BGP community
BGP communities are attributes that maybe added to every prefix we choose. This is very interesting if one wants to logically separate incoming and outgoing traffic. With communities we have more granular control over the data plane inside our Autonomus system.
The communities attribute is a way to group destinations into communities and apply routing decisions based on the communities. This method simplifies the configuration of a BGP speaker that controls distribution of routing information.
The communities attribute is an optional, transitive, global attribute in the numerical range from 1 to 4,294,967,200. Along with Internet community, there are a few predefined, well-known communities, as follows:
- internet—Advertise this route to the Internet community. All routers belong to it.
- no-export—Do not advertise this route to eBGP peers.
- no-advertise—Do not advertise this route to any peer (internal or external).
- local-as—Do not advertise this route to peers outside the local autonomous system. This route will not be advertised to other autonomous systems or sub-autonomous systems when confederations are configured.
In this small case scenario we have a customer AS 100 that does not want some prefixes to be advertised outside his own AS. Maybe the prefixes are malicious, or they have no agreement with the ISP companies or within any other reason this can be done with using the BGP default community NO-EXPORT. Let us take a look into the diagram.
In our small example we will be looking at the CX1 router and some of the ISP routing tables. First let us take a look at the BGP configs of the CX1 router, and the BGP table of the ISP2 router.
We can see that the ISP2 router has the two prefixes inside the RIB table. Those the prefixes we do not want to advertise outside the AS100. This is achieved via a simple route-map and an ACL that is associated with the desired traffic.
CX1#sh ip access-lists
Standard IP access list 1
10 permit 44.44.44.0, wildcard bits 0.0.1.255 (2 matches)
CX1#sh route-map
route-map NO-EXPORT, permit, sequence 10
Match clauses:
ip address (access-lists): 1
Set clauses:
community no-export
Policy routing matches: 0 packets, 0 bytes
CX1
neighbor 16.1.1.2 send-community both
neighbor 16.1.1.2 route-map NO-EXPORT out
We have an ACL that is used to capture source of loopback address advertised with the prefixes 44.44.44.0/24 and 44.44.45.0/24. After that I have created an route-map called NO-EXPORT that uses the acl 1 and sets the community no-export on those prefixes. Then we have applied this route map to the neighbor inside the AS100.
Now let us see the RIB table of the ISP2 router.
And it is working fine, we do not see the prefixes we stopped to advertise. We can verify this further on the edge router of the AS100.
CUSTOMER#sh ip bgp neighbors 172.16.1.2 advertised-routes
BGP table version is 11, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
*> 2.2.2.2/32 192.168.1.2 0 0 200 i
*> 3.3.3.3/32 172.16.1.2 0 0 300 i
*>i5.5.5.5/32 17.1.1.2 0 100 0 i
We can see that the prefixes are not being advertised to the eBGP neighbor as we intended. Down following we can see the BGP table of the AS100 edge router.
Total number of prefixes 4
CUSTOMER#sh ip bgp 44.44.44.0
BGP routing table entry for 44.44.44.0/24, version 10
Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer)
Not advertised to any peer
Local
16.1.1.1 from 16.1.1.1 (4.4.4.4)
Origin IGP, metric 0, localpref 100, valid, internal, best
Community: no-export
The prefix 44.44.44.0 is in the routing table but it has the no-export community attached to the route. Thus the prefix is not being exported to the eBGP neighbors. Very simple and clean.
Feel free to comment.
No comments:
Post a Comment