The traffic volumes from Abbeyknockmoy are getting every day more difficult to cope with, without killing the latency. We're backhauling on 3 links into town now, to cope with the volume.
The fiber that is being installed by Smart will enable us with access to our own leased dark fiber from e-net, which will link Mervue to Ballybaan.
From there a licensed 7 GHz link at 30+ m on the old tower should enable us to get to Abbeyknockmoy and solve all of the bandwidth issues for a good while.
I've also got to figure out, what kind of kit we're going to use for the dark fiber. Initially our idea was CWDM gear, but that's way out of the budget currently. I've got a few other things that I'm looking at for the interim.
Tuesday, April 7, 2009
Thursday, April 2, 2009
Cisco Catalyst Switch for ExWest
I've finally aquired a proper switch for Exchange West.
A Cisco Catalyst 4006 with a bunch of FE ports and a couple of GBIC ports will be serving as Internet Exchange in Galway until the demand for something bigger or better arises. Yes, this beast is EoL, next year even EoS, but honestly, the service is going to be free on 100 mbit/s ports and will come with no SLA and no option to buy transit across the exchange.
I've also sourced a SuperVisor III engine for the beast, so that it's running IOS, has a 64 Gbps switching fabric and will forward 48-Mpps in hardware for both Layer 2 and Layer 3/4 traffic.
I reckon' it'll be a good start platform.
A Cisco Catalyst 4006 with a bunch of FE ports and a couple of GBIC ports will be serving as Internet Exchange in Galway until the demand for something bigger or better arises. Yes, this beast is EoL, next year even EoS, but honestly, the service is going to be free on 100 mbit/s ports and will come with no SLA and no option to buy transit across the exchange.
I've also sourced a SuperVisor III engine for the beast, so that it's running IOS, has a 64 Gbps switching fabric and will forward 48-Mpps in hardware for both Layer 2 and Layer 3/4 traffic.
I reckon' it'll be a good start platform.
Wednesday, April 1, 2009
e-Net site survey for new fiber trunk (2/2)
The key was organised and the building surveyed.
All we have to do is to drill holes in two walls. The outside wall of our building, because when you're on the roof of our neighbor building, you are looking at exactly that wall :) Our building is one story higher. And then, once you've run the cable through the half of the building you've got to drill through the plaster-board wall, that was errected, when we moved in. That's it.
We'll just wait for them to do the job now. Might take a couple of weeks, but there's no immidiate rush.
All we have to do is to drill holes in two walls. The outside wall of our building, because when you're on the roof of our neighbor building, you are looking at exactly that wall :) Our building is one story higher. And then, once you've run the cable through the half of the building you've got to drill through the plaster-board wall, that was errected, when we moved in. That's it.
We'll just wait for them to do the job now. Might take a couple of weeks, but there's no immidiate rush.
Tuesday, March 31, 2009
e-Net site survey for new fiber trunk (1/2)
e-Net was around today to do the full site survey for the fiber install.
Three options are available, but we ended up with exactly, what Keith from Smart and myself had been thinking all along in the first place: the cable-riser in the neighbor building.
No civils are needed for that job, which keeps the cost down and it's going to be guaranteed seperate feeding from the BT fiber.
Unfortunatly I didn't have the key for the neighbor building today, but we'll look at it again tomorrow, when I have it.
Three options are available, but we ended up with exactly, what Keith from Smart and myself had been thinking all along in the first place: the cable-riser in the neighbor building.
No civils are needed for that job, which keeps the cost down and it's going to be guaranteed seperate feeding from the BT fiber.
Unfortunatly I didn't have the key for the neighbor building today, but we'll look at it again tomorrow, when I have it.
Monday, March 30, 2009
GBLX packet loss, flapping sessions
Turns out, GBLX has seen their filters breaking the NDP protocol before, however it didn't bother them enough to fix that globally.
At least they've fixed that for us now, until somebody decides, that it's not conforming with the standards of their filtering. The connection works again, but we'll definatly be switching for something else, because I can't use a YoYo like that for anything.
At least they've fixed that for us now, until somebody decides, that it's not conforming with the standards of their filtering. The connection works again, but we'll definatly be switching for something else, because I can't use a YoYo like that for anything.
Sunday, March 29, 2009
Change of core network to measure IPv6 traffic universally
I wanted to know, how much IPv6 traffic we're actually passing to our gateways, to the INEX, between the 6to4 and miredo gateway etc.
This was something I wanted to do especially, after I found out, that our approx 16-20 mbit/s traffic on the 6to4 gateway actually mainly is traffic between teredo and 6to4 hosts and doesn't end up anywhere, that is native IPv6.
Now, somebody might now come around and tell us to use netflow for that, but that doesn't work everywhere, I'm afraid.
So I came up with a better strategy. Any of our routers in the core network is Vlan capable. So I've stuck the IPv6 traffic in the core in a seperate Vlan from the IPv4, instead of running dual-stack. That way I can just monitor the individual interfaces.
That works pretty much on anything, as long as it's SNMP capable, and gives quite a good overview already. We'll see over the next days and weeks, how that tunes out.
This was something I wanted to do especially, after I found out, that our approx 16-20 mbit/s traffic on the 6to4 gateway actually mainly is traffic between teredo and 6to4 hosts and doesn't end up anywhere, that is native IPv6.
Now, somebody might now come around and tell us to use netflow for that, but that doesn't work everywhere, I'm afraid.
So I came up with a better strategy. Any of our routers in the core network is Vlan capable. So I've stuck the IPv6 traffic in the core in a seperate Vlan from the IPv4, instead of running dual-stack. That way I can just monitor the individual interfaces.
That works pretty much on anything, as long as it's SNMP capable, and gives quite a good overview already. We'll see over the next days and weeks, how that tunes out.
Saturday, March 28, 2009
GBLX packet loss, flapping sessions
It looks like I've cracked the case on where Global Crossing just is plain wrong, with the help of Bernard, who pointed me in the right direction.
I did some tcpdumps on the IPv6 session for Neighbor Discovery and Solicitation, which uses ICMPv6 and is crucial in the interaction of IPv6 hosts. And guess what ? They are even rate-limiting that !!! No wonder, we're constantly loosing the connection to their router.
Anyhow, I've dumped more data including the tcpdump to them and we'll see, what they say to that.
I did some tcpdumps on the IPv6 session for Neighbor Discovery and Solicitation, which uses ICMPv6 and is crucial in the interaction of IPv6 hosts. And guess what ? They are even rate-limiting that !!! No wonder, we're constantly loosing the connection to their router.
Anyhow, I've dumped more data including the tcpdump to them and we'll see, what they say to that.
Subscribe to:
Posts (Atom)