Lab

Scenario

This lab extends a LAN over VPN link to two different sites. These sites will be connected to the Internet and routed with BGP.

eBGP to “ISP router” and iBGP between the sites.

The two “sites” are my laptops and the hosts and routers running in these “sites” are Virtualbox guests. Router guests are Vyatta 6.5, servers guests Bodhi Linux.

All the routers have an IPv4 connection to “ISP-router” which is a Cisco.

IPv6 from r1a and r2b is tunneled over IPv4 link.
L2VPN between the sites is done over IPv4 link.

The end result should be that you can connect a host to either site, using the LAN prefix 2001:98:0013:004f::/64 and that host gets IPv6 Internet-connection. The connection should have automatic failover using the other link to the “ISP router”.

Network Diagram

I apologise for the crappy network diagram. I drew it as Google docs presentation and it felt a bit clumsy.

Set up the Lab

Install guests (the routers) on the two hosts.
Give routers IPv4 address.
Configure IPv4 routing so that guest routers can see each other, 0/0 points to the “ISP router”.
Try that all routers can ping each other with IPv4 addresses.

L2VPN

Create L2VPN between r3a and r4b, using the IPv4 network as transport.

IPv6 tunnels

If your virtualization software and network environment allows, you may skip this phase and give r1a and r2b their IPv6 link addresses directly. In my system I have VirtualBox and the link is over wifi. It will not allow me to directly use IPv6 in this interface.

Testing

Set up a host on both “sites”
Bring down routers, links, or the connection between sites. What happens?

My observations:

1. When I turn off routers, the routing changes to the other link immediately.

2. When I put down the main WAN link, it takes time to reroute. About a minute or two.

3. From my two “servers” the other one changes the first-hop immediately and automatically. The other one does not. Don’t know why. Both hosts are with automatic configs.

BGP AS-path prepending

BGP has its ways to choose a link to use. Which route did your routers choose to be the active one? Now we want to tell it that we would prefer to pass traffic via r1a. So put this configuration in r2b to make its path appear longer.

In this part we are going to connect a new “customer” to our network. Previous episode featured a user connected directly to one of the core routers. This time there will be CE-routers. There will be two of them, attached to two different core nodes and configured with sufficient services to handle failover in case the main connection breaks down.

IPv6 address allocation

Allocate a new prefix 2001:99:13:4c::/64, route it from the Internet router to FW and from FW to the first LAB router. This will be the IPv6 prefix used in the customer’s LAN.

Then allocate two more nets to be used as link addresses between our core routers and CE-routers: 2001:99:13:4d::/64 and 2001:99:13:4e::/64. Route them as well.

Connections and topology

Connect the new customer routers to your network. I connect these two via R6 and R8.
Configure the interfaces and define IPv6 BGP neighbors.
Our core network has ASN 65501 and this new site is going to be in ASN 65502.

Now you should see IPv6 default route on all the routers and be able to ping6 hosts outside your own lab. (Use loopbacks as source)

“Customer” site and a new prefix

Case study: Fake Ltd

The next job is to add an interface for a bogus client. My customer Fake Ltd has an IPv6 prefix 2001:99:13:4b::/64 and their non-existent main office is located in an made-up Business Center where the connections are provided by the Fairy-Tale ISP’s imaginary core router called R8.

A make-believe port eth6 has been provisioned for this customer.

This is the best thing you get when you want to buy services without using real money.

Route it from the Real World

Route the client’s prefix 2001:99:13:4b::/64 with a static route from Internet gw to FW and from the FW to R1 just like the you did with the lab prefix in the beginning.

Now check IPv6 routing table in R8. You will see it as connected network. Go check from your other routers. No 4b there?

It is not visible yet in the other lab routers because this configuration does not redistribute connected networks. You can either make the connected networks to be redistributed or give a network statement in R8.

We do the latter.

Inject the new prefix into BGP

After you commit this command in R8, the new network should appear in the routing tables across your lab network.

You can now connect a client computer to this interface. It should get an IPv6 address and default route information from R8. Note that this configuration does not yet give IPv6 DNS addresses. For those you will need DHCPv6 set up and “other-config-flag true” under the router interface.

Now that our lab routers have each other’s loopbacks in the routing tables, we can start defining internal BGP neighbors. We will use these loopback addresses to create the adjacencies.

The lab looks like this:

I have chosen R1 and R2 to be Route Reflectors in this network. (RR in the diagram)

The iBGP assumes full mesh topology between participating routers. So routes learned from a neighbor will not be handed over via iBGP to others.

Except if a router is a Route Reflector, then it may do so.

In order to avoid building a full mesh topology (creating a bgp neighbor relationship from each router to each router) we use Route Reflectors. Now every router will have BGP connections to these two reflectors only.

Do put the “router-reflector-client” under address-family ipv6-unicast or otherwise it will not reflect IPv6 routes!
Create the relationship from R1 to every other router in your lab network using these commands.
Then do the same from R2, adjusting the lines appropriately.

In the previous part we gave our lab routers loopback addresses and verified that the routers do communicate via Internet Protocol version 6.The lab should now look like this:

Let’s take a look at the IPv6 routing table.

show ipv6 route

You will see only addresses that are connected directly to that router. So if you are at R1, you will see 2001:99:13:4a::1/128 plus the link-local addresses of each interface on R1.

If you would try to ping R2 with address 2001:99:13:4a::2 it will not respond to you. The reason for this is that since there are no routes, R1 does not know where to send traffic that is supposed to go to 2001:99:13:4a::2 and even if it did, R2 does not know how to return packets.

In the next episode we will add BGP to this network and the BGP adjacencies will be created using lab router’s loopback addresses. Since the loopbacks are now unreachable, this would not work.

Now you could write static route and thus tell R1 from where to find the address 2001:99:13:4a::2 but that would spoil the whole thing. We are trying to make a network that has a dynamic routing.

So we want to add an IGP.

The job of the Interior Gateway Protocol is to make sure that the core nodes of this network will find each other at all times. They need to find each other’s loopback addresses.

You will want to add every interface that points to other routers in your core. Do not forget to add loopback as well. Give each router an id. This id is typically the the same as the IPv4 loopback address of your router.

The Lab

In this exercise we will add IPv6 into my IPv4-speaking lab network. This lab consists of four switches, eight routers and one firewall. The firewall is connected to the NIC of my host system and provides access to the real world. All the lab hosts are Virtualbox guests on my computer.

The switches in the middle are not relevant to this article and for that reason we will not go into their configurations.

Episodes in this story will be

Part I The LAB; connections and addresses
Part II OSPF as IGP
Part III BGP route reflectors and their clients
Part IV BGP routes
Part V New site via eBGP

Here is the network diagram for this lab.
(Click to enlarge)

Each link between the routers and switches represents a Virtualbox intnet, each of them being unique. (Exeption: link between FW and Cisco goes through my wlan)

Because Virtualbox does not speak IPv6 over wlan interface, I have made a tunnel from the firewall to my real world router. There is also a tunnel between R1 and FW just because it is fun to make tunnels.

The prefix for my lab routers is 2001:099:0013:004a::/64. Each router will get a globally valid loopback address from this area.

I will use also other prefixes when it is time to add “customer” sites to the mix.

The Firewall is an ubuntu server, all other routers and switches are Vyatta 6.3.

There will be also ip6tables rules on the Firewall. I might write some more on firewalling later but you can find an example of a very basic firewall setup from my previous posting about IPv6 for residential user with tunnel service.

Here are the configurations for the tunnels used to connect the Real World to the Firewall and the Firewall to R1.
Feel free to skip them if you are not intending to use tunnels. The main beef in this lab will be the dynamic routing between routers from R1 to R8.

Set up a client interface with router advertisement and advertise with BGP

Set up a client computer and test connectivity

Let’s get it started!

Check IPv6 forwarding

Vyatta routers

Vyatta 6.3 has IPv6 forwarding on by default. You can verify it with
show ipv6 forwarding

Firewall (Ubuntu server)

sudo nano /etc/sysctl.conf

Uncomment
net.ipv6.conf.all.forwarding=1

Reboot.

Verify IPv6 connectivity between the lab routers

Go to one of them, check which interfaces are connected to other routers and give it a try:

sudo ping6 -I eth0.12 ff02::1

If and when you get replies, you can try to connect to one of those neighbors directly:
ssh fe80::a00:27ff:fe96:c448%eth0.12

Routing the LAB Prefix

I have routed the LAB prefix from the Real World (Cisco router) to my virtual lab. The routing goes in two different tunnels. You can see the commands used in static routing (Cisco, Ubuntu, Vyatta) in the tunnel examples above.

Router loopbacks

The last job in this episode is to assign each Vyatta router an address from our LAB Prefix.Let’s put the to the loopback interface.

This was my first attempt to do anything with source routing in it, in any platform, so I may not have it all correctly, let alone being according to any best practices. Anyway I was able produce the outcome I was hoping to get. Please feel free to comment!Inspiration to this lab exercise came from the LARTC tutorial and some other articles I found from the web. (See the resources section at the bottom of this post)
And of course there is always the desire to learn more what networking things you can do with just Linux boxes!

Scope

The scope of this exercise was to create a small lab net that routes IPv4. There are two user organizations in the network that are both supposed to reach a shared resource (Internet connection via firewall) and be able to communicate with other IP addresses in their own address range.

This outcome is to be produced by using Ubuntu Linuxes as routers and iproute2 program that comes with them.

The “customer” organizations and their routing tables are called “pizza” and “kebab”.

Network diagram

What counts as a success?

“Customer” addresses in the routing table “pizza” should be able to access other addresses that are in the routing table “pizza”. They should not be able to connect to hosts that are within the table “kebab”.

All hosts should be able to reach the Internet through my firewall, via NAT.

Result

The result of this configuration was what I hoped it to be. However, on a router I can ping between the host addresses of the local router, even when they belong in different sites. I assume this is because these single host addresses are visible in the routing table named “local”.