Tag Archives: BGP

Border Gateway Protocol (BGP)

Reading Time: 9 minutes

BGP Basics

What is BGP

Border Gateway Protocol (BGP) is regards as the most influential network protocols as it is backbone of the internet today. BGP is a Path Vector Routing Protocol, that unlike other routing protocols uses TCP (port 179, as its transport layer) to establish connectivity before exchanging routing information with another BGP speaker (peer). BGP communication can be done between same and/or different networks, these networks are known as Autonomous Systems (AS) with an  AS being a set of Routers that are managed by single entity, business and/or company. BGP uses routing information to maintain a BGP Routing Information Base (RIB) of Network Layer Reachability Information (NLRI) which it will exchange with other BGP peer or Peer ASs. BGP is a classless protocol, it can support any IP prefix regardless of class, this is both for IPv4 and IPv6. It is important to note that requires TCP connection first before building BGP connection, without that first established session a BGP peering never happen, however once that session is connected it will not have to made again unless a change is made. BGP uses Keepalive messages to ensure reliability of the session as it does not use any transport protocol-based keep-alive mechanism to determine if peers are reachable.

BGP Usage

BGP is largely (but not exclusively) used in large enterprises and data centre hosting environments where the need for single or multihomed to multiple Internet Service Providers (ISPs) connections are needed, this is known as Exterior BGP (eBGP). BGP is extensively used with Service Provider environments. BGP allows a large range of the policy based controls for an AS to influence and/or manipulate routed inbound and outbound traffic to help optimise the movement of traffic for their own needs. Additionally BGP can be used between BGP routers within the same AS to advertise internal routes with the same level of control as eBGP, with some small however important difference, this is known as Interior BGP (iBGP).

eBGP vs iBGP

There are some Key Differences between eBGP and iBGP that are important to note:

eBGP

  • eBGP session is between BGP peers with different AS numbers
  • Inter-AS communication is by via eBGP
  • eBGP respects the AS_Path Path Attribute
  • Routes learnt via eBGP will be advertised to other eBGP and iBGP peers

iBGP

  • iBGP session is between BGP peers with the same AS number
  • Intra-AS communication can be by via iBGP
  • iBGP commonly uses an IGP for network reachability and to establish BGP TCP session via Loopback address
  • Routes learnt via iBGP will not be advertised to other iBGP peers however will advertise routes to an eBGP peer

The above isn’t the full differences but just some of the main difference that need to remember. Additionally there are situations where some of these rules may need to be manipulated and can be done in design and/or configuration however that is for later

BGP Peering States

When establishing a BGP session there are 6 states that need to be completed before peering session comes up. The first 3 states are to ensure the TCP transport layer connectivity is there, once this has been completed then BGP connectivity is established with the final 3 states:

BGP State Connect Description
Idle TCP This is when all BGP connections will be refused. An Idle state occurs when the BGP session hasn’t been configured on the other BGP peer or BGP has isn’t enabled at all. Commonly, a start event is required from the other peer to prepare the TCP connectivity.
Connect TCP The router listening for TCP connections and is waiting for the TCP 3-way handshake to be completed:

  • If this is completed, then an Open message is sent and is transitioned into the OpenSent State.
  • If TCP connections fails, the BGP peer restarts the ConnectRetryTimer and waits for the remote peer to initiate a TCP connection and transitions into an Active State.
Active TCP This is when the BGP peer is trying to establish TCP connection.
OpenSent BGP When in the OpenSent, an open message has been sent by the BGP peer however has not received by the local peer:

  • Once the message has been received, checked and has no errors, the local peer will send a Keepalive message.
  • If a message is received, checked and an error is found then state is transitioned back to an Idle state.
OpenConfirm BGP When in the OpenConfirm, the BGP is waiting on a Keepalive or Notification message:

  • Once the peer receives a Keepalive message, it will move into the Established state
  • If the local peer does not receive a Keepalive within the negotiated session hold timer, it will send a Notification message and transition back to Idle state. The same will occur if the local peer sends out a Notification message.
Established BGP Having received the Keepalive message, the BGP session is fully Established. The peers are now able to exchange Update, Notification and Keepalive messages

BGP Message Types

As shown above, there are a number of different messages sent between BGP peers to Establish a session and when even the peering has been established, messages are used to ensure that both peers have synchronized routing information. BGP can only process a message after the entire message has been received, the maximum message size is 4096 bytes with 19 bytes being the smallest message size, this would be just be a header with no data. Each message type uses a fixed header size of 19 bytes with BGP Keepalives not include any data after the header, so they will always use the minimum size.

Each Message would be include the following:

Message Type Description
Open Once TCP connection has been completed both peers will send out an Open Message. This message starts the peering session, it provides details about the remote peer, in addition to details about supported and optional options.

These details are included:

  1. BGP version (normally version 4)
  2. AS number
  3. Hold Time
  4. Router ID
  5. Par-Len
    • If this set, it informs the peer that optional parameters should be expected
  6. Optional Parameters
    • This is where negotiable parameters are indicated, these would be authentication and capability extension such as Multiprotocol Extensions and route refresh.
Update An Update Message sends a list of new, withdrawn or types of routes from the remote peer. Depending on the routing policy of remote peer these may or not be entered into the Routing Table.

These details are included:

  1. Unfeasible Route Length
    • If this is set, it will tell the peer, the length of withdraw routes
  2. Withdrawn Routes
    • Lists IP prefixes that have been removed as they are no longer deemed as reachable
  3. Path Attribute Length
    • This indicates the total length of Path Attributes field. Its value allows the length of the Network Layer Reachability field to be determined. A value of 0 determines that neither Path Attribute and NLRI is present in the update.
  4. Path Attribute
    • The following properties for a route is included:
      1. Origin
      2. AS Path
      3. Next-Hop
      4. Multi-Exit Discriminator (MED)
      5. Local Preference
  5. Network Length Reachability Information (NLRI)
    • Lists IP prefixes that will be advertised as reachable via the AS
Keepalive It is important to always remember that Keepalive Messages are not used to ensure the TCP connection between peers is kept. They are used to ensure that BGP Hold Timers do not expire keeping alive the route exchange.
Notification Notification Message is used to inform a peer that there is an error with the BGP session.

There are 6 Error code numbers:

  1. Message Header Error
  2. Open Message Error
  3. Update Message Error
  4. Hold Timer Expired
  5. Finite State Machine Error
  6. Cease

In addition to 17 Sub Error codes (6 Open Message Errors and 11 Update Message Errors). These can found in RFC4271

Refresh Normally BGP can not readvertise routes that have already been acknowledged by a peer, if the BGP peer has been configured to soft clear of BGP sessions then peers will be able to exchange Refresh Messages. Some vendors you have to explicitly configure this, in Cisco you need to configure soft-reconfiguration whereas with Juniper it is set by default within JunOS.

BGP Attributes

Unlike other Routing Protocols, BGP primary function is to find the best path to a destination and not the shortest path. BGP uses a number of attributes to calculate the best path for any given destination prefix. These attributes can be broken down into 4 types:

Well Known Attribute Types
Well known Mandatory These attributes must be known and understood by all BGP speakers. Additionally must exist within the BGP update messages.

Attributes classed as Well Known Attributes:

  • Origin
  • AS Path
  • Next-Hop
Well known Optional These attributes must be known and understood by all BGP speakers. However they don’t have to exist within a BGP update message.

Attributes classed as Well Known Optional Attributes:

  • Local Preference
  • Atomic Aggregator
Optional BGP Attribute Types
Optional Transitive Attributes don’t need to be understood by a BGP speaker however the set flag(s) will need to be passed onto other neighbours.

Attributes classed as Optional Transitive:

  • Aggregator
  • Community
  • Extended Community
Optional Non-Transitive These attributes don’t need to be understood by a BGP speaker and the set flag(s) will not be passed onto other neighbours.

  • Multi Exit Discriminator
  • Originator ID
  • Cluster List
  • Multiprotocol Reachable NLRI
  • Multiprotocol Unreachable NLRI

A BGP Update message could include some, if not all, of the following attributes:

 
Message Information
 Origin (Attribute Code 1) The Origin Attribute confirms the source of the route aka where the route was learnt from. The Origin of a route can either be:

  1. I: Internal (0) The Route is learnt from IGP

  2. E: External (1) The Route is learnt from EGP

  3. ?: Incomplete (2) The Route is learnt by something that isn’t by Internal or External methods

The rule used for Origin is that: Internal is better than External which is better than Incomplete

 AS Path (Attribute Code 2) AS Path is a list of AS numbers that are between the source AS router to the our own AS. The AS Path is primary usages are to prevent Routing Loops, assist in the Path Selection and Policy Based Routing (PBR). BGP router will drop any routes received where it can see its own AS number within the AS Path this is how Routing Loops are prevented. The path enables the router to make policy decisions based on the presence of certain AS’s within the path. Additionally routes with a shorter AS Path are preferred over routes with longer AS Path
Next-Hop (Attribute Code 3) This Attribute contains the IP address of the BGP peer that advertises the route. The Next-Hop is used for reachability and reliable of for the BGP session. For eBGP it is usually the peering address associated with the physical link with another AS. iBGP works differently as you can have situations where due to rules with iBGP the next-hop address isn’t reachable due to learning the route from another iBGP peer, in this situation the Next-Hop can be changed by policy.
Multi Exit Discriminator (Attribute Code 4) Multi Exit Discriminator (MED) is used when there are more than one route to the same upstream AS. The route with the lowest MED value is always preferred by default.
Local Preference (Attribute Code 5) Local Preference is an important attribute as it is the first attribute evaluated in the Path Selection Process. Local Preference is used for Infra-AS traffic communications for BGP session. As the name, suggests is only used to influence traffic within an AS. Oddly BGP prefers routes with the Highest Local Preference.
Atomic Aggregator (Attribute Code 6) Atomic Aggregator attribute is a notification that tells other BGP speakers within the AS-Path that some information has been lost and/or changed due to route aggregation. This may affect the best path selection because a less specific route was selected over more specific route.  
Aggregator (Attribute Code 7) Aggregator attribute is set when an advertised route has been aggregated. This attribute contains the AS number and Router-ID of the Router that has performed the aggregation
Communities (Attribute Code 8) Community attribute is tag that is use to modify, filter and/or influence a common group of IP Prefix(es) to act in a user defined way. Communities uses 4-octets of space to represent its value. Communities are used in conjunction with PBR. A community is 32-bit value, that is common defined as AS/IP-address:User-defined ie 100:1 or 192.168.100.1:1. 100 would be the AS or 192.168.100.1 being the device loopback address with 1 being a value significant within AS100.
Originator ID (Attribute Code 9) Originator attribute is a loop prevention mechanism used within iBGP network using a Route Reflector. The Route Reflector attaches if own Router-ID to routes, so if it receives a route with its own Router-ID it will ignore the route.
Cluster List (Attribute Code 10) Cluster List similar to the Originator ID attribute is a loop prevention mechanism however if an iBGP network is used clustered set of Route Reflectors then routes have the Route Reflectors Cluster ID attached to the advertised routes.
Multi-Protocol Reachable NLRI (Attribute Code 14) Multi-Protocol Reachable NLRI has two main functions as defined in RFC 4760:

  1. Negotiates what non IPv4 unicast families will be announced between two BGP peers.

  2. Defines the Network Layer Address of the router that should be the next-hop of the destination families. Ie if you have advertised l2vpn bgp family the next-hop for this bgp family will be defined within this attribute.

When this attribute is used in a BGP Update message, the Origin and AS Path attributes have to be included. Local Preference attribute is additionally added to Update messages for iBGP peering sessions.

Multi-Protocol Unreachable NLRI (Attribute Code 15) Multi-Protocol Unreachable NLRI attribute is used to withdraw any BGP families that are no longer being advertised between BGP peers.
Extended Communities (Attribute Code 16) Extended Communities are the same as Community attribute however it has 8 octets of space to represent the community compared to 4 octets with normal communities. This allows 64-bit value, it can be represented as Type:Global-Administrator:Local-Administrator. It is important to note that you have set amount of bits you can use. You will have 16 bits for the Type, 16 bits, for the Global-Administrator (commonly the ASN/IP address) and 32 bits, for the Local-Administrator (commonly user defined).   

BGP Path Selection

When a destination prefix reached by multiple routes via BGP by default only one path will be advertised into the Routing Table. With this in mind BGP has used its Route Selection Algorithm to determine what path will be installed into the Routing Table. The algorithm uses the following steps:

  • Prefer the highest Local Preference Value
  • Checks what path has shortest AS Path
  • The Route with the Lowest Origin Value
  • If the route has a Lower MED
  • If the Prefix is learnt via eBGP is preferred over being learnt via iBGP
  • The path with the better exit out of the local AS. This means that the underlying IGP metric cost is taken into consideration, the path with the lowest IGP is preferred
  • The eBGP route that has the longest uptime or prefer the routes from the peer with lowest Router ID
  • Prefer routes with the shortest Cluster List Length. This is when you use a Route Reflector within your iBGP peering session
  • Prefer routes from a peer with the lowest IP Address

Some vendors have their own vendor specific additions to the path selection algorithm. Cisco use Weight before checking Local Preference and Juniper verify that the Next-Hop is reachable before checking Local Preference. With JunOS, if the Next-Hop isn’t verified then the route is set as a Hidden route and will need investigating.

Share this:
Share

What is BGP FlowSpec?

Reading Time: 5 minutes

I recently messed about with some Junos Automate Scripts that one of my colleagues had previously been working on, that could be used to add static routes to enable Remote Triggered Blackhole (RTBH) Filtering (which can be found here), and I found it was a bit rough around the edges (for people who aren’t cli junkies). As I do, I started looking into RTBH and saw that it’s a heavy-handed solution in trying to combat DDoS attacks against a network. RTBH technology has been around for a number of years now and has been defined in RFC 3882 and RFC 5635. In its most basic of terms, you can either blackhole all traffic from a source address and/or to a destination address by injecting the attacking/attacked prefix into BGP with a community that will rewrite the next-hop to a pre-configured discard route on edge routers. If you have massive DDoS trying to block every source address, it would be like going fishing with a shotgun. By blocking the destination address the attacker will have got their desired outcome. With that in mind, using RTBH is ideally a last resort solution. There is an alternative more subtle way of blocking unwanted attack traffic from our network. This alternative method is known as BGP FlowSpec.

What is BGP FlowSpec

BGP FlowSpec is defined in RFC 5575. RFC 5575 defines a new Multi-Protocol BGP Extension MP-BGP, in addition, with new Network Layer Reachability Information NLRI. The new NLRI collects 12 types of Layer 3 and Layer 4 details that are used to define a Flow Specification then actions are assigned to these routes dependant on the user’s needs. If you wanted to look at FlowSpec in a simple form, it is a firewall filter that is injected into BGP to filter out specific port(s) and protocol(s) just as a normal ACL would do. BGP uses NLRI to exchange routing details between BGP speakers, each of the MP-BGP Extensions have their own NLRI details that are identified by their Address Family Indicator AFI and Subsequent Address Family Indicator AFI. Usually IPv4 unicast routes (also known as BGP families) are the default for BGP peers, if non IPv4 unicast routes need to be exchanged ie IPv6, EVPN, L2VPN, FlowSpec routes, then MP-BGP defines the relevant NLRI of the router that should have the next-hop of the destination families. This had been defined in RFC 2858 and RFC 4760. As stated above, as of writing, there has been 12 NLRI types defined for BGP FlowSpec, these fields will be added to NLRI field within the BGP Update Message and advertised to peers. In addition, FlowSpec does not support IPv6 yet.

FlowSpec NLRI Types

These are the 12 FlowSpec NLRI types:

Type NLRI Component
1 Destination Prefix
Defines the destination prefix to match
2 Source Prefix
Defines the source prefix
3 IP Protocol
Contains a set of {operator, value} pairs that are used to match the IP protocol value byte in IP packets.
4 Port
This is defines whether TCP, UDP or both will be packets will be influenced
5 Destination Port
Defines the destination port that will be influenced by FlowSpec
6 Source Port
Defines the source port that will be influenced by FlowSpec
7 ICMP Type
8 ICMP Code
9 TCP flags
10 Packet Length
Match on the total IP packet length (excluding Layer 2 but including IP header)
11 DSCP
Match on the Class Of Service flag
12 Fragment Encoding

NOTE: Not all 12 types have to be defined for FlowSpec to be enabled

FlowSpec Actions

RFC 5575 has defined 4 minimum Actions that routes matching FlowSpec NRLI types can take. These actions are carried as BGP extended communities added to the FlowSpec route. These actions are:

Traffic-Rate Community

The Traffic-Rate community is non-transitive, that tells the receiving BGP peer, what to rate limit matching traffic to. If the traffic needs to be discarded or dropped, this will be limit of 0 should be used.

Traffic-Action Community

The Traffic-Action community is used to sample defined traffic. This allows sampling and logging metrics to be collected from the FlowSpec route, that could be used to get a better understand of the attack traffic.

Redirect Community

The Redirect community allows the FlowSpec traffic to be redirected into a Virtual Routing and Forward Instance VRF. As the same Route-Targets and Route-Distinguisher can be used, you are able to import routes into a dedicated blackhole VPN or any other VPNv4.

Traffic-Marking Community

The Traffic-Marking community is used to modify the Differentiated Service Code Point DSCP bits of a transiting IP packet to the defined value. This could be used to set to FlowSpec routes to highest discard probability, allowing traffic not to dropped/discarded until co

FlowSpec Rule Ordering

It is important to note, that unlike normal firewall filters, FlowSpec routes use a different method of ordering rules. Most firewall filters and/or ACLs use the top-down approach, where in, once the filter has a match any other rules afterward are not inspected. With FlowSpec a deterministic algorithm to order the rules is used. By comparing the left component of each FlowSpec NLRI, the algorithm will use the following details to order FlowSpec Routes:

    1. If the types differ, the lowest type is used. If the types are the same then component values within that component are compared
    2. For IP values, the lowest IP prefix is chosen. If the IP addresses are the same then most specific prefix is used
    3. For all other types, the binary string of the contents is compared to determine the order

Validation Checks

Validate checks within FlowSpec are important, because you could get into a situation where, if no validation checks are done, FlowSpec route(s) could be injected by an attacker that doesn’t own a set of prefix(es) that could blackhole traffic. Like any other unicast BGP route, the next-hop address must resolve for the route to be usable, as per the normal BGP path selection process. In addition, to a valid next-hop, RFC 5775 has defined the follow must be valid of a Flow Specification:

    1. The originator of the flow specification matches the originator of the best-match unicast route for the destination prefix embedded in the flow specification.
    2. There are no more specific unicast routes, when compared with the flow destination prefix, that have been received from a different neighbouring AS than the best-match unicast route, which has been determined in step 1

The overall goal is to confirm that the originator of the FlowSpec route is the same as the originator of the BGP unicast route, this is done by either using BGP’s AS Path attribute or if that isn’t present (in iBGP situation) then the Peering IP address is used.

FlowSpec and Junos

Configuring FlowSpec on a JunOS device is actually quite straightforward. I’m being naughty and I don’t actually have a topology set up to show the full verification ‘show command’ outputs on the cli, but when I get the time to set something up, I’ll be back to edit this post. With all that said, Let’s getting cracking :p

The scenario is that we have an attack from 172.90.87.15 on TCP port 80 to the web-server 8.9.0.1. First we will inject a FlowSpec route to discard all TCP port 80 traffic to 8.9.0.1 when the source is from 172.90.87.15. We will need to make sure that we can order the terms as per the RFC requirement, this is done under the show routing-options flow stanza:

[email protected]# show routing-options flow                       
term-order standard;

Then enable MP-BGP family flow to BGP group

[email protected]# show protocols bgp group test 
type internal;
family inet {
    unicast;
    flow

Next configure the FlowSpec Route under routing-options flow route stanza:

[edit routing-options flow route test]
[email protected]# show 
match {
    destination 8.9.0.1/32;
    source 172.90.87.15/32;
    protocol tcp;
    port 80;
}
then discard;

With these are the options available under match and then flags. You will note that they are largely the same flags that were stated in the RFC

Match FlagsThen Flags
[edit routing-options flow]
[email protected]# set route test match ?  
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  destination          Destination prefix for this traffic flow
+ destination-port     Destination TCP/UDP port
+ dscp                 Differentiated Services (DiffServ) code point (DSCP) (0-63)
+ fragment             
+ icmp-code            ICMP message code
+ icmp-type            ICMP message type
+ packet-length        Packet length (0-65535)
+ port                 Source or destination TCP/UDP port
+ protocol             IP protocol value
  source               Source prefix for this traffic flow
+ source-port          Source TCP/UDP port
+ tcp-flags            TCP flags
[edit routing-options flow]
[email protected]# set route test then ?                          
Possible completions:
  accept               Allow traffic through
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  community            Name of BGP community
  discard              Discard all traffic for this flow
  next-term            Continue the filter evaluation after matching this flow
  rate-limit           Rate in bits/sec to limit the flow traffic (9600..1000000000000)
  routing-instance     Redirect to instance identified via Route Target community
  sample               Sample traffic that matches this flow

Once committed you will be able to verify Flowspec routes because they are installed into their own routing table inetflow.0 and if dedicated, VRF for FlowSpec routes and the table will be under routing-instance-name.inetflow.0. You can also check FlowSpec firewall filter by running the command show firewall filter __flowspec_default_inet__

FlowSpec TableFlowSpec Firewall Filter
[email protected]> show route table inetflow.0 extensive 

inetflow.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
8.9.0.1,172.90.87.15,proto=6,port=80/term:3 (1 entry, 1 announced)
TSI:
KRT in dfwd;
Action(s): discard,count
        *Flow   Preference: 5
                Next hop type: Fictitious
                Address: 0x94359c4
                Next-hop reference count: 6
                State: 
                Local AS: 65123 
                Age: 4:10 
                Validation State: unverified 
                Task: RT Flow
                Announcement bits (1): 0-Flow 
                AS path: I
                Communities: traffic-rate:0:0
[email protected]> show firewall filter __flowspec_default_inet__    

Filter: __flowspec_default_inet__                              
Counters:
Name                                                Bytes              Packets
8.9.0.1,172.90.87.15,proto=6,port=80                    0                    0
Share this:
Share

Configuring BGP using Bird on Ubuntu 14.04LTS

Reading Time: 3 minutes

As part of the QFX testing I’ve been doing at work, I’ve had to do the testing of running BGP between a switch and server. Although one of my seniors advised I could just test BGP between two switches, as BGP is BGP, and should work whether it’s a switch or server, the protocol is the same and should simply work. However, given the chance to learn something new, I went with it and thought this would be the perfect chance for a new post! I found out that our production servers use EXaBGP daemon. I looked into the configuration and the specs for EXaBGP…. Let just say was pretty lost very quickly (being polite)! I then started looking into alternative daemons and found BIRD. I had heard of BIRD before and from my research it didn’t look as complex as EXaBGP.

The BIRD project was developed as a school project at the Faculty of Mathematics and Physics at Charles University in Prague, with major contributions from developers Martin Mares, Pavel Machek, Ondrej Zajicek, Libor Forst and Ondrej Filip. Designed for a UNIX based system, BIRD is an open source daemon that runs an Internet protocol suite. It can run a number of Dynamic Routing Protocols: BGP, OSPF, RIP, Static Routing, Both IPv4 and IPv6 and can hold Multiple Routing Tables.

I had found a perfect post from mindless.gr that went into detail on how to configure a simple IPv4/IPv6 BGP session using BIRD, which was exactly what I needed.

With that in mind, this post will detail how to configure a simple IPv4 BGP session using BIRD on Ubuntu 14.04LTS

Let’s get Cracking 😛

You will need sudo and root privileges

You will be able to make the changes here with sudo privileges. You need to install the BIRD package, which is nicely available via Ubuntu’s Advanced Packaging Tool apt-get install bird

[email protected]:~$ apt-get install bird6

By default any modern Linux distribution will have IP Forwarding disabled; we’ll need the server to basically act as a router and we’ll need to have IP Forwarding enabled. Running the command sysctl net.ipv4.ip_forward=1 will enable IPv4 forwarding. You can also make this a permanent change so that on boot, IP forwarding will always been enabled. You will need to edit /etc/sysctl.conf file. Check below for what you need to look out for and uncomment:

[email protected]:~$ cat /etc/sysctl.conf
{...}
# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

# Uncomment the next line to enable packet forwarding for IPv6
#  Enabling this option disables Stateless Address Autoconfiguration
#  based on Router Advertisements for this host
#net.ipv6.conf.all.forwarding=1
{...}

Backup the original bird.conf by running something like cp bird.conf bird.old.conf (always need to cover your ass :p lol)

The config file looks quite complex at first appearance (when this was written I didn’t have a clue about any of it!!). If you want more detailed information about the config file and the different options available you can find them on the Bird Internet Routing Daemon: User’s Guide Page

For my example, I needed a simple configuration that had the server advertise 4 routes (3 x /24 and /22) and accept all routes. This was the same setup on the switch side, which is a Juniper QFX5100.

To edit the bird.conf file, you’ll need it to be root. I tried a sudo nano however I got Permission Denied! So I sudo -s down to root and edited the conf file

[email protected]:~$ sudo -s
[sudo] password for marquk01: 
[email protected]:~# nano /etc/bird/bird.conf
Bird.confSwitch Configuration
[email protected]:~$ sudo cat /etc/bird/bird.conf
[sudo] password for marquk01: 
/*
 *	This is an example configuration file.
 */

# Yes, even shell-like comments work...

# Configure logging
log syslog all;

# Override router ID
router id 192.31.1.3;

# This pseudo-protocol performs synchronization between BIRD's routing
# tables and the kernel. If your kernel supports multiple routing tables
# (as Linux 2.2.x does), you can run multiple instances of the kernel
# protocol and synchronize different kernel tables with different BIRD tables.
protocol kernel {
#	learn;			# Learn all alien routes from the kernel
	persist;		# Don't remove routes on bird shutdown
	scan time 20;		# Scan kernel routing table every 20 seconds
#	import none;		# Default is import all
	export all;		# Default is export none
#	kernel table 5;		# Kernel table to synchronize with (default: main)
}

# This pseudo-protocol watches all interface up/down events.
protocol device {
	scan time 10;		# Scan interfaces every 10 seconds
}

# Static routes (again, there can be multiple instances, so that you
# can disable/enable various groups of static routes on the fly).
protocol static static_bgp {
	route 192.70.0.0:255.255.252.0 via 192.31.1.3;
	route 192.70.1.0:255.255.255.0 via 192.31.1.3;
	route 192.70.1.0:255.255.255.0 via 192.31.1.3;
	route 192.70.2.0:255.255.255.0 via 192.31.1.3;
	route 192.70.3.0:255.255.255.0 via 192.31.1.3;
}

#BGP Configuration
protocol bgp {
        import all;
        export where proto = "static_bgp";

        local as 3000;
        neighbor 192.31.1.2 as 4000;
}
set interfaces xe-0/0/4 description "km-vm3 10GB"
set interfaces xe-0/0/4 enable
set interfaces xe-0/0/4 unit 0 family inet address 192.31.1.2/31
set routing-options static route 192.69.0.0/24 reject
set routing-options static route 192.69.1.0/24 reject
set routing-options static route 192.69.2.0/24 reject
set routing-options static route 192.69.3.0/24 reject
set routing-options autonomous-system 4000
set protocols bgp enable
set protocols bgp local-as 4000
set protocols bgp group test local-address 192.31.1.2
set protocols bgp group test family inet unicast
set protocols bgp group test neighbor 192.31.1.3 export BGP-Export
set protocols bgp group test neighbor 192.31.1.3 peer-as 3000
set policy-options policy-statement BGP-Export from protocol static
set policy-options policy-statement BGP-Export then accept

Having configured the switch and the server, I needed to enable to the bird daemon. This was done by running the command invoke-rc.d bird start

[email protected]:~$ invoke-rc.d bird start

To enter the bird client, you will need to run the command birdc and from there you’re able to run a verification command to check that routes are being advertised and received from server to the switch.

[email protected]:~$ sudo birdc
[sudo] password for marquk01: 
BIRD 1.4.0 ready.
bird>

From the bird client, you can run show route to see the RIB table and to check the BGP status you will run show protocols all bgp1

show routeshow protocols all bgp1
bird> show route 
192.69.0.0/24      via 192.31.1.2 on eth1 [bgp1 11:35:14] * (100) [AS4000i]
192.69.1.0/24      via 192.31.1.2 on eth1 [bgp1 11:35:14] * (100) [AS4000i]
192.69.2.0/24      via 192.31.1.2 on eth1 [bgp1 11:35:14] * (100) [AS4000i]
192.69.3.0/24      via 192.31.1.2 on eth1 [bgp1 11:35:14] * (100) [AS4000i]
192.70.0.0/22      via 192.31.1.3 on eth1 [static_bgp 13:50:05] ! (200)
192.70.1.0/24      via 192.31.1.3 on eth1 [static_bgp 11:35:09] ! (200)
192.70.2.0/24      via 192.31.1.3 on eth1 [static_bgp 11:35:09] ! (200)
192.70.3.0/24      via 192.31.1.3 on eth1 [static_bgp 11:35:09] ! (200)
bird> show protocols all bgp1
name     proto    table    state  since       info
bgp1     BGP      master   up     11:35:14    Established   
  Preference:     100
  Input filter:   ACCEPT
  Output filter:  (unnamed)
  Routes:         4 imported, 4 exported, 4 preferred
  Route change stats:     received   rejected   filtered    ignored   accepted
    Import updates:              4          0          0          0          4
    Import withdraws:            0          0        ---          0          0
    Export updates:              9          4          0        ---          5
    Export withdraws:            0        ---        ---        ---          0
  BGP state:          Established
    Neighbor address: 192.31.1.2
    Neighbor AS:      4000
    Neighbor ID:      10.1.0.241
    Neighbor caps:    refresh AS4
    Session:          external AS4
    Source address:   192.31.1.3
    Hold timer:       52/90
    Keepalive timer:  18/30

On the switch, we can check when the BGP session is up and can see what routes that are being adverted and what routes are being received:

show bgp summaryshow route advertising-protocol bgpshow route receive-protocol bgp
{master:0}
[email protected]> show bgp summary group test    
Groups: 1 Peers: 1 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0               
                       4          4          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.31.1.3             3000         79         79       0       1       33:43 4/4/4/0              0/0/0/0
{master:0}
[email protected]> show route advertising-protocol bgp 192.31.1.3

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 192.69.0.0/24           Self                                    I
* 192.69.1.0/24           Self                                    I
* 192.69.2.0/24           Self                                    I
* 192.69.3.0/24           Self                                    I
{master:0}
[email protected]> show route receive-protocol bgp 192.31.1.3                                                          

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 192.70.0.0/22           192.31.1.3                              3000 I
* 192.70.1.0/24           192.31.1.3                              3000 I
* 192.70.2.0/24           192.31.1.3                              3000 I
* 192.70.3.0/24           192.31.1.3                              3000 I

You can enable BIRD for IPv6 as well. The editing and process is exactly the same however you’ll need to edit the /etc/bird/bird6.conf file with the appropriate IPv6 addressing. To enter the IPv6 BIRD client you’ll use the command birdc6.

Being able to spin up VMs and have them configured as “dumb” BGP nodes is such a useful thing to have in a lab when you don’t have as many switches/routers as you need. From what I can see Bird can be a extremely useful tool for connecting BGP routes and I see that many Internet Exchange Points (IXPs) such as London Internet Exchange (LINX), London Network Access Point (LONAP), Deutscher Commercial Internet Exchange (DE-CIX), Amsterdam Internet Exchange (AMS-IX) and many more use BIRD for their Route Server. When I get a chance I will defiantly look into how to get the most out of BIRD!

You can find all the documentation and user guides on BIRD on the official website here

Share this:
Share