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.
Showing posts with label INEX. Show all posts
Showing posts with label INEX. Show all posts
Tuesday, April 21, 2009
Thursday, March 26, 2009
INEX Meeting, GBLX, various.
The INEX meeting in Dublin was on. I gave a talk on IPv6 deployment. The video for that can be found here.
It also looks like in the likes of the issues with GBLX, we're probably going to kill that session and get IPv6 from KPN instead. Global Crossing engineers have no understanding for, that rate-limiting ICMP in IPv6 simply is a no no. Even though they are saying, that they only are limiting the ICMPv6 traffic targeted for their router. It clearly affects us badly. How bad ? Check this out:
The gap that looks ok from the 23rd to the 24th is, when they shut the filter down after much arguing. However on the 24th, after we confirmed it is the filter, that is causing the issue, they just bloody turned it on again. Disregarding that the service is useless to us that way.
It also looks like in the likes of the issues with GBLX, we're probably going to kill that session and get IPv6 from KPN instead. Global Crossing engineers have no understanding for, that rate-limiting ICMP in IPv6 simply is a no no. Even though they are saying, that they only are limiting the ICMPv6 traffic targeted for their router. It clearly affects us badly. How bad ? Check this out:
The gap that looks ok from the 23rd to the 24th is, when they shut the filter down after much arguing. However on the 24th, after we confirmed it is the filter, that is causing the issue, they just bloody turned it on again. Disregarding that the service is useless to us that way.
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 17, 2008
Mikrotik RouterOS 3.15 release
The release of ROS 3.15 yesterday fixed quite a few bugs, that affected us.
IPv6 and IPv4 address families can now co-exist on the same BGP session (routing-test). That means, if our testing goes well, we'll be announcing IPv6 routes on INEX Vlan#2, too, very soon.
BIOS 2.18 fixes the issue, where 2.17 was killing ether3 on RB600 and ether2 and 3 on RB500 series.
The issue, that one couldn't disable dns resolving on traceroutes was really annoying for diagnostics as well.
They however broke adding static IPv4 routes via WinBox instead :( and my own RB600 router went into a non-recoverable state during upgrade. Something I haven't seen in a very long time. Netinstall and reload of backup fixed that though.
IPv6 and IPv4 address families can now co-exist on the same BGP session (routing-test). That means, if our testing goes well, we'll be announcing IPv6 routes on INEX Vlan#2, too, very soon.
BIOS 2.18 fixes the issue, where 2.17 was killing ether3 on RB600 and ether2 and 3 on RB500 series.
The issue, that one couldn't disable dns resolving on traceroutes was really annoying for diagnostics as well.
They however broke adding static IPv4 routes via WinBox instead :( and my own RB600 router went into a non-recoverable state during upgrade. Something I haven't seen in a very long time. Netinstall and reload of backup fixed that though.
Wednesday, September 17, 2008
INEX meeting, Dublin
Today was INEX meeting. As we're one of the newest members at the INEX, a presentation of the company was required, sort of. The talk can be found here. Unfortunately I didn't have the time to prepare it properly, it got hacked together the same morning, but well, very few people will notice the real hick-ups :).
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.
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)