Nokia (Alcatel-Lucent) BGP configuration tutorial. Part 1 – basic eBGP, iBGP


When we say Service Provider, we imply BGP and when we say BGP, we imply Service Provider. There is no way I would leave you without covering configuration steps for one of the most versatile, scalable and robust internet protocols also known as BGP. And here it is – BGP configuration guide for Alcatel-Lucent Service Routers. As with OSPF configuration tutorial I will cover configuration process for various BGP scenarios along with verification and troubleshooting steps bundled with colorful figures, detailed code snippets and useful remarks.

BGP is so huge that I had no option but to write about it in several parts:

Part 1 dedicated to basic eBGP/iBGP configuration. We will practice with common BGP configuration procedures at first, then learn how to export routes into BGP process and prevent unnecessary route reflection by means of split-horizon over eBGP links. After that we will see how to configure iBGP to spread eBGP learned routes across Autonomous Systems. I will cover the necessity of full-mesh iBGP topology and the use of the  next-hop-self  command for iBGP peers.

It’s perfect time to configure some BGP, right?

Common BGP configuration steps

Despite what type of BGP (Internal or External) you are going to configure there are some basic steps we are about to discuss. Address planning, IGP configuration, router-id selection, autonomous-system number setting, peer groups and neighbor configuration – all of these task are common to every BGP configuration routine.

IGP and addressing

BGP completely relies on IGP (or static routes) when resolving nexthop address received in BGP updates from its peers. This means that prior to BGP configuration you should have IGP up and running. During this session I will refer to this base topology:

A few words about address plan and key characters in this scene: two Autonomous Systems (hereinafter AS) 65510 and 65520 are going to establish mutual BGP peering.

AS 65510 utilizes network for local link addresses, system interfaces of its routers and customers-assigned networks, whiles AS 65520 uses for the same purposes. Address plan details could be found at the Legend section of the “base topology” figure.

We will be working with two customers networks:

  •   R5_Customer -  in AS 65510
  •   R3_Ext_Customer - in AS 65520

As to Interior Gateway Protocol – I chose IS-IS, though you can choose an IGP protocol of your choice – it wont be any different. IS-IS configuration for this tutorial is super straightforward, system  and network interfaces are participating in IS-IS process for according AS (except interfaces between R1-R3, R2-R4 as they are connecting different AS’s and we will run BGP there). Inter-router links are all point-to-point type.

IS-IS configuration section for reference:

Configuring Router ID and Autonomous System number

Ok, IGP is configured, address plan is clear and documented, it seems its a perfect time to configure a common entity for almost every routing protocol  – Router ID. For BGP there is more than one place to configure Router ID. Here is Router ID selection process sorted by priority (in descendancy order)

  1. Router ID configured in BGP global context with command  configure router bgp router-id <ip-address>
  2. Router ID configured globally for a router with command  configure router router-id <ip-address>
  3. Router ID inherited from  system IP-address.

Important thing to remember that if no router-id nor   system interface configured – BGP will not start. Since we have  system interface configured for every router we dont need to specify router-id explicitly.

AS number can be configured either globally for a router  configure router autonomous-system <autonomous-system> or for a specified peer group with local-as command. We will stick to the first option and configure our AS numbers globally for a router:

Configuring eBGP

Common parameters are now configured and we can jump to eBGP peers configuration. Recall we have two routers within AS 65510 (R1 and R2) which will have eBGP peering sessions with R3 and R3 within AS 65520 accordingly. Thus we should configure eBGP peering between pairs R1-R3, R2-R4.

Alcatel-Lucent’s BGP configuration policy requires you to configure at least one peer group to make BGP peering happen. Peer groups are logical containers for BGP peers that share common parameters. Every BGP neighbor you add should find its place in any of the BGP peer groups, in other words – peer groups are mandatory in SR OS.

I will guide you through basic eBGP configuration between R1 and R3. R2 and R4 configuration will be just the same.

As simple as that, eBGP in its simpliest form has been configured in 5 lines. Pay additional attention to local-address command. It is common practice to specify link IP address for an eBGP peer, otherwise ALU router will try to establish TCP session from its system IP address and will obviously fail.

To verify successful eBGP peering use command  show router bgp summary (another way is to use  show router bgp neighbor <neighbor-ip-address>

At the end of this show command you can find information about BGP neigbors and their states. We issued   show router bgp summary on R1, that is why we see as a neighbor (which is R3’s interface IP address). If a session is established then you see the session uptime and number of routes recived/active/sent in a column State|Rcv/Act/Sent. Otherwise this column will show the state in which BGP session is currently operating.

String 0/0/0 (IPv4) is an indicator that peering has been successfully established and router R1 received and sent exactly zero IPv4 routes. And this is ok, since we only started eBGP session, but did not export any routes to it. It is very important to remember that by default ALU SR OS does not add any non-BGP routes to the BGP process.

Exporting routes to BGP

No fun at all to play with zero NRLI (network layer reachability information). Lets correct this and add some routes to our eBGP process. We have a perfect network for this in our address plan –  R5_Customer - . To emulate this customer’s network we must add loopback interface to R5 and announce this network to IS-IS:

After we created a network for our customer and announced it via IS-IS we should check if R1 could see it in its routing table:

R1 hears about  loud and clear! But this is not sufficient for BGP process on R1 to advertise this prefix to R3. We should explicitly tell BGP process running on R1 to take prefix into consideration and the way to do so is to create policy-statement and export it to BGP. Step-by-step plan goes like this:

  • create prefix-list to match desired prefix
  • create policy-statement accepting prefixes from prefix-list and delivering it to BGP process
  • add customer’s network to BGP via export <policy_statement> command under peer group context.

Lets implement this plan:

After we have policy option prepared we can use it in the export  command in eBGP peer group on R1:

Export command triggers BGP Update message with NRLI for  R5_Customer going from R1 to R3 (note that I made the same configuration to R2-R4 pair, so the figure below shows R2’s BGP update message as well):

Take a look at  show router bgp summary once again on R1:

Nice, we have sent and received one IPv4 NLRI. We will deal with the received route later, and now jump to R3 to check if exactly  R5_Customer network propagated to R3 from R1?

BGP route processing

I have to hit a pause for a moment and share with you the BGP route processing diagram. It helps to understand what BGP databases are there on ALU SR OS, what path does a BGP route take from the entering to the BGP processing to advertising.

credits: Alcatel-Lucent Service Routing Architect (SRA) Self-Study guide, WILEY

I will refer to these databases from now on as BGP RIB In, BGP Local-RIB and BGP RIB Out.

To see what routes are in BGP RIB In and BGP Local Routing Information Base (BGP Local-RIB) issue show router bgp routes command:

Perfect, network is in BGP Local-RIB (since it passed validation checks, see the asterisk flag * ) and flag  u tells us that this route is used and made its way to router’s R3 routing table:

Alcatel-Lucent eBGP reflecting routes issue

Now it is time to deal with the received route on R1 from its neighbor R3.

Local to AS 65510 prefix is in R1’s BGP Local-RIB, but why wee see it there? Because R3 sent it to R1. But why the hell R3 sent back prefix to R1 given that it came from it earlier?

Lets investigate NRLI propagation for this prefix:

  1. R1 sends BGP update message to R3 about prefix with AS Path 65510.
  2. R3 receives this update, stores it in BGP RIB In database and checks if this NRLI is valid (nexthop resolvable, no AS Path loop) in order to put this prefix in R3’s BGP Local-RIB.
  3. All the checks passed and R3 sends back NRLI back to R1 since this is not prohibited by RFC 4271 A Border Gateway Protocol 4 (BGP-4) adding its AS Number to AS Path.
  4. R1 receives this update and stores it in its BGP RIB In but this route will never make its way to BGP Local-RIB due to AS Loop error.

Based on the output from show router bgp routes command and the fact that there is only one flag i  associated with prefix we can conclude that this prefix was not delivered to Route Table Manager (RTM) and left alone in BGP RIB In of R1. But why is that? If we issue super-useful command  show router bgp routes <prefix> hunt for this network we could see what happened:

RIB In Entries section of this output and espesically the strings “Flags” and “AS Path” answer the question why R1 will not pass to the BGP Local-RIB — there is AS Path Loop for this NRLI. And this is the reason why this NRLI is in BGP RIB In only.

Split-horizon for eGBP

For those of you who came from Cisco or Juniper its quite strange to see that R3 send the same prefix back to R1. I agree, its hard to find real case scenario when it would be desired to receive previously announced prefix over eBGP. To mitigate this issue you can use  split-horizon command on R3. This split-horizon has nothing to do with standard iBGP split-horizon behavior (which is “do not advertise prefixes received from iBGP peer to other iBPG peers”).

eBGP resulting configuration

Check the resulting configuration of this basic eBGP configuration tutorial:

iBGP configuration

iBGP sessions are established inside AS and are used to distribute BGP routes between routers inside this AS. In our case we have two Autonomous Systems, so we will configure full mesh of iBGP sessions for AS 65510 and AS 66520:

The reason we need to configure full-mesh of iBGP sessions follows because we have iBGP split-horizon rule in effect. Starting with AS 65510 configure iBGP peer group for every router inside this AS and specify other routers system  IP address as a neighbor. For iBGP it is common to use system  or loopback IP address (instead of link addresses) as a neighbor address because this leverages IGP path redundancy.

Implementation plan for every router is straightforward:

  1. create peer group “iBGP”
  2. set local AS Number as peer-as inside iBGP peer group
  3. specify neighbors with their system interface
Important that for iBGP peers you do not need to specify local-address (though it is not prohibited) since ALU router will initiate TCP socket opening from its system IP address.

To verify that iBGP sessions have been successfully established you can use good-old  show router bgp summary or fancy  show router bgp group <group name> :

Ok, now we got iBGP full-mesh configured for both AS but to start playing with iBGP let me introduce you another customer network – R3_Ext_Customer - . This customer resides beside R3 and you should add this network to BGP with policies and export just as we did before for R5_Customer

You already skilled enought to answer the question “what happens next?” Right, R3_Ext_Customer NRLI goes from R3 to R1 via eBGP. R1 checks if this NRLI is valid by checking AS Path for looping and next-hop (NH) for reachability.

Since default behavior of BGP is to set its egress interface’s IP address as next-hop over eBGP links, we see that R1 receives BGP route with  as next-hop:

This next-hop is reachable to R1 since it has toR3  interface in this network. So R1 has every right to pass NRLI to BGP Local-RIB and then to the Routing Table Manager (it will then install this route to R1’s routing table).

And now iBGP on router R1 comes into play by advertising NRLI to its iBGP peers. This is a default BGP’s behavior to advertise valid BGP routes came from eBGP peer to all iBGP peers, and the most important part of this eBGP-iBGP routes redistribution is that the next-hop once set by eBGP peer (R3 in our case) goes unchanged in iBGP updates:

Take a look at R5’s BGP routes:

R5 received R3_Ext_Customer NRLI but it cant use it ( u  flag is absent). Invoke  hunt command to see whats wrong:

Aha, R5 cant validate received NRLI since its next-hop is unresolvable to R5. Recall the R1 did not change next-hop information it received from R3, so R5 received the same IP address as a next-hop and has no route to it. That is the reason that R5’s routing table has no network :

There are two approcahes to fix this:

  1. use  next-hop-self on R1
  2. adding eBGP interface to IGP (as passive) or implementing static or default routes in AS 65510 to reach R3’s interface network

We will stick to the option #1.

iBGP next-hop-self

I dont even quite sure that I have to tell you what next-hop-self command does. It forces iBGP speaker, who received an eBGP update message to substitute next-hop information with its  system IP address to help iBGP peers to use prefixes anounced via eBGP.

Get back to R5 and look for the changes:

Now it is a different story! R5 validates received NRLI and uses it, thanks to resolvable next-hop which is R1’s system IP address . The next step is to pass this route to the RTM which is responsible for routing-table provisioning. If we take a look at R5 routing table for the recently received prefix we will see that next-hop isnt :

The reason behind this discrepancy is that routing table should have connected networks as a next-hop and since is far from being connected to R5 it performs an operation called recursive lookup. R5 takes next-hop value recived from iBGP update  and perform route-table lookup for it:

R5 knows how to reach by means of IS-IS protocol and the next-hop for this prefix is indeed which is a connected network:

That is why we see different next-hop in routing and BGP Local-RIB tables.

Wrapping up

To this moment we have done a good job – we have configured exchange of two customers networks (R5_Customer and R3_Ext_Customer) between AS 65510 and AS 65520. Thanks to us, now a client residing in R3_Ext_Customer network can reach hosts from R5_Customer:

This was done by mutual exchange of corresponding routes both via eBGP and iBGP. We practiced with common BGP configuration procedures at first, then learned how to export routes into BGP process and managed to prevent unnecessary route reflection by means of split-horizon over eBGP links. Next step was iBGP configuration to spread routes from eBGP peers across Autonomous Systems. I covered the necessity of full-mesh iBGP topology and the use of the  next-hop-self  command for iBGP peers.

It this opening part of a massive BGP tutorial I was covering basic eBGP/iBGP configuration on Alcatel-Lucent Service Routers running SR OS. I intentionally left a lot of show commands output and configurations walk-throughs to let even a novice repeat those steps easily. If some of you want to get the full picture – see this configuration output for every router in this topology:






And for those of you who’s motto is “pcap or it didnt happen” I share wireshark dumps for these links:

noshut# exit all

Roman Dodin

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

You Might Also Like