Cisco BGP soft-reconfiguration and received-routes relation

A while ago I received the following question:

“Why I’m not seeing the prefixes received from the BGP peer when using the show ip bgp neighbors x.x.x.x received-routes while the soft-reconfiguration inbound is not enabled?”

I must admit that I had to stop and think for a second before giving my response.

Simple BGP

For the above diagram I have a simple BGP configuration:

Focus is on the secondary router. I’m trying to see what prefixes I receive from my BGP neighbor, so I rapidly hit the following command:

OK, that’s not good. Am I missing the command? Let’s see:

-> received-routes – Display the received routes from neighbor

OK, I know the soft-reconfiguration inbound is not enabled, but what has this to do with the fact that the command is not showing me what routes I receive from BGP neighbor?

Let’s recall what “soft-reconfiguration inbound” command actually does.

BGP soft-reconfiguration inbound
*Cisco BGP-4 Command and Configuration Handbook

According to the above explanation, if you have an inbound policy (like a route-map) applied to a BGP neighbor and you change that policy, you need to clear the BGP session before it take effect. This is the procedure without having “soft-reconfiguration inbound” configured. I remember it like this and most of the network engineers out there remember this behavior associated with the “soft-reconfiguration inbound” command.

Still, I just want to see what routes I received from BGP neighbor and according with “sh ip bgp neighbors 192.168.0.1 received-routes” description is the right command . I have no inbound policy on R2 for R1 BGP neighbor.

A less remembered fact about the “soft-reconfiguration inbound” command is that when added, the router begins to store updates from the specified neighbor. These updates are unmodified by any existing inbound policies so that the router can correctly apply the new policies when soft reconfiguration is triggered.

Where are these updates stored?

In the BGP Adj-RIB-in (Adjacent Routing Information Base, Incoming) table. So, what the “received-routes” command does actually is looking in the BGP Adj-RIB-in table for the received routes from the BGP neighbor. I consider that the “received-routes” command has an ambiguous explanation leading to confusion.

When “soft-reconfiguration inbound” is not present, the BGP router does not store anything in Adj-RIB-in. Rather it process the update and discard the Adj-RIB-in table, but not before adding the information in the Loc-RIB (Local Routing Information Base) table. Knowing these facts of course the BGP router returns an error when trying to check the received prefixes using the “received-routes” command.

To check actually what’s received from BGP peer and stored in the Loc-RIB (after being processed by inbound policies) use only the “routes” parameter in the command:

-> routes – Display routes learned from neighbor

The output is what exists in the Loc-RIB table, after processed by the inbound policy.

Let me show you an example of the above explanation.

I’ll apply the “soft-reconfiguration inbound” first:

Now I’ll check again the received routes:

OK, so I have three prefixes, reflected in the Adj-RIB-in table.
Checking next the Loc-RIB tables (so the routes installed after being processed by inbound policies):

The Adj-RIB-in and Loc-RIB tables are identical.

Now, I’ll apply an inbound policy that will filter the 3.3.3.3 prefix.

OK, we have the “soft-reconfiguration inbound” in place, so the inbound policies should be applied automatically denying the 3.3.3.3 prefix.

The above output is what we receive from BGP peer. Notice that the 3.3.3.3 prefix is still there, in the Adj-RIB-in table, as the inbound policies are not applied yet. The only visible change is the missing > sign (best).

Now we can see that the inbound policy is working fine as the 3.3.3.3 prefix is not installed in the Loc-RIB table. This is also the explanation why the > (best) sign was missing from the 3.3.3.3 prefix in Adj-RIB-in.

I hope you understood the logic behind the confusion which these commands “received-routes” and “routes” and their explanation in IOS is creates.

Please let me know in Comments if you have any questions.

IPsec VPN Mikrotik to Linux

After writing the Mikrotik IPsec VPN article and I got some questions about how Mikrotik will work with a Linux device to build an IPsec VPN. I did notice that the questions were more oriented for a copy / paste solution, so I’ll provide one that it’s working. If you need more details about why the solution is like it this, please let me know.
Also don’t forget to customize the solution as you need.

I’ll start with the same topology like in the last post, just that the right side now it’s a Linux device.

Mikrotik-IPsec-VPN-Linux

Please consider the minimum ports needed to be open on your firewall from my earlier article. Just don’t forget to open these ports also on the Linux device.

First let’s configure the Mikrotik.

The IPsec Proposal

CLI

GUI

IP > IPsec > Proposals

The IPsec Policy

CLI

GUI

IP > IPsec > Policies

The IPsec Peer

CLI

GUI

IP > IPsec > Peers

Now, the Linux part. I’m using Ubuntu, but I’m not going to advocate here for one flavour or another. So, just use any device with Linux or you try solutions such as Amazon AWS. Install Openswan (compile it from source or install via your Linux flavour package system).

The main file for Openswan is ipsec.conf. For me this file is in /etc, but I assume it can reside in another location.

For the above example, the ipsec.conf file looks like this:

You need to associate the keyword “left” with “local” and “right” with “remote” and it will be easier to read the configuration above.

Also in the /etc location I have another file called ipsec.secrets which has the pre-shared secret key:

This is the minimal configuration that I need to apply to have the IPsec VPN up and running. I’m sure that it can be fine tuned to add more security or features, but that is not in scope of this post.

As always if you have problems please let me know in Comments.

Mikrotik IPsec VPN

If you did not hear yet about Mikrotik I can’t say I blame you. Not exactly something you’ll find in SOHO network shops next to brand like TP-Link, Linksys or Netgear. Mikrotik is a company
in Latvia that produce network hardware under the name of RouterBOARD. The devices are excellent and the RouterOS support an amazing amount of feature for a SOHO product.

As recently I did develop a small VPN network based on IPsec and using Mikrotik RB951G-2HnD platform, I had the idea to put together a short how to for the enthusiast out there who wants to try these products. Now, I’m not saying that this is the best or the only approach, but it’s a start from which you can develop your own fine tuned solution.

Let’s assume that we have the following topology:

Mikrotik-IPsec-VPN

The idea is to build a VPN using IPsec technology between the two routers. The RouterOS version is 6.23, so earlier versions may not support all features described here, but I’ll try to point this where is the case.

As some people are more comfortable with GUI and others with CLI, I’ll describe both methods. If you are following this blog post, I assume that you are already a bit familiar with RouterOS and your Mikrotik device is connected at least to Internet.

In this example I’ll focus on the left side of the diagram. The right side is configured in the same way.

Before going into the real IPsec configuration, please be sure to have the following ports open on your Mikrotik firewall:

You may not use these protocols after following this blog post, but it’s OK to have them open if you want to experiment. They can be closed later after you decide what to use, but we don’t want this as a blocking point and force us into troubleshooting.

You can allow the following ports into Mikrotik firewall as follow into CLI:

The place-before=0 is to force the rule on the top of your Input table.

On GUI, check the

IP > Firewall > Filter Rules > Input table

Another thing to remember if you’re using NAT like in the picture above is that the LAN subnets have to be allowed to communicate directly, before they are pass to masquerade rule.

CLI

GUI

IP > Firewall > NAT

Let’s start now with the IPsec configuration part.

First let’s define a new IPsec Proposal policy. There is a default one which comes preconfigured but I would like to use my own.

CLI

GUI

IP > IPsec > Proposals

As mentioned earlier in this post, depending on your RouterOS version, you can have here different options. Just pick what suits your needs.

Next we need to define an IPsec Policy.

CLI

GUI

IP > IPsec > Policies

I think that settings are obvious, just be careful to correctly pick the sources (SRC ADDR and SA SRC). The SRC values are from local site while the DST part has to be the remote site.

Last we need to define a least one IPsec Peer

CLI

GUI

IP > IPsec > Peers

Be careful that if you are on version RouterOS 5.xx (just as an example) the Encryptions Algorithm field supports only one value and not multiple like configured above. I did especially to highlight that there are differences depending on the RouterOS version. Nevertheless the baseline for IPsec VPN configuration remains the same.

If you have questions or something does not work as explained please let me know in Comments.

New GNS3 1.0 Beta 1

It appears that there are some significant changes ongoing with GNS3.

As mentioned by the GNS3 CEO and co-founder Stephen Guppy on 11th of August 2014, the new GNS3 will be more polished and will migrate to a multi-vendor emulation platform. For those using this tool, it’s a well known fact that GNS3 was mainly focused to emulate Cisco platform, evolving to support vPC and VirtualBox virtual machines.
 
They have a new very polished website accessible at new.gns3.net where you can also download the GNS3 1.0 Beta 1 software.

I did grab a copy of the Beta 1 and installed on a Windows system (the only one which had right now on hands). You can see a screenshot below.
 
GNS3 1.0 Beta 1
 
To be honest, first impression is that not much did change, except some buttons / icons here and there. Of course this just after a quick look from my side. I will test the software in the next days and come back with an update.
 
If interested, you can check the press release from 26th of August 2014 for more details about upcoming changes in the GNS3 organisation.
 

EGP

Today I came across an old Cisco router with original IOS image. Big surprise (at least for me) when I did check what routing protocols are supported on this router:

EGP protocol

I was out of the game, or better not even yet had discover the networking games, when the EGP was still out there and available to be configured on the Cisco routers.

I hope to bring a smile on your face or some nostalgic memories when you’ll see this :)