Tag: ipv6
Quagga and Routing
by Alex on Mar.13, 2009, under Tinkergeek
So, after some thinking, some prodding, and some money, I started to play with networking. My home network has for the longest time always had a Linux box at the front of it doing firewalling, nat, and all the other goodies one needs on a network. Ebay provided the cheap avenue to get some “real” networking gear, and after some frantic tabs and ?’s, I got a shiny new Cisco 871 configured up to do NAT and take a DHCP address.
Eventually, I wanted to get IPv6 networking back into my house. After dealing with SiXXS for the longest time, I moved to Hurricane Electric’s free tunnel service. I’ve never been happier with a free service. However, my home Internet connection is a Verizon DSL line with a dynamic IP address. HE just uses a point to point link for providing connectivity, so I choose to home my tunnel and IPv6 space to a machine at the Purdue Computer Society. Then, I set up a static tunnel to my house and routed some space to my 871. The goal here is to always have a constant connection for the world to me, even if that constant connection leads to a box and then dead-ends. Plus, it seems sort of silly to waste a whole /48 at my house when there could be all sorts of more useful places to send my IPv6 subnet space to.
This is where Quagga comes in. I do not really want to have to maintain static routes pointed everything, I just want the routers to know about eachother and figure out the hard parts. While I’m digging the Cisco stuff, I’m certainly not interested in buying another router, but Linux does that routing thing nicely. Quagga provides the routing protocols to populate the kernel’s routing table. It seems like a match made in heaven. (As a side note, recent Quagga builds are broken with respect to advertising IPv6 routes in BGP… Check before pulling your hair out too!)
So, for testing, I installed Quagga on two Linux boxes and gave them a simple configuration (ASN’s changed to protect the innocent):
Fremont:
router bgp 65220
bgp router-id 128.46.156.55
neighbor 2001:470:c180:aa01::2 remote-as 65221
neighbor 2001:470:c180:aa01::2 next-hop-self
!
address-family ipv6
network 2001:470:1f11:6e5::/64
network 2001:470:c180::/48
aggregate-address 2001:470:c180::/48
neighbor 2001:470:c180:aa01::2 activate
exit-address-family
Saratoga:
router bgp 65221
bgp router-id 128.46.156.11
neighbor 2001:470:c180:aa01::1 remote-as 65220
neighbor 2001:470:c180:aa01::1 next-hop-self
!
address-family ipv6
network 2001:470:1f11:53f::/64
network 2001:470:c159::/48
neighbor 2001:470:c180:aa01::1 activate
exit-address-family
fremont> show ipv6 routeCodes: K – kernel route, C – connected, S – static, R – RIPng, O – OSPFv3,I – ISIS, B – BGP, * – FIB route.K>* ::/0 via 2001:470:1f10:6e5::1, he-1C>* ::1/128 is directly connected, loC>* 2001:470:1f10:6e5::/64 is directly connected, he-1B>* 2001:470:1f11:53f::/64 [20/0] via fe80::20d:93ff:fe60:9b64, eth0.11, 00:20:56C>* 2001:470:1f11:6e5::/64 is directly connected, he-1B>* 2001:470:c159::/48 [20/0] via fe80::20d:93ff:fe60:9b64, eth0.11, 00:20:56S 2001:470:c180::/48 [1/0] is directly connected, null0 inactiveC>* 2001:470:c180:aa01::/64 is directly connected, eth0.11C * fe80::/64 is directly connected, eth0.11C * fe80::/64 is directly connected, he-1C>* fe80::/64 is directly connected, eth0
SiXXS vs HE
by Alex on Jan.24, 2009, under Tinkergeek
A friend noted that the “customer service” on SiXXS was getting to be quite a problem. It appears with popularity comes more trouble tickets and increased user support effort, something SiXXS appears unwilling to provide in a kind manner. Then, we started checking Hurricane Electric’s tunnel offerings..
HE does not have a “credits” system nor do they have strict requirements on things like user registration or tunnel performance. One merely requests a tunnel from one of their POPs and you get it automatically (along with another /64 so you can provide service to your LAN right off the bat). Then, once the tunnel is up and running, it is a simple click of a link to get a /48 allocation. No human intervention or long justifications required.
A big problem with tunnels is that latency can start to get out of hand. My native IPv4 connection gets under 80ms to most places on the Internet and usually it’s under 40ms to popular locations. To get anywhere interesting (Google and the like) over IPv6, it’s at least a 100ms journey.
Now after getting set up with a HE tunnel, I find my latency problems are a little less severe. In fact, I started running “traceroute” and noticed that most of the SiXXS stuff usually bounced around their POP for a bit and then jumped onto the HE network. After looking more into HE, it appears they have one of the largest IPv6 networks out there and they actually have customers using their network! SiXXS was a great starting point, but I wonder why people do not just go with the kinder, friendlier, and faster tunnel provider?
As a side note though, HE only provides static tunnels. No strange UDP encapsulated tunnels here to get past NAT or firewall issues.