Archive for November, 2009
Native IPv6 with Internode
Recently my ISP Internode started a IPv6 trial, for their PPPoE ADSL customers.
I managed to get my setup going, albeit with a few hacks to get around some.. odd stuff.
First of all, you need to change the username your DSL connects with to “<yourusername>@ipv6.internode.on.net”… you’ll need to update this in the following files:
- /etc/ppp/peers/dsl-provider
- /etc/ppp/chap-secrets
Once you’ve done this you’ll need to enable ipv6 on your PPP connection, so open /etc/ppp/options and somewhere in that file place +ipv6, which should enable IPv6 in PPPD. There’s some more configuration to be done in PPPD, but we’ll come back to that.
You now need to configure your dhcpv6 client to pick up your /64 from internode. Install it by issuing the following command:
apt-get install wide-dhcpv6-client
Once this is installed you’ll need to configure the configuration file /etc/wide-dhcpv6/dhcp6c.conf with the following information:
interface ppp0 { send ia-pd 0; script "/etc/wide-dhcpv6/dhcp6c-script"; }; id-assoc pd { prefix-interface eth0 { sla-id 0; sla-len 4; }; };
Once this is enabled, it will allow you to get your IPv6 subnet information from Internode, but you need to advertise this subnet to your LAN clients! This is where radvd comes in.
Install it by issuing apt-get install radvd, and put the following in the config file:
interface eth0 { AdvSendAdvert on; MinRtrAdvInterval 3; MaxRtrAdvInterval 10; prefix ::/64 { AdvOnLink on; AdvAutonomous on; AdvRouterAddr on; }; };
Now, you should bring up your DSL connection by going ‘pon dsl-provider’.. if you have a look inside your /var/log/syslog, you should see something like the following:
Nov 16 15:01:40 aang pppd[12649]: local LL address fe80::6487:8571:1291:995d Nov 16 15:01:40 aang pppd[12649]: remote LL address fe80::020c:86ff:feda:dc1b
This indicates that your IPv6 portion of the PPPoE has come up. Unfortunately there’s one small gotcha with Linux’s IPv6 support, you need to manually configure a default route, by doing the following “ip -6 route add default dev ppp0”.
Now start up your wide dhcpv6 client by issuing “/etc/init.d/wide-dhcpv6-client start” then start up your radvd, by issuing /etc/init.d/radvd start.
If you issue “ip -6 address” you should see something similar to:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 inet6 2001:44b8:75ec:fa0:20e:cff:fe38:d42a/64 scope global
This shows you have a local IPv6 address!
You should be able to do a traceroute6 or mtr to ipv6.google.com!
If you’re planning on doing IPv6 for your network also, you’ll need to enable IPv6 forwarding, by editing /etc/sysctl.conf and find the changing the following line:
net.ipv6.conf.all.forwarding=0
to:
net.ipv6.conf.all.forwarding=1
This should get the ball rolling.
To automate this somewhat, I’ve created the following scripts to bring the default route up automatically and to kick the dhcpv6 client once the PPP session comes up. Download them here and here, copy them to /etc/ppp/ipv6-up.d/, make sure they’re executable (chmod +x) and add the following line to your /etc/ppp/peers/dsl-provider file:
ipparam ipv6default
Once you’re done you should have IPv6 for your entire lan and what network change is complete without a traceroute or two, eh?
traceroute6 to ipv6.internode.on.net (2001:44b8:8020:f501:250:56ff:feb3:6633) from 2001:44b8:75ec:fa0:223:6cff:fe7e:eb8b, 64 hops max, 12 byte packets 1 2001:44b8:75ec:fa0:20e:cff:fe38:d42a 3.144 ms 0.670 ms 0.608 ms 2 loop0.lns6.adl6.internode.on.net 59.173 ms 64.452 ms 59.790 ms 3 gi9-40.cor1.adl6.internode.on.net 56.972 ms 57.928 ms 64.692 ms 4 te2-1.rtr2.adl6.internode.on.net 65.898 ms 57.747 ms 58.438 ms 5 2001:44b8:8020:f501:250:56ff:feb3:6633 58.108 ms 57.006 ms 58.253 ms
External server monitoring with Panopta
One of the most important things when you’re running a hosting business, is keeping an eye on your infrastructure so you can be on top of any faults that might arise.
At Web In A Box, we run our own internal monitoring using cacti+nagios which keeps an eye on all our stuff.
The problem with running internal monitoring is, it’s not really done from a customer’s perspective– if there’s an upstream fault which would cause your customers problems, your monitoring won’t always catch it.
To combat this, we signed up for a monitoring service from a company called Panopta (http://www.panopta.com). Panopta has a network of monitoring nodes all around the world (20, at last count). You select your primary monitoring point (in our case, Sydney) and Panopta probes the services within your network every 60 seconds.
In the event of a failure, the other monitoring nodes will start actively checking, which means it lowers false positives, while allowing you to gain a bit more perspective on faults, allowing you pin-point geographically where the fault may lie, if it’s upstream.
Panopta also keep historic trending data and also allow you to have a public facing availability report:
So if you’re looking for a decent way to keep an eye on your network, give Panopta a look 🙂
For the love of god, update your “Bogon” list.
For those not familiar, I am a director in a small web hosting company called Web In A Box (http://www.webinabox.net.au).
Earlier this year we were allocated our first shiny, new, IP allocation from the local RIR, APNIC. For what should’ve been a happy happy time for us, turned sour, quickly.
After migrating a good chunk of our infrastructure into our new IP space, it become apparent that something was a bit off with our IP space. We started running into all kinds of connectivity issues, even with some of our own machines overseas!
After some investigation it appeared that our IP space was in fact, quite new and shiny. So new and shiny infact, that a good chunk of the internet still thought the “supernet” (110.0.0.0/8) it came from was still unallocated!
I’ll stop here and provide a bit of backfill so you can understand the situation. Nasty people on the internet (spammers, DoS’ers etc) have long hi-jacked other people’s IP space, or even hi-jacked unallocated space, in an attempt to evade blacklisting/firewalling. In an attempt to thwart the mean men, several “Bogon” lists were published with (at the time) unallocated IP blocks, so people could firewall/blacklist them, so mean men couldn’t use them for the forces of evil.
As the story often goes in IT, the usual churnover of staff meant these bogon lists often went unattended as time went on. This was seemingly fine for a while, until the unthinkable happened. The internet started running low on IPv4 space, so those “Bogon” ranges started being allocated out to people who needed them (like us) and because these filters weren’t being maintained, connectivity to these new IP addresses was being blocked!
Now, back to the story. Because of the very nature of these lists and the fact they’ve often gone unattended and been completely forgotten about, getting them removed is a complete pain in the ass. We’ve had people flat out deny they’ve even got “Bogon” blocks in place, only through insistence on our part have they gone and checked and eventually rectified the problem.
So, where to go from here? Well, there’s plenty of debate on the ‘tubes over the ongoing effectiveness of “Bogon” filtering, but for the people who think it’s a good idea, how do they implement it without it becoming a ticking time bomb next time someone forgets it?
Well, The guys at Team Cymru (http://www.team-cymru.org/) have released a BGP ‘Black-hole’ service which fits the bill quite nicely. We ourselves have turned up a BGP session with them and we’re currently receiving 26 prefixes from their route reflectors. We use a simple route-map to install a null routed next hop, from the routes we receive from them. If you’re worried that the cymru guys could send you some nasty routes and blow your network up, you can simply do what we’ve done– We’ve set up a prefix list with the current “Bogon” prefixes allowed, but nothing more. Because IPv4 is running out, the likelyhood of something being added to the “bogon” list, is slim to none, so doing this prevents the Cymru guys sending us any prefixes we wern’t otherwise expecting, but they’re free to withdraw any they like, as the space gets consumed.
So if you’re currently running “Bogon” filtering within your network please, please, PLEASE consider switching to the Cymru BGP feed, or at worst, set some kind of automatic script, based on the lists they publish. We’d REALLY appreciate it.
Dear FOX, We hate you.
It seems that whenever I get particularly attached to any kind of television show, some retarded TV network comes along and decides it’s a *brilliant* idea to cancel it.
The latest ‘victim’ is Dollhouse which has been canceled due to ‘poor ratings’. This decision sucks, for the following reasons:
- They put it in the Friday Night Timeslot
There was no way the show was really going to succeed in this timeslot. It’s where TV shows go to die. Dollhouse was put here from the beginning so it never had a chance. - Piss-poor promotion.
There was so little hype surrounding Dollhouse than no-one tuned in initially because they knew nothing about it. Due to the fact this show actually has an involving story line, people would’ve struggled to pick it up mid-stream. - Piss-poor distribution
I live in Australia and whilst I don’t watch much FTA Television, I don’t think Dollhouse was even aired here, which stinks. They wonder why TV piracy is so rampant, I would’ve never gotten the chance to see the show if it weren’t for it. It’s a bit of a double edged sword actually, because whilst the TV studios continue to walk around with their heads in their asses, Shows like this with a huge online cult following, die, because they don’t recognise the Internet as a ‘valid medium’ and refuse to take it seriously
So I’ll continue to be completely disillusioned by the TV industry, while they keep cancelling great, original, thought provoking TV shows and keep utter shit like LOST and Survivor running.