Skip to main content

BGP Configuration in Nokia, Cisco, Juniper and Huawei Part 1

BGP is a routing protocol used to exchange routing information between different autonomous systems (Ases) and is described in RFC 4271, A BGP 4. An IGP such as OSPF or IS-IS have a main role for exchange of routing information within each AS. BGP is very scalable and stable routing, therefore bgp in most cases is deployed to improve/enhanced the existing network.

BGP can scale to million of routes and multiple copies of the Internet route table. Therefore, BGP is the fundamental routing protocol of the internet and is used  by every ISP in the world for ISP interoperability. Right now BGP still growth to support various capabilities such as multiple protocol families.

BGP Operation

To exchange routing information with BGP, a BGP session must be established between BGP Speaker (Router that running  bgp routing known as bgp speaker). BGP routers with established BGP sessions are knows as BGP Neighbors or peers.

A BGP session is established in two phase:

Phase 1:TCP connection – Both BGP speaker atempt a TCP session on port 179. BGP speaker with higher router-ID retains the connection, and the other BGP speaker drop its connection.

Phase 2: BGP Capabilities exchange – After TCP session is established, BGP speaker exchange BGP messages. The following parameters must be correctly configured for a session to be established:

  • BGP Version Number
  • AS Number of the peer
  • BGP router-ID
  • Authentication if you configured

BGP currently defines five message types, type 1 throgh 4 defined in RFC 4271, and type 5 is defined in RFC 2918.

  1. Open – is used to initialy request a BGP session with peer and exchange BGP parameters
  2. Update – is used to exchange NLRI/Prefix
  3. Notification – indicate an error and close peer session
  4. KeepAlive – is used to respond to an Open message and to maintain TCP session
  5. RouteRefresh – is used to request a BGP peer resend the routes it advertised at session establishment

You can see the exchange more detail in the packet capture file .pcap  in this link.

BGP Session Types (eBGP and iBGP)

The different between these type is peer AS. When you peer with the same AS its called iBGP (Internal BGP), and when you peer with the differen AS its called eBGP (External BGP)

eBGP session are usually direct connect between BGP speaker, but its not mandatory, these router are called border or edge router. When you want peer not directly you should set BGP Multi-hop for increase IP TTL.

iBGP session are usually not directly connected. Because the routers are in the same AS and managed by one administrator.

BGP Attributes

BGP is a path-vector protocol that uses BGP path attributes to choose the preferred path to destination. BGP attributes are divided into two main categories: well-known and optional. Well –known attributes have two sub categories: Mandatory and discretionary while Optional attributes have two subcategpries: transitive and non-transitive.

  • Well-Known Mandatory –This Type of attribute must be present in every BGP update, and its expected that all BGP speaker understand the meaning of the attribute. If well-known mandatory attribute missing, a Notification message is generated and BGP cant established. The well-known mandatory are Origin, AS-Path, and Next-Hop.
  • Well-Known Discretionary – This type of attribute is recognized by all BGP speaker, but may or may not present in the Update message. The sender choice to include it, based in its meaning. The well-known dicretionary attributes are Local Preference and Atomic-Aggregate.
  • Optional Transitive – This attribute may or may not be supported in all BGP implementations. If one is snet in an Update message, the BGP speaker must accept the attribute and past it along to other BGP speakers, even if its not supported. Optional trasitive attributes are Aggregator and Community.
  • Optional Non-transitive – This attribute may or may not be supported in all BGP implementations. Non-trasitive attribute is not passed to eBGP peers and can be safely ignored if its not understood. Optional non-transitive attribute are MED, Originator-ID, and Cluster-list.

Here some brief explaination about each  attributes :

 

LAB Test

In the Lab The the following Software released were used :

I would use this base topology for lab test :

We can see 2 AS In the topology above, 65540 and 65550. Each AS running OSPF area 0 as IGP base protocol. But OSPF not mandatory, you can choose other IGP that you want like IS-IS. The IGP infrastructure must be stable because BGP relies on the IGP routing within AS. Instability in the IGP environment may cause a larger problem in BGP.

R1, R2, R3, and  R4 act as border router/edge router, R5 and R6 both are member of AS 65540 they have loopback address as customer network and want to advertise to AS 65550 via BGP.

Below OSPF configuration for all routers :

R1

R2

R3

R4

R5

R6

Configuring Global Parameters

Two Global Parameters that are configured when implementing BGP: AS Number and Router ID.  Because i use four different router, so the configuration each router also different, but i can say the basic CLI Nokia and Juniper is very similar and  Huawei have similarity  with Cisco.

For Nokia, AS number can be configured either globallly in the router context or specified peer group with local-as and juniper too. We will configured in global router :

A:R1#configure router autonomous-system 65540 
root@R2# set routing-options autonomous-system 65540

For Huawei and Cisco AS number configured in BGP context :

RP/0/0/CPU0:R4(config)#router bgp 65550
[R3]bgp 65550

We must also  configuring  router-ID at the global or BGP level context, we choose configuring router ID at BGP level. If the router ID have not configuring, the system or loopback address will be derived as router id. If neither router-ID nor system address is configured, a BGP peering is not established.

Group and Peer Configration

A peer group defines a template with common configuration parameters shared by all neighbors in the group. The use of peer groups simplifies BGP management and administration. In Nokia and Juniper defines peer group are mandatory, but in Huawei and Cisco its just an options. In this LAB configuration the all routers defines peer group to facilitate management and administration. Below the configuration of Peer groups for all router :

R1

R2

R3

R4

We have two BGP group “eBGP” and “iBGP”, eBGP group will you use Interface address AS as source address to update packet while iBGP group will use system address as source IP to update packet.

eBGP anf iBGP Configuration

eBGP peer are usually directly connected, and the peer address used is the neighbor interface address, while iBGP peer are used to system address to provide a more fault-tolerant design. Listing below show the configuration of an eBGP and iBGP session between R1, R2 and R3, R4, R5 and R6. On cisco router we must enable  soft-reconfiguration inbound always to store routes that has been received.

R1

R2

R3

R4

R5

R6

Exporting Network to BGP

The All router required export policy to advertised non-BGP routes in BGP, by default BGP not advertise prefix anything. First, we want to advertise system/loopback address of router R1 and R2  to AS 65550 and vice versa, for router R3 and R4. and then we advertise all customer network through BGP. Below the configuration of policy :

R1

R2

R3

R4

Nokia and Juniper must specify policy statement to tell export their system/loopback address and then apply to BGP group. Huawei and Cisco have same characteristic about how to advertise their system/loopback IP to the BGP, we don’t use specific policy statement to advertise this, we just need define IP in family address unicast  with statement  network . I think it’s done, but in the cisco router they applied routing special enforcement that mean every eBGP neighbors must have an inbound and outbound policy  configured. If no policy is configured, no routes are accepeted from the neighbor, nor are any routes advertised to it. This added security measure ensures that routes cant accidentally be accepted or advertised in the case of a configuration omission error. The enforcment policy affect just on externalBGP neighbor. For internalBGP neighbors all routes are accepted or advertised if there is no policy. For simple eBGP neighbor policy configuration, we will accept and advertised all routes with no modification with policy pass-all. After that router R5 and R6 will received customer 3 and 4 prefix and router R3 and R4 will receive customer 5 and 4 prefix, let see the BGP RIB IN.

R3

R4

R5

R6

In router R5 and R6,  customer prefix of R3 (172.16.3.0/24) and R4 (172.16.4.0/24) doesn’t mark as valid route, Why? lets examine one of the customer prefix and route propagation between AS.

 

Use of Next Hop Self

By default eBGP doesn’t make a change about the next hop address, the router just passed the route without modification. In listing above prefix 172.16.3.0/24 have Res. Nexthop Unresolved because the Next-Hop, 117.0.0.3, is not known in AS 65540. The situation is the same R6. The unresolved Next-Hop issue can be resolved by configuring next-hop-self on router R1 and R2 which play as edge router. When applied to group iBGP, R1 and R2 sets the Next-Hop of routes advertised to its iBGP peers to its system/loopback address.

R1

R2

Let’s examine customer prefix on router R5 and R6 again.

There are other solution to an unresolved Next-Hop. One approch is to advertise the external interface into IGP, typically as passive interafce. However next hop self is simple and effective, and is usually the preffered solution.

Selection of eBGP vs. iBGP routes

 

When router receives two routes for the prefix, in the example router R2 receive prefix 172.16.3.0/24 from eBGP peer R4 and another from iBGP peer R1. The two routes have the same AS-Path, Origin, and MED. BGP therefore selects the route learned from the eBGP peer over the one learned from iBGP peer, as shown in listing above. The result is the traffic from R2 for 172.16.3.0/24 leaves the AS at R2 instead of through R1.

Selection of Route Based on IGP Cost

When R6 receives two routes for prefix 172.16.3.0/24. and the routes have the same Local-Pref, As-Path, Origin, and MED. They are both learned via iBGP. but the router R6 will choose route from R2 because he have IGP cost lower than R1. The route with the lowest IGP cost to the Next-Hop is selected.

 

Source :

~. Alcatel-Lucent Service Routing Architect (SRA) Self-Study Guide: Preparing for the BGP, VPRN and Multicast Exams
~. Implementing BGP on Cisco IOS XR Software (Cisco.com)
~. AR150&200&1200&2200&3200 V200R003C01 Configuration Guide – IP Routing (support.huawei.com)
~. Junos OS  BGP Feature Guide (Juniper Networks)

 

 

 

Khoirul Firdaus

Network Telco Engineer - SDN/NFV Enthusiast