I will be using Vyatta as the routing platform throughout this series of posts, I will go through the details of installing and configuring Vyatta there are plenty of documents on the internet that can help with that. Suffice to say you will need the router installed and configured, and a layer two adjacency to your upstream provider, as this will generally be the case if you are buying transit and it is delivered via a cross connect or similar hand off to your location.
One you have your cross connect and the vlan tagged/trunked to your router’s interface (or the hand off plugged directly into your router) you should be good to go.
To complete the configuration we will need the following information:
- The carrier/upstream ASN
- The IP address assigned to your circuit by your upstream
- Your ASN
- The address space you wish to announce to the internet
In this example we will use the following information for the configuration; private address space as the prefix we are originating to the internet, private address space for the customer and carriers IP’s as well as private ASN’s, these are only used to illustrate this process they would obviously be different in a real world scenario.
- Upstream ASN: 65000
- Carriers IP: 10.1.1.1/30
- Customer IP: 10.1.1.2/30 (assigned by the carrier to our end of the circuit)
- Customer ASN: 65001
- Prefix to announce to the internet: 10.10.10.0/24
In Vyatta, like most other network operating systems, there are several steps to bring up a BGP peering and announce routes, but these steps will generally be the basic’s required for most platforms (IOS, Junos etc).
- Configure the BGP prefix list
- Configure the BGP neighbour
- Set a static route to blackhole/null0 for the prefix you are announcing
- Announce our address space into BGP
1. Configure the BGP prefix list
I usually attempt to do this as the second step however if you dont complete this step before bringing up the neighbour adjacency BGP will automatically import any routes it is being sent into your router. Usually this is not an issue if you only have one upstream provider as you will be importing either the global routing table, a subset of the global table or a default route. This is generally a question your carrier will ask you before they provision the circuit so you will be aware of this.
However if, for some reason, you want to perform any ingress filtering or alternatively you are configuring a peering session with a downstream router (a customers device perhaps) you may not want to blindly accept any routes immediately when the session is established. For this reason I find configuring the prefix list prior to configuring the neighbour information a bit cleaner.
In configure mode:
set policy prefix-list EXPORT-AS65000 rule 10 action permit set policy prefix-list EXPORT-AS65000 rule 10 prefix 10.10.10.0/24 set policy prefix-list EXPORT-AS65000 rule 10 description “Anounce my prefix to the internet” commit
The commands above do the following:
create a prefix list called EXPORT-AS65000
match the network 10.10.10.0/24 and allow this prefix to be announced to the specified neighbour
It is a good idea to name your prefix lists intelligently as a way of documenting your configuration, here we have named this prefix list by the function it is serving (EXPORT) and the ASN it is related to ie: who we are exporting routes to. You can have more than one rule pre prefix list but in this example we will only use one.
In this post we are going to assume that we will be importing whatever routes our upstream provider is going to send us, As I said before, BGP will automaticaly import all routes it is sent, so we will not go through the process of creating an import prefix list.
2. Configure the BGP neighbour
Now we have a prefix list defining the prefixes we want to announce to our neighbour we can go ahead and configure the bgp neighbour itself.
From configure mode:
set protocols bgp 65001 neighbor 10.1.1.1 remote-as 65000 set protocols bgp 65001 neighbor 10.1.1.1 soft-reconfiguration inbound set protocols bgp 65001 neighbor 10.1.1.1 prefix-list export EXPORT-AS65000 set protocols bgp 65001 neighbor update-source 10.1.1.2 commit
The above commands do the following:
Tell bgp process that the neighbour IP is 10.1.1.1
Set the remote as to 65000 (the ASN of our carrier)
Set the neighbour to use the EXPORT-AS65000 prefix list
Set the source interface for bgp updates to 10.1.1.2 (the IP address assigned by our carrier to our end of the circuit)
Configures soft reconfiguration inbound, this allows the bgp process to “refresh” the RIB without hard resetting the bgp session (a hard reset drops the session and all traffic while the neighbour ship re converges).
Soft reconfiguration is useful when making changes to a bgp peering session that is already online and passing traffic, for example, announcing a new prefix or removing an existing prefix announcement.
Once you commit this configuration you should be able to see a bgp neighbour session start and come up. You can check this with the following commands:
run show ip bgp summary
(In Vyatta if you want to run a user exec command from configure mode you can prefix the command with the run keyword).
Here you can see that the BGP session with the neighbour is up but we are yet to start exporting routes to our carrier. As I am configuring this example in a lab I have not created an prefixes to import into our router which is why you cannot see any routes being imported.
BGP router identifier 10.1.1.2, local AS number 65001 IPv4 Unicast - max multipaths: ebgp 1 ibgp 1 RIB entries 1, using 64 bytes of memory Peers 1, using 2524 bytes of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.1.1.1 4 65000 22 31 0 0 0 00:17:17 0
3. Set static route to blackhole/null0
We need to set a static route to blackhole for the prefix that we are originating to the internet. We do this to create an aggregate or summary route (according to google). This is necessary because BGP will only advertise routes that are in the routing table and a static route to blackhole/null0 will accomplish this.
Add a static route to blackhole with the following command:
set protocols static route 10.10.10.0/24 blackhole commit
4. Announce prefix into BGP
The last step is to announce the prefix with the bgp network command. This tells BGP which network to advertise:
set protocols bgp 65001 network 10.10.10.0/24 commit
You should now be able to see networks being advertised by the Customer router to the Carriers router. We can confirm this by running the following command on the customer router:
show ip bgp neighbors 10.1.1.1 advertised-routes
If this has been done correctly you will see the following output:
BGP table version is 0, local router ID is 10.1.1.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 10.10.10.0/24 10.1.1.2 0 32768 i Total number of prefixes 1
We can see also check that the carriers router is receiving our prefixes with the following command, usually you will not have access to your upstreams router to be able to check this, in this case you would use your carriers looking glass (or a another carriers looking glass if they don’t provide one), this is a website that will query a carriers router/route server and return the output to the page as if you were running the command directly on the carriers equipment.
Here is the output from our carriers router:
vyatta@Carrier:~$show ip bgp neighbors 10.1.1.2 received-routes BGP table version is 0, local router ID is 10.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, R Removed Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 10.10.10.0/24 10.1.1.2 0 0 65001 i Total number of prefixes 1
There we have it we now have a basic BGP peering session established and we are successfully advertising our prefix to our upstream who is then passing this onto the internet at large.
Footnote: Apologies for the spelling conflicts, particularly neighbour and neighbor. I am Australian and we spell this word differently to Americans which is the reason for the use of the “u” throughout the text. However so as to not confuse anyone reading the configuration examples I have left this out and used the American spelling because this is the way it is implemented in the Vyatta syntax.