BGP version 4 is the heart and soul external routing protocol of the modern Internet. It is defined in RFC1771. It supports CIDR addresses.
BGP version 4 is used to exchange routing information between autonomous systems. Autonomous systems are define as any group of networks which share administrative control and internal routing protocols. Best to think of Autonomous Systems as an organization, like a university or a company.
BGP uses TCP as its transport protocol. So BGP speaking routers maintain a TCP connection on port 179 to other BGP speaking routers. When two routers are using BGP to exchange routing information they are said to be bgp "peering".
BGP is a "Path Vector" protocol. Every Autonomous System is assigned a AS number. An AS number is a 16 bit quantity (0-65535) or (as of 2008) 32 bit quantity (written as X.Y where X and Y are 16 bit numbers). ASN's are assigned by the same folks who assign IP address blocks (ARIN in the United States). BGP uses, as its primary metric, the number of AS's it takes to reach a CIDR prefix. The AS path information is an BGP "attribute" attached to a CIDR prefix. The attribute is AS_PATH. Another important attribute is the NEXT_HOP attribute which specifies the next hop to use to reach a prefix (if BGP choose to use that prefix).
For example, 10.10.0.0/16 is announced by AS6 to AS5 and AS4 with a path of "AS6". If AS4 would announce 10.10.0.0/16 to AS5 with a path of "AS4 AS6" then AS5 would use the shorter path (directly to "AS6" instead).
Another example. AS10 receives 10.20.0.0/20 from AS12 with a path of "AS12 AS8 AS5 AS2". It also receives 10.20.0.0/20 from AS14 with a path of "AS14 AS5 AS2". So AS10 would deliver packets destined to 10.20.0.0/20 to the next hop of the shorter path AS14.
BGP can be used between AS's as an external routing protocol or within an AS as a Internal routing protocol. These are called EBGP and IBGP respectively. EBGP means you are using BGP to exchange routing information with a different Autonomous System number. IBGP means you are exchanging routing information within your Autonomous System.
BGP allows you to summarize routing information so you can hide internal routing information from your BGP neighbors and instead present a single CIDR supernet for all your internal routes.
For Cisco, Juniper, and most other routers there are a number of BGP attributes that can influence the choice of a the route that is chosen.
If the path specifies a next hop that is inaccessible, drop the update. Prefer the path with the largest weight. Weight is a internal attribute that is not advertised to other routers. It is applied to all routes in a router, and is usually based on the routing protocol If the weights are the same, prefer the path with the largest local preference. Local preference is an internal attribute that applies only to BGP routes. If the local preferences are the same, prefer the path that was originated by BGP running on this router. If no route was originated, prefer the route that has the shortest AS_path. If all paths have the same AS_path length, prefer the path with the lowest origin type (where IGP is lower than EGP, and EGP is lower than incomplete). If the origin codes are the same, prefer the path with the lowest MED attribute. MED is set by the next hop router that is advertising the route and is usually related to the peers internal routing metrics. If the paths have the same MED, prefer the external path over the internal path. If the paths are still the same, prefer the path through the closest IGP neighbor. Prefer the path with the lowest IP address, as specified by the BGP router ID.
The key components of a BGP configuration are:
On JunOS BGP routing is done in the protocols bgp section. An example. Here we have a JunOS router which is in AS 65501 to peer with a neighbor service provider which is AS 1. We want to announce our address space 10.80.0.0/16 to the server provider and we want to accept all routes from the service provider.
Our border router has two interfaces, 10.70.0.1/30 is used to connect to the service provider and 10.80.1.1/24 connects to our internal network.
routing-options {
aggregate {
route 10.80.0.0/16; here we configure what amounts to a null route for
the /16 we want to advertise
}
static {
route 0.0.0.0/0 reject; here we add a static default route to discard since we will have a full default free feed
}
}
protocols {
bgp {
group isp { use a different group for different types of connections
type external; Specify internal for IBGP and external for EBGP
local-address 10.70.0.1; Specifiy the local address for the connection
export send-bgp-and-our-net; link to a policy-option policy statement for export policy
local-as 65501; specify our AS
neighbor 10.70.0.2 { specify neighbor address and remote AS
description "Link to ISP";
peer-as 1;
}
}
}
}
policy-options {
policy-statement send-bgp-and-our-net {
term ouras {
from protocol aggregate; send our aggregate route to neighbors
then {
next-hop self; use our local address as next-hop
accept;
}
}
term learned-from-bgp {
from protocol bgp; send routes learned from other bgp connections
then {
next-hop self; use our local address as next-hop
accept;
}
}
term reject {
then reject; dont send anything else
}
}
}
First under routing options we create an aggregate route for the full CIDR address of our network. Then under protocols bgp we configure the peering. We create a group we decide to call "core" and configure the appropriate local-address/local-as and neighbor statements. We specify an policy option policy statement called "send-our-net" which when applied as the export map will tell bgp to send our aggregate to the neighbor. We don't need to specify a import policy since we are accepting all routes from the ISP. By default we accept all unless restricted via a policy-statement. By default we send none unless permitted via a policy-statement.
Here is an example for a local (IBGP) peering between 10.80.0.1 (in AS 65501) and 10.80.0.2 (also in AS65501)
protocols {
bgp {
group internal { use a different group for different types of connections
type internal; Specify internal for IBGP and external for EBGP
local-address 10.80.0.1; Specifiy the local address for the connection
export send-bgp-and-our-net; link to a policy-option policy statement for export policy
local-as 65501; specify our AS
neighbor 10.80.0.2 { specify neighbor address and remote AS
description "Link to ISP";
peer-as 65501;
}
}
}
}
Here are some commands to review the bgp setup
show bgp summary show route received-protocol bgpThe first will show you a brief summary of your bgp neighbors. The last two can be used to review the routes you are sending or receiving from a particular neighbor via bgp.show route advertised-protocol bgp
On cisco's and quagga routers the BGP configurations are very similar to each other . If we wanted a cisco router which is the border to AS 65501 and with address 10.71.0.1/30 on eth0 and with eth1 connected to the net 10.81.0.0/16 wants to peer with a service provider which has a address of 10.71.0.2/30 in AS 1 you might do something like this:
ip route 10.81.0.0 255.255.0.0 null0 create a null route so we have the /16 in our routing table to advertise router bgp 65001 local AS will default to process number network 10.81.0.0 mask 255.255.0.0 specify the network blocks to announce. We will specify our groups /16 neighbor 10.71.0.2 remote-as 1 specifiy remote ip and AS if remote AS != local AS then EBGP neighbor 10.71.0.2 description EBGP Link to service provider add a description neighbor 10.71.0.2 soft-reconfiguration inbound this peer will all allow soft-reconfiguration inbound so we can change parameters without having to clear the entire bgp process neighbor 10.71.0.2 next-hop-self use our local address as the next hop for advertisements to this neighborThe router bgp line starts a bgp process and gives it a process ID of the AS we are representing. The network statement says which base network we want to advertise. We will also need to insure a route matching this network is in our routing table. The easiest way to do this is with a null static route. Under the router bgp stanza we set parameters for the neighbor.
You can also use BGP to communicate routing information between routers within your AS. This is IBGP peering. The peer AS is equal to your AS. This can be used to allow your border routers to share external BGP route information that they have learned, without having to inject that external information into your normal IGP (like OSPF).
Here is an example of an internal BGP configuration between this router and another router in our AS with ip address 10.81.0.2.
router bgp 65001 local AS will default to process number network 10.81.0.0 mask 255.255.0.0 specify the network blocks to announce. We will specify our groups /16 neighbor 10.81.0.2 remote-as 65001 specifiy remote ip and AS if remote AS = local AS then IBGP neighbor 10.81.0.2 description IBGP Link internal router add a description neighbor 10.81.0.2 soft-reconfiguration inbound this peer will all allow soft-reconfiguration inbound so we can change parameters without having to clear the entire bgp process neighbor 10.81.0.2 next-hop-self use our local address as the next hop for advertisements to this neighbor
Note that by default cisco BGP will send all routes learned via BGP and listed in the network statements. So we don't need to define an export policy
Here are some commands to review the bgp setup on IOS/quagga routers
show ip bgp summary show ip bgp neighbors x.x.x.x received-routes show ip bgp neighbors x.x.x.x advertised-routes
Some other notes to consider. First off, you don't have to have BGP peering between directly connected machines. You can use "multihop" BGP peering to exchange routes between machines that are not connected to each other.
In either case you need to be careful about the "next-hop" attribute and be sure that the neighbor router has a route (connected, or learned) to the next hop you advertise.