Our Dublin BGP router just died this morning. It looks like, that there is a bug, that causes Quagga (0.99.10 and as it seems 0.99.11) to crash, when it receives a 32-bit ASN in the as-path on certain peering sessions.
A post to the users list confirmed very quickly, that it was a bug and it wasn't an isolated incident, a work-around was found, implemented and we got things quickly back up and running.
Luckily, our BGP feeds are split over the Galway and Dublin BGP servers, so nobody really noticed.
Showing posts with label TeleCity. Show all posts
Showing posts with label TeleCity. Show all posts
Thursday, April 30, 2009
Tuesday, April 21, 2009
Cisco Catalyst
We've recently bought a couple of older Cisco Catalyst switches and replaced the Dell switches in the network.
First of all, the Cisco switches are more flexible and some of them even do Layer3 services, like BGP. So on top of the Catalyst 4006 for ExWest, we've got one of them in TeleCity and one in Mervue.
The changeover was done last week and things seem to be running pretty good. I'm just left with replacing the switches in remote sites like Abbeyknockmoy etc.
The reason for replacing the old switches is, that once in a while, when the VLan configuration is committed, the darn things just go daft and drop everything. All that is left then is to drive on site and powercycle the switch. Not something you really want to do, when the switch is 60-70 km's away.
Another switch that had to go is the Linksys Enterprise switch, because it's just a PAIN to having to find a Windows box, just to configure the Vlans. The switch's webinterface only works in IE and you can't configure Vlan's via SSH or telnet. How daft is that ?
Also our INEX Lan#2 peering are handed by the Catalyst in Dublin now. No major box needed there currently and we can upgrade as we go.
First of all, the Cisco switches are more flexible and some of them even do Layer3 services, like BGP. So on top of the Catalyst 4006 for ExWest, we've got one of them in TeleCity and one in Mervue.
The changeover was done last week and things seem to be running pretty good. I'm just left with replacing the switches in remote sites like Abbeyknockmoy etc.
The reason for replacing the old switches is, that once in a while, when the VLan configuration is committed, the darn things just go daft and drop everything. All that is left then is to drive on site and powercycle the switch. Not something you really want to do, when the switch is 60-70 km's away.
Another switch that had to go is the Linksys Enterprise switch, because it's just a PAIN to having to find a Windows box, just to configure the Vlans. The switch's webinterface only works in IE and you can't configure Vlan's via SSH or telnet. How daft is that ?
Also our INEX Lan#2 peering are handed by the Catalyst in Dublin now. No major box needed there currently and we can upgrade as we go.
Wednesday, March 25, 2009
Adding 200 mbit/s from Galway to Dublin
It looks like the next couple of months will be very exciting.
We've recently peaked 86 mbit/s on our BT circuit to TeleCity in Dublin and the Smart circuit on the other end of town is running at around 23 mbit/s. That's an aggregated traffic volume of approx. 110 mbit/s at peak.
Now, we're going to shut the Dangan circuit down, maybe keep it as backup as it doesn't cost us much, but all the traffic on that circuit is going to be moved into our datacenter in Mervue. Also with only 14 mbit/s leeway left, more bandwidth was needed.
Smart is going to supply us with 100 mbit/s L2 (in addition to the BT circuit), which we're going to combine on the Cisco switches I've just bought for our network.
On top of that, we're going to get another 100 mbit/s L2 circuit into DEG in Dublin (another datacenter), where we are moving our INEX Lan#1 connection. That way, we'll be connected to INEX in two different datacenters and will be getting the optimum redundancy out of that.
That's a total of 400 mbit/s from Galway to Dublin now, where 300 mbit/s of that are in our datacenter in Mervue.
There were a lot of reasons for not increasing the circuit with BT:
- we wanted fiber into the building on a physical different path. Smart was not even allowed to bring the fiber in through the same ducting or elevator shaft. So matter of fact, we're bringing the fiber in through a cable-riser in the neighboring building and then through a complete different wall.
- we wanted the fiber on an entirely different path from Galway to Dublin. BT's fiber is along the irish railroads, while Smart uses ESB networks fiber along the pylons and high voltage lines.
- BT only installed a STM1 capable CPE, when they supplied us with the fiber initially. If we had opted just to increase that circuit, the CPE gear would have to be replaced resulting in downtime or us hauling the traffic across town to Dangan, which isn't really an option. The reason for establishing the DC in Mervue was, that we couldn't get decent wireless links to Dangan.
These are just a few of the reasons, why.
We've recently peaked 86 mbit/s on our BT circuit to TeleCity in Dublin and the Smart circuit on the other end of town is running at around 23 mbit/s. That's an aggregated traffic volume of approx. 110 mbit/s at peak.
Now, we're going to shut the Dangan circuit down, maybe keep it as backup as it doesn't cost us much, but all the traffic on that circuit is going to be moved into our datacenter in Mervue. Also with only 14 mbit/s leeway left, more bandwidth was needed.
Smart is going to supply us with 100 mbit/s L2 (in addition to the BT circuit), which we're going to combine on the Cisco switches I've just bought for our network.
On top of that, we're going to get another 100 mbit/s L2 circuit into DEG in Dublin (another datacenter), where we are moving our INEX Lan#1 connection. That way, we'll be connected to INEX in two different datacenters and will be getting the optimum redundancy out of that.
That's a total of 400 mbit/s from Galway to Dublin now, where 300 mbit/s of that are in our datacenter in Mervue.
There were a lot of reasons for not increasing the circuit with BT:
- we wanted fiber into the building on a physical different path. Smart was not even allowed to bring the fiber in through the same ducting or elevator shaft. So matter of fact, we're bringing the fiber in through a cable-riser in the neighboring building and then through a complete different wall.
- we wanted the fiber on an entirely different path from Galway to Dublin. BT's fiber is along the irish railroads, while Smart uses ESB networks fiber along the pylons and high voltage lines.
- BT only installed a STM1 capable CPE, when they supplied us with the fiber initially. If we had opted just to increase that circuit, the CPE gear would have to be replaced resulting in downtime or us hauling the traffic across town to Dangan, which isn't really an option. The reason for establishing the DC in Mervue was, that we couldn't get decent wireless links to Dangan.
These are just a few of the reasons, why.
Friday, October 10, 2008
GBLX IPv4 session live
Finally the last bit for our IPv4 transit falls into place: Our IPv4 session with Global Crossing got turned up today, immidiatly eating up traffic.
Thursday, October 9, 2008
Hurricane IPv6 BGP tunnel TCY <-> FFM
As IPv6 over Level3 fell flat (PacketExchange can't deliver) and I still have no second IPv6 peer for TeleCity, I did set a second tunnel up with Hurricane Electric. That finally got set up today, lads must be a bit busy at HE.net.
So for IPv6 we've now Smart Telecom (native) and Hurricane London (tunnel) in Dangan, Galway. In TeleCity we've got GlobalCrossing (native) and Hurricane Frankfurk/Main (tunnel), Germany on top of the INEX peerings on Vlan#1.
The INEX Vlan#2 is a Mikrotik router and they still can't do IPv6 BGP without mix/match :(. I've been chasing them on that since 3.10 now, it was supposed to be fixed in 3.12 and as of 3.14 routing-test it still doesn't work, if I got the configuration right.
So for IPv6 we've now Smart Telecom (native) and Hurricane London (tunnel) in Dangan, Galway. In TeleCity we've got GlobalCrossing (native) and Hurricane Frankfurk/Main (tunnel), Germany on top of the INEX peerings on Vlan#1.
The INEX Vlan#2 is a Mikrotik router and they still can't do IPv6 BGP without mix/match :(. I've been chasing them on that since 3.10 now, it was supposed to be fixed in 3.12 and as of 3.14 routing-test it still doesn't work, if I got the configuration right.
Friday, October 3, 2008
GBLX IPv6 and eXpress peering live
Finally, it took ages to get the details for the Globalcrossing IPv6 and the eXpress peering sessions. But they are live now and we'll just have to wait for the eXpress route-servers to pick up our prefixes. That should happen in the next 24 hours.
All we are waiting on our circuit to PacketExchange is the session for IPv4 from Globalcrossing.
Anyhow, this means, that we have 3 IPv4 and 3 IPV6 transit carriers now.
All we are waiting on our circuit to PacketExchange is the session for IPv4 from Globalcrossing.
Anyhow, this means, that we have 3 IPv4 and 3 IPV6 transit carriers now.
Tuesday, September 16, 2008
Level3 session live
The session for Level3 is live, which means, we've got 3 IPv4 transit carriers for our upstream.
Monday, September 8, 2008
Friday, September 5, 2008
More X-connects live
The cross-connects to Cogent and PacketExchange went live. We'll just have to wait for them to supply us with the session details and test the connections.
Thursday, July 31, 2008
Tuesday, July 29, 2008
INEX Quarantine fail
Yikes. Turns out, that the switches I've used are leaking their own MAC-addresses into all VLan's. That kicks us another 24 hours back on the schedule.
Monday, July 28, 2008
INEX Quarantine
Our X-connect has been setup and the quarantine process to be enabled on the two INEX ports has been initiated. We'll see how things go in the next 24 hours.
Wednesday, July 23, 2008
TeleCity PoP
Our rack in TeleCity is ready to move in. The first routers are gone in and we're only waiting for our fiber link from Galway and the crossconnects to the carriers and the INEX.
Thursday, July 10, 2008
INEX membership
We got an email from the INEX team today, that our membership has been approved, so it's all downhill from here :)
Subscribe to:
Posts (Atom)