Two sites, one LAN

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

two-sites-one-lan

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.

generate openvpn key r3a-r4b

r3a
set interfaces bridge br2
set interfaces ethernet eth4 bridge‐group bridge br2
commit
set interfaces openvpn vtun2 mode site‐to‐site
set interfaces openvpn vtun2 remote‐host 10.1.4.2
set interfaces openvpn vtun2 shared‐secret‐key‐file /home/user/r3a-r4b
set interfaces openvpn vtun2 bridge‐group bridge br2
commit

r4b
set interfaces bridge br2
set interfaces ethernet eth5 bridge‐group bridge br2
commit
set interfaces openvpn vtun2 mode site‐to‐site
set interfaces openvpn vtun2 remote‐host 10.1.3.2
set interfaces openvpn vtun2 shared‐secret‐key‐file /home/user/r3a-r4b
set interfaces openvpn vtun2 bridge‐group bridge br2

commit

Give the lab-routers their IPv6 addresses

set interfaces ethernet eth4 ipv6 address eui64 2001:98:13:4f::/64
set interfaces ethernet eth4 ipv6 router-advert prefix 2001:98:13:4f::/64
set interfaces ethernet eth4 ipv6 router-advert other-config-flag true

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.

That is why I use tunnels.

Create IPv6-over-IPv4 tunnels between

“ISP-router” – r1a
“ISP-router” – r2b

IPv6 addresses for the tunnels

“ISP-router” Cisco
2001:98:0013:004e::1/126
r1a
2001:98:0013:004e::2/126

“ISP-router” Cisco
2001:98:0013:004e::5/126
r2b
2001:98:0013:004e::6/126

Cisco config
interface Tunnel3
description IPv6 tunnel to r1a
no ip address
ipv6 address 2001:98:0013:004e::1/126
ipv6 enable
tunnel source 10.1.1.1
tunnel destination 10.1.1.2
tunnel mode ipv6ip

Vyatta config for r1a
edit interfaces tunnel tun3
set address 2001:98:0013:004e::2/126
set encapsulation sit
set local-ip 10.1.1.2
set remote-ip 10.1.1.1
set description "IPv6 tunnel to cisco"
exit
commit

Adjust accordingly for r2b.

Routing

Configure IPv6 eBGP from r1a and r2b to Internet-router.

r1a
set protocols bgp 65502 neighbor 2001:98:13:4e::1 address-family ipv6-unicast soft-reconfiguration inbound
set protocols bgp 65502 neighbor 2001:98:13:4e::1 remote-as 65501
set protocols bgp 65502 parameters router-id 10.1.1.2

cisco
router bgp 65501
no synchronization
bgp log-neighbor-changes
neighbor 2001:98:13:4E::2 remote-as 65502
no auto-summary
!
address-family ipv6
neighbor 2001:98:13:4E::2 activate
neighbor 2001:98:13:4E::2 next-hop-self
neighbor 2001:98:13:4E::2 soft-reconfiguration inbound
redistribute static
default-information originate
no synchronization
exit-address-family
!

Adjust accordingly for r2b

Configure IPv6 iBGP r1a – r2b

r2b
set protocols bgp 65502 neighbor 2001:98:13:4f:a00:27ff:fef7:eb81 address-family ipv6-unicast soft-reconfiguration inbound
set protocols bgp 65502 neighbor 2001:98:13:4f:a00:27ff:fef7:eb81 remote-as 65502
set protocols bgp 65502 neighbor 2001:98:13:4f:a00:27ff:fef7:eb81 address-family ipv6-unicast nexthop-self
set protocols bgp 65502 neighbor 2001:98:13:4f:a00:27ff:fef7:eb81 update-source 2001:98:13:4f:a00:27ff:fe97:1e3c

Adjust accordingly for r1a.
Inject the LAN prefix into BGP

r1a & r2b
set protocols bgp 65502 address-family ipv6-unicast network 2001:98:0013:004f::/64

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.

r2b
set policy route-map prepend-secondary rule 10 action permit
set policy route-map prepend-secondary rule 10 set as-path-prepend "65502 65502"
set protocols bgp 65502 neighbor 2001:98:13:4E::5 address-family ipv6-unicast route-map export prepend-secondary

IPv6 Vyatta Lab – Part V; New site via eBGP

[Originally posted Jun 3, 2012 4:31 AM by Antti Uitto   [ updated Jun 3, 2012 10:05 AM ]]

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.

vyatta-lab-with-loopacks3

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.

cust2-gw1 (connected to R6)
set interfaces ethernet eth4 address 2001:99:0013:004d::2/64
set protocols bgp 65502 neighbor 2001:99:0013:004d::1 address-family ipv6-unicast soft-reconfiguration inbound
set protocols bgp 65502 neighbor 2001:99:0013:004d::1 remote-as 65501
set protocols bgp 65502 parameters router-id 172.2.2.1

Just make something up for router-id.

R6 (connected to cust2-gw1)
set interfaces ethernet eth5 address 2001:99:0013:004d::1/64
set protocols bgp 65501 neighbor 2001:99:0013:004d::2 address-family ipv6-unicast soft-reconfiguration inbound
set protocols bgp 65501 neighbor 2001:99:0013:004d::2 remote-as 65502

Create the links and bgp relationships between cust2-gw2 and R8 in similar way, using link network 2001:99:13:4e::/64.

Make sure you add these new link interfaces to your IGP (OSPF) in the core network so that your next-hop addresses will be available.

Create the LAN interface and turn on router advert

cust2-gw1
set interfaces ethernet eth5 ipv6 address eui64 2001:99:13:4c::/64
set interfaces ethernet eth5 ipv6 router-advert send-advert true
set interfaces ethernet eth5 ipv6 router-advert prefix 2001:99:13:4c::/64

Advertise the customer prefix into BGP.

cust2-gw1 & gw2
set protocols bgp 65502 address-family ipv6-unicast network 2001:99:13:4c::/64

Manipulate your routing

In my network gw1 was chosen as the primary route to the new customer site. This may be just fine but for the fun of doing so, I wanted to change this.

This configuration will be inserted into cust2-gw1 and it will prepend the AS PATH announced by this router. This will cause cust2-gw2 to become better than gw1.

set policy route-map as-prepend rule 1 set as-path-prepend “65502 65502”
set policy route-map as-prepend rule 1 action permit
set policy route-map as-prepend rule 1 match ipv6 address prefix-list as-prepend
set policy prefix-list6 as-prepend rule 1 action permit
set policy prefix-list6 as-prepend rule 1 prefix 2001:99:13:4c::/64
set protocols bgp 65502 neighbor 2001:99:13:4d::1 address-family ipv6-unicast route-map export as-prepend

The routing turned  to gw2 but still my computer in the cust2 LAN wanted to use gw1 as it’s primary gateway to the world.  In Cisco you can manipulate this by setting the gw2 router priority to “high”.

I don’t know how to do that in Vyatta at the moment. There is so much to learn.

Add a computer to the LAN

Now it is time to add a “customer’s” computer into this LAN and see if we reach our core network router’s loopbacks and perhaps even the Internet from it.

Check  ip -6 route  on the computer (if Linux). Which gateway it wants to talk to first?

Test your redundancy. Verify which route your computer uses to reach the Internet and then turn off that gw. Put it back on and turn off the other one. What happens? Do you lose many pings?

Check out this Packetlife article for more information on IPv6 ND providing first-hop redundancy.
http://packetlife.net/blog/2011/apr/18/ipv6-neighbor-discovery-high-availability/

More to do

It might be wise to make a prefix-list in the core routers R6 and R8 to prevent other networks than 2001:99:13:4c::/64 being advertised to our network.

I could easily add one here but I will not since there has to be stuff left for future articles!

IPv6 Vyatta LAB – Part IV ; BGP routes and a customer site

[Originally posted May 9, 2012 12:41 PM by Antti Uitto   [ updated May 9, 2012 1:17 PM ]]

In the previous chapter we created BGP connections for our network. In order to avoid configuring full mesh, connecting each router to each router (as iBGP would demand), we used Route Reflectors.

Now we should have all the BGP neighbors up and running but nothing is yet advertised using BGP.

In this exercise we shall inject some routes into this new BGP.

I have earlier configured a static default route in R1. (See the first episode)
Let’s make this ::/0 available to all the other routers as well.

R1
set protocols bgp 65501 neighbor 2001:99:13:4a::2 address-family ipv6-unicast default-originate
set protocols bgp 65501 neighbor 2001:99:13:4a::3 address-family ipv6-unicast default-originate
… etc …

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.

Create an interface

R8
set interfaces ethernet eth6 address 2001:099:0013:004b::1/64
set interfaces ethernet eth6 ipv6 router-advert prefix 2001:099:0013:004b::/64
set interfaces ethernet eth6 ipv6 router-advert send-advert true

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

R8
set protocols bgp 65501 address-family ipv6-unicast network 2001:99:13:4b::/64

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.

https://sites.google.com/site/6filesb/home/blog/ipv6basicsaddressingahostandstaticrouting

It was worth every penny!

IPv6 Vyatta LAB – Part III BGP route reflectors and their clients

[Originally posted May 3, 2012 2:28 PM by Antti Uitto   [ updated May 9, 2012 12:43 PM ]]

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:

vyatta-lab-with-loopacks2

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.

Let’s start configuring!

Say configure to your Vyatta and insert these:

Route Reflector R1
set protocols bgp 65501 address-family ipv6-unicast
set protocols bgp 65501 neighbor 2001:99:13:4a::2 address-family ipv6-unicast
set protocols bgp 65501 neighbor 2001:99:13:4a::2 remote-as 65501
set protocols bgp 65501 neighbor 2001:99:13:4a::2 address-family ipv6-unicast soft-reconfiguration inbound
set protocols bgp 65501 neighbor 2001:99:13:4a::2 address-family ipv6-unicast route-reflector-client
set protocols bgp 65501 neighbor 2001:99:13:4a::2 update-source 2001:99:13:4a::1

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.

Other routers
set protocols bgp 65501 address-family ipv6-unicast
set protocols bgp 65501 neighbor 2001:99:13:4a::1 address-family ipv6-unicast
set protocols bgp 65501 neighbor 2001:99:13:4a::1 remote-as 65501
set protocols bgp 65501 neighbor 2001:99:13:4a::1 address-family ipv6-unicast soft-reconfiguration inbound
set protocols bgp 65501 neighbor 2001:99:13:4a::1 update-source 2001:99:13:4a::4
set protocols bgp 65501 neighbor 2001:99:13:4a::2 address-family ipv6-unicast
set protocols bgp 65501 neighbor 2001:99:13:4a::2 remote-as 65501
set protocols bgp 65501 neighbor 2001:99:13:4a::2 address-family ipv6-unicast soft-reconfiguration inbound
set protocols bgp 65501 neighbor 2001:99:13:4a::2 update-source 2001:99:13:4a::4

This links the router in question to both Route Reflectors.
Just change the update-source and paste to each router.

show ipv6 bgp summary

You should now see BGP adjacencies.

Then check

show ipv6 route bgp

and you will find that although BGP neighbors are defined and adjacencies are up, you have no BGP-learned IPv6 routes. We will change that in the next episode.

Sources
http://en.wikipedia.org/wiki/Route_reflector
http://en.wikipedia.org/wiki/Internal_border_gateway_protocol#Operation

IPv6 Vyatta LAB – Part II OSPF as IGP

[Originally posted May 1, 2012 10:48 AM by Antti Uitto   [ updated May 3, 2012 2:29 PM ]]

Part II    OSPF as IGP

 
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:

vyatta-lab-with-loopacks



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.

My choise for IGP in this lab is OSPF.

Here are the spells to get it going.

R1
set protocols ospfv3 area 0.0.0.0 interface eth0.12
set protocols ospfv3 area 0.0.0.0 interface eth0.13
set protocols ospfv3 area 0.0.0.0 interface eth0.14
set protocols ospfv3 area 0.0.0.0 interface eth1
set protocols ospfv3 area 0.0.0.0 interface eth2
set protocols ospfv3 area 0.0.0.0 interface lo
set protocols ospfv3 parameters router-id 10.5.5.1

Please adjust the interfaces to suit your configuration.

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.

Now check IPv6 routing table again.

show ipv6 route

You should see the loopbacks of all lab routers.

Ping them.

sudo ping6 2001:99:13:4a::8 -I 2001:99:13:4a::1

Other show-commands

show ipv6 route ospf6
show ipv6 ospfv3
show ipv6 ospfv3 neighbor
show ipv6 ospfv3 neighbor detail
show ipv6 ospfv3 route
show ipv6 ospfv3 route detail
show ipv6 ospfv3 interface eth0.12
show ipv6 ospfv3 database
show ipv6 ospfv3 area

Sources
http://en.wikipedia.org/wiki/Open_Shortest_Path_First
http://searchsecurity.techtarget.com/definition/IGP
http://en.wikipedia.org/wiki/Interior_gateway_protocol

IPv6 Vyatta LAB – Part I; the LAB connections and addresses

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)

 

vyatta-lab

 

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.

Tunnel from FW to r1

Firewall  (Ubuntu)
sudo ip tu ad sit203 mode sit local 4.4.4.1 remote 4.4.4.2 ttl 64
sudo ip ad ad dev sit203 2001:099:0013:004a:ffff:ffff:ffff:fffd/126
sudo ip li se dev sit203 up
sudo ip -6 ro ad 2001:099:0013:004a::/64 via 2001:099:0013:004a:ffff:ffff:ffff:fffe

R1  (Vyatta)
set interfaces tunnel tun203 encapsulation sit
set interfaces tunnel tun203 local-ip 4.4.4.2
set interfaces tunnel tun203 remote-ip 4.4.4.1
set interfaces tunnel tun203 address 2001:099:0013:004a:ffff:ffff:ffff:fffe/126
set protocols static route6 ::/0 next-hop 2001:099:0013:004a:ffff:ffff:ffff:fffd

Tunnel from FW to REAL WORLD (Cisco)

FW  (Ubuntu)
ip tu ad sit200 mode sit local 194.x.x.5 remote 194.x.x.1 ttl 64
ip ad ad dev sit200 2001:099:0013:0049:ffff:ffff:ffff:fffe/126
ip li se dev sit200 up
ip -6 ro ad ::/0 via 2001:099:0013:0049:ffff:ffff:ffff:fffd

Cisco
interface Tunnel200
no ip address
ipv6 address 2001:99:13:49:FFFF:FFFF:FFFF:FFFD/126
ipv6 enable
tunnel source 194.x.x.1
tunnel destination 194.x.x.5
tunnel mode ipv6ip
ipv6 route 2001:99:13:4A::/64 2001:99:13:49:FFFF:FFFF:FFFF:FFFE

Procedure

This is what we are going to be doing:

 

  1. Check IPv6 forwarding
  2. Verify IPv6 connectivity between the lab routers
  3. Route the lab prefix from the Internet router to LAB FW
  4. Route the lab prefix from LAB FW to R1
  5. Set IPv6 loopback addresses with mask /128 to each router
  6. Set up OSPFv3 and verify connectivity between routers
  7. Set up BGP
  8. Redistribute default route to BGP
  9. Set up a client interface with router advertisement and advertise with BGP
  10. 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.

Do this by commanding

user@r1  configure
user@r1 set interfaces loopback lo address 2001:99:13:4a::1/128
user@r1 commit
user@r1 save

user@r2 configure
user@r2 set interfaces loopback lo address 2001:99:13:4a::2/128
user@r2 commit
user@r2 save

user@r3 configure
user@r3 set interfaces loopback lo address 2001:99:13:4a::3/128
user@r3 commit
user@r3 save

….  etc ….

In the next episode we will set up OSPF as an IGP for the lab network.

Networking with Linux; source routing

[Originally posted Mar 13, 2012 5:33 AM by Antti Uitto   [ updated Mar 13, 2012 5:34 AM ]]

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”.

And maby rule for “local” table is read first?

linuxlab2:~$ ip rule show
0: from all lookup local
32760: from 192.168.13.0/24 lookup kebab
32761: from 192.168.12.0/24 lookup kebab
32762: from 192.168.11.0/24 lookup kebab
32763: from 192.168.3.0/24 lookup pizza
32764: from 192.168.2.0/24 lookup pizza
32765: from 192.168.1.0/24 lookup pizza
32766: from all lookup main
32767: from all lookup default
linuxlab2
linuxlab2:~$ ip route show table local match 192.168.2.1
local 192.168.2.1 dev eth1 proto kernel scope host src 192.168.2.1
linuxlab2:~$
linuxlab2:~$ ip ro sh ta local match 192.168.2.2
linuxlab2:~$

Procedure

1. Install router hosts with ssh, vlan and bridge-utils
2. Give password for root user
3. Turn on ip forwarding
4. Give link IP’s and test connectivity
5. Create both routing tables to all routers
6. Make “customer” interfaces
7. Add them to the appropriate routing tables
8. Make static routes
8. Create ip rules to all routers (“from”-rules)
9. Give default routes to both routing tables

(you can find routing and ip rule commands later in the post)

Create new routing tables
echo 1 pizza >> /etc/iproute2/rt_tables
echo 2 kebab >> /etc/iproute2/rt_tables

“Customer” addresses

pizza
192.168.1.0/24
192.168.2.0/24
192.168.3.0/24

kebab
192.168.11.0/24
192.168.12.0/24
192.168.13.0/24

Notes

“Customer” site addresses are present in their own routing tables. Routing table called “main” has all the routes so that it can bring you the returning packets.

IP rules dictate that packets sourcing from “pizza” addresses are routed according to the “pizza” routing table. There are only “from” rules in my set.

The main table has no 0/0-route but the “pizza” and “kebab” tables do have it.

Configs per router

linuxlab1

“Customer” interfaces

# description pizza
auto eth3.10
iface eth3.10 inet static
address 192.168.1.1
netmask 255.255.255.0

# description kebab
auto eth3.20
iface eth3.20 inet static
address 192.168.11.1
netmask 255.255.255.0

Configs in /etc/rc.local
#
# ROUTES
#
ip route add 127.0.0.0/8 dev lo table pizza
ip route add 192.168.2.0/24 via 10.1.2.2 table pizza
ip route add 192.168.3.0/24 via 10.1.3.3 table pizza
ip route add 192.168.1.0/24 dev eth3.10 table pizza
ip route add default via 10.2.2.1 table pizza
ip route add 127.0.0.0/8 dev lo table kebab
ip route add 192.168.12.0/24 via 10.1.2.2 table kebab
ip route add 192.168.13.0/24 via 10.1.3.3 table kebab
ip route add 192.168.11.0/24 dev eth3.20 table kebab
ip route add default via 10.2.2.1 table kebab
ip route add 192.168.2.0/24 via 10.1.2.2
ip route add 192.168.12.0/24 via 10.1.2.2
ip route add 192.168.3.0/24 via 10.1.3.3
ip route add 192.168.13.0/24 via 10.1.3.3
#
# IP RULES
#
ip rule add from 192.168.1.0/24 table pizza
ip rule add from 192.168.2.0/24 table pizza
ip rule add from 192.168.3.0/24 table pizza
ip rule add from 192.168.11.0/24 table kebab
ip rule add from 192.168.12.0/24 table kebab
ip rule add from 192.168.13.0/24 table kebab

linuxlab2

“Customer” interfaces:

# description pizza
auto eth1
iface eth1 inet static
address 192.168.2.1
netmask 255.255.255.0

# description kebab
auto eth2
iface eth2 inet static
address 192.168.12.1
netmask 255.255.255.0

Configs in /etc/rc.local
#
# ROUTES
#
ip route add 127.0.0.0/8 dev lo table pizza
ip route add 192.168.2.0/24 dev eth1 table pizza
ip route add 192.168.3.0/24 via 10.1.2.1 table pizza
ip route add 192.168.1.0/24 via 10.1.2.1 table pizza
ip route add default via 10.1.2.1 table pizza
ip route add 127.0.0.0/8 dev lo table kebab
ip route add 192.168.12.0/24 dev eth2 table kebab
ip route add 192.168.13.0/24 via 10.1.2.1 table kebab
ip route add 192.168.11.0/24 via 10.1.2.1 table kebab
ip route add default via 10.1.2.1 table kebab
ip route add 192.168.1.0/24 via 10.1.2.1
ip route add 192.168.11.0/24 via 10.1.2.1
ip route add 192.168.3.0/24 via 10.1.2.1
ip route add 192.168.13.0/24 via 10.1.2.1
#
# IP RULES
#
ip rule add from 192.168.1.0/24 table pizza
ip rule add from 192.168.2.0/24 table pizza
ip rule add from 192.168.3.0/24 table pizza
ip rule add from 192.168.11.0/24 table kebab
ip rule add from 192.168.12.0/24 table kebab
ip rule add from 192.168.13.0/24 table kebab

linuxlab3

“Customer” interfaces

# description pizza
auto eth2
iface eth2 inet static
address 192.168.3.1
netmask 255.255.255.0

# description kebab
auto eth3
iface eth3 inet static
address 192.168.13.1
netmask 255.255.255.0

Configs in /etc/rc.local
#
# ROUTES
#
ip route add 127.0.0.0/8 dev lo table pizza
ip route add 192.168.2.0/24 via 10.1.3.1 table pizza
ip route add 192.168.3.0/24 dev eth2 table pizza
ip route add 192.168.1.0/24 via 10.1.3.1 table pizza
ip route add default via 10.1.3.1 table pizza
ip route add 127.0.0.0/8 dev lo table kebab
ip route add 192.168.12.0/24 via 10.1.3.1 table kebab
ip route add 192.168.13.0/24 dev eth3 table kebab
ip route add 192.168.11.0/24 via 10.1.3.1 table kebab
ip route add default via 10.1.3.1 table kebab
ip route add 192.168.1.0/24 via 10.1.3.1
ip route add 192.168.11.0/24 via 10.1.3.1
ip route add 192.168.2.0/24 via 10.1.3.1
ip route add 192.168.12.0/24 via 10.1.3.1
#
# IP RULES
#
ip rule add from 192.168.1.0/24 table pizza
ip rule add from 192.168.2.0/24 table pizza
ip rule add from 192.168.3.0/24 table pizza
ip rule add from 192.168.11.0/24 table kebab
ip rule add from 192.168.12.0/24 table kebab
ip rule add from 192.168.13.0/24 table kebab

Commands to verify and check stuff

ip rule show
ip route show
ip route show table pizza
ip route show (table pizza/kebab) match 192.168.2.5
ifconfig
ip address
ping 8.8.8.8 -I 192.168.2.1
traceroute 8.8.8.8 -s 192.168.12.1

And then what?

I don’t know. Perhaps add IPv6 to this? Is it possible? Why would it not be?
Or maby get Quagga and make these things to do dynamic routing?

Resources

http://www.linuxhorizon.ro/iproute2.html
http://kindlund.wordpress.com/2007/11/19/configuring-multiple-default-routes-in-linux/
http://lartc.org