Nokia (Alcatel-Lucent) BGP configuration tutorial. Part 2 – BGP policies. Community

featured

In the first part of this BGP tutorial we prepared the ground by configuring eBGP/iBGP peering. We did a good job overall, yet plain BGP peering relationship is useless, the power of BGP in its ability for granular management of multiple routes from multiple sources. And the tools that help BGP to handle this complex task are BGP policies at their full glory.

In this part we will discuss and practice:

  • BGP export/import policies for route advertisement/filtering;
  • BGP communities operations;
  • Aggregation of BGP routes: route summarization technique and the corresponding aggregate  and atomic-aggregate path attributes

Index

What are BGP policies for?

BGP peering configuration process is simple, you saw it in Part 1, but, frankly, no network engineer leaves BGP router in a default state “receive all, advertise all”. What is far more challenging is to deploy proper BGP policies which are used to protect local AS from bogus or unwanted prefixes and to optimize both incoming and outgoing traffic flows.

In BGP you can define two types of policies: Import and Export. To see where and when does the particular policy takes effect I paste here once again BGP route processing diagram:

Export polices are used for:

  • export routes from different protocols to BGP (like IGP routes being exported to BGP in Part 1)
  • granular control of advertised routes
    • prohibit unwanted prefixes advertising
    • set path attributes to desired NLRI
  • reducing control plane traffic
    • advertise aggregate routes

Import policies are used for:

  • filtering unwanted NLRI
    • by prefix, prefix-length, community value
  • manipulation of outbound traffic
    • applying Local-Pref  attribute to desired prefixes
    • modifying/setting  MED  value or any other transitive attribute

In Alcatel-Lucent Service Router OS BGP policies configuration takes place in router’s policy-options context – configure router policy-options .

To see how to configure these policies, where to apply them and what goals could be achieved, we will go through a set of tasks you could face as an ISP engineer. To simulate simple ISP scenario we will use UNetLab and build the following topology:

Interfaces, IGP and basic BGP configuration is the same as in Part 1, see Wrapping up section for configuration output.

Community attribute

We start our journey with BGP communities introduction. Traditional community (not extended) is an optional transitive BGP Path attribute and as per RFC 1997 its definition is: A community is a group of destinations which share some common property.

I like to think of a community as a label (or a tag) which BGP speaker puts on a NLRI. This label could serve different purposes like identify prefixes originated from a specific geographic region, customer or service, could indicate specific prefix treatment like no-export  or no-advertise  or could mean any other property which BGP router wants to communicate with an NLRI. Communities themselves are just the means to tell other BGP AS’es something about specific prefixes, they are useless until you bind some actions to them. For example, you tag some prefixes with community A and others with community B and then tell your BGP peers to, for example, set Local Preference 200 for prefixes with community A and leave Local Pref intact for prefixes with community B.

Communities are represented by a community string which is a 32 bit value. First two bytes of a community attribute have to be encoded with an AS number where community was born, and the other two bytes are set by AS network engineer as he pleases (or in other words community string format goes like this  <2byte-asnumber:community-value> ).

The community attribute values ranging from 0x0000000 (0:0) through 0x0000FFFF (0:65535) and 0xFFFF0000 (65535:0) through 0xFFFFFFFF (65535:65535) are reserved.

To practice with a classic community attribute lets run our lab and refer to the following picture:

We will use three different communities for our customer routes:

  • 65510:100 – community for every route originated from the West side of our AS 65510
  • 65510:200 – community for every route originated from the East side of our AS 65510
  • 65510:2 – community for the  Customer_2  routes

Add community

Community strings are configured under policy-options  context. At first we have to specify prefix-lists for our customers networks and declare all the community strings we want to later work with.

The same policy-options  configuration block goes to R6.

To tag routes with community values we have to configure policy-statement  which adds community for selected prefixes. This policy will be later used by BGP as an export policy.

Community operations syntax:

Lets dissect policy-statement "Adv_Customers_nets" piece by piece:

Again, the same configuration goes to R6.

Its time to apply our policies both on R5 and R6. And you already know the drill:

Now take a look at the show router bgp summary command on R5. There are 2 routes advertised to every iBGP neighbor and 2 rotes received from its fellow R6:

Show communities

To ensure that correct communities were passed along with the NLRI we can issue  show router bgp routes <prefix> detail

Everything works as expected. Customer_1  routes tagged with one community “West”, and Customer_2  routes tagged with both “West” and “Customer_2” communities. Its time to fire up wireshark and see how community strings transfer in the BGP Updates:

Community path attribute propagates across eBGP links. To check this we can issue a command on R3 (which resides in AS 65520) that selects the routes with a specific community value :

And of course you can use  show router bgp routes <prefix> hunt to see the most detailed output for a given BGP route.

Well-known communities

[RFC 1997] specifies three well-known communities:

  • NO_EXPORT (0xFFFFFF01) All routes received carrying a communities attribute containing this value MUST NOT be advertised outside a BGP confederation boundary (a stand-alone autonomous system that is not part of a confederation should be considered a confederation itself).
  • NO_ADVERTISE (0xFFFFFF02) All routes received carrying a communities attribute containing this value MUST NOT be advertised to other BGP peers.
  • NO_EXPORT_SUBCONFED (0xFFFFFF03) All routes received carrying a communities attribute containing this value MUST NOT be advertised to external BGP peers (this includes peers in other members autonomous systems inside a BGP confederation).

You will encounter  no-export  and no-advertise  communities quite often, so don’t skip that part of the tutorial.

To demonstrate the power of the default communities I would like to introduce you another AS 65530 which has the single-homed peering with AS 65520:

Router R7 residing in AS 65530 has default BGP configuration:

And thus receives all BGP routes R3 marked as valid and placed into its BGP Rib-Out database:

Moreover, R7 receives all the community values with the received NLRI. See the community string 65510:100 for the received route 10.10.55.0/24 :

Replace Community

We will change this behavior by tagging prefix 10.10.55.0/24  with no-export  community. To do so I will add policy-statement to our border router R1 which will replace the community string  65510:100 for the NLRI  10.10.55.0/24 with the  no-export one. See figure to track changes we are going to make to the Customer_1  prefix 10.10.55.0/24

Lets write down the details about prefix  10.10.55.0/24 on R3. R3 receives this prefix from R1 and installs in its RIB. Community value for this prefix is  65510:100 :

Now go to R1 and add the necessary configuration:

Ok, lets see if this magic was casted properly, check with R1 and its RIB-In and RIB-Out:

Good, R1 modified community attribute of this route. It is important to note that community replace  function removes all communities for a prefix. So if we had 2+ communities for the   10.10.55.0/24 prefix we would end up with just one  no-export in the end.

Well, lets check with R3, how is this fella doing?

R3 sees and uses this prefix with no-export  community!

Before we jump to R7 let the dust to settle and think about the propagation path of the examined prefix. R5 originates this prefix and sets community West "65510:100" . R5 then advertise via its UPDATE message this prefix with that community to all of its iBGP peers (R1, R2 and R6 are the iBGP peers of R5). R1 (since we configured it this way) replaces community  West  with  no-export for its eBGP peer R3, but R2 does not.

This leads to a situation when R2 advertises   10.10.55.0/24 prefix with its original community  West "65510:100" so R4 selects this route as the best (because R4 prefers eBGP routes over iBGP):

This highlights the fact that if you have more then one eBGP peers and want to communicate specific community value – you should do this on every border BGP router.

Check R7 BGP routes now. We expect that R3 does not advertise the prefix   10.10.55.0/24  to its eBGP peer R7, since it is equipped with  no-export community:

That is what  no-export community for. R3 does not advertise a route with  no-export to its eBGP peers, but do advertise it to its iBGP peers:

With  no-advertise community works a bit different, if a router receives a route with   no-advertise community it will not advertise it at all even to its iBGP peers.

We will proceed the same steps to practice with add and remove community operations.

Remove Community

At this moment R2 does not modify any routes flying off to eBGP peer R4. Lets imagine that we now have to remove community  Customer_2 from all Customer_2 routes on R2 before advertising them to AS 65520. To do so we have to perform community remove operation. To filter all the routes with community string 65510:2 we could use prefix lists or better filter by community string:

Now R2 takes routes with community string 65510:2 and removes before sending to eBGP peer R4:

Note that remove operation removes just this community from a list of communities. Like in this example R2’s RIB-In had the prefix 172.10.55.0/24 with both 65510:2 and 65510:200. And remove operation worked for 65510:2 community only.

Matching on Community

The whole thing with communities is to perform some actions for the specific prefixes. And the most important part here is how to filter routes based on their community string? I show you the basic scenarios with various filtering options.

“AND” and “OR” operators

How can you pick out the routes with different communities and modify them altogether? One approach is to write multiple policy-statements with the same action but for different from community <name> statements. This is a bruteforce. There are far more elegant techniques.

To create a community that matches some of community values you can use | operator in a string like that  community West_or_Customer_2 members 65510:2|65510:100 . This community will match prefixes with community strings like  65510:2 ,  65510:2 65510:100 ,  65510:2 63300:2 54487:200

To match more than one community (emulate AND operator) you can compose community like this :  community "A_and_B" members "65510:2" "65510:100" . This community will match   65510:2 65510:100 or   100:100 200:200 65510:2 65510:100 but not 65510:2 or  100:100 65510:2 .

Expressions

Alcatel-Lucent SR-OS has built-in expressions engine equipped with simple yet most commonly used operators. The syntax of Expressions is as follows:

A good example of expressions use case it to exactly match only prefixes with specific communities only:

This community once used in from statement of a policy will match prefixes with community string 65510:2 65510:100  only (thanks to exact command at the end).

Regular Expressions

Another approach is to use regular expressions for community strings.

Let me show you how easy it is to filter routes with community string containing  65510:100  or 65510:2 :

See how I defined community Customer_2_from_West , I used simple regular expression for least significant two bytes of the community string  65510:(2|100) . This matches communities 65510:100  or 65510:2 . Another way to achieve the same effect is to write community members like this: 65510:2|65510:100 . This regexp community string will match strings like   65510:2 ,  65510:2 65510:100 ,  65510:2 63300:2 54487:200

Of course you can use more complex regexps, refer to this table of supported operators to build a regexp of your own.

Wrapping up

Here goes our final configuration state for all routers. I will use this configuration for my next post which will be about route summarization, which in BGP terms sounds like route aggregation.

 

 

 

 

 

 

Roman Dodin

Network engineer at Nokia
Eagerness to learn multiplied by passion to share.
You can reach me at LinkedIn

You Might Also Like

  • ahmed karim

    amazing Roman !!, can’t wait for Part 3.