Archive for the ‘Switches and routers’ Category

Cumulus attacks on Juniper (again)

Thursday, November 12th, 2015

I have a lot of time for Cumulus Networks – I think they’re doing some very cool and unique things with their Cumulus Linux operating system for switches and they genuinely have something different to offer, but when they publish blog posts like their one today (https://cumulusnetworks.com/blog/junipers-second-run-up-the-open-networking-mountain/) I lose a lot of respect for them.

This seems to be nothing more than a thinly veiled attack casting FUD (Fear, Uncertainty and Doubt) at a competitor – a knee-jerk reaction to a threat to their business. It actually reads pretty similarly to their blog post when Juniper originally announced the OCX range (https://cumulusnetworks.com/blog/juniper/). They’ve probably attacked other vendors in a similar manner.

For example, just by going to the main QFX5200 page on the Juniper web site (http://www.juniper.net/us/en/products-services/switching/qfx-series/qfx5200/), I find:

Open access to the standard Junos Linux kernel, enabled by the disaggregated version of the Junos software, allows users to install third-party Linux RPM packages and create guest containers and VMs with central resource management and programmable APIs.

Yes that still needs a little more detail, but it answers at least some of the questions and all it took was a couple of clicks! Imagine what you could find out by actually speaking to someone familiar with the details…

I have a few questions of my own for Cumulus Networks;

  1. Did Cumulus Networks actually attempt to find out the answers to any of these points yourselves? If so, were you unable to find the details, or did you just not like what you found so decided to feign ignorance?
  2. Will Cumulus Networks put their money where their mouth is and make sure that Cumulus Linux runs on the Juniper QFX5200 series of switches (assuming that Juniper are willing to co-operate)?
  3. Does Cumulus Linux currently run on any switches powered by the Broadcom StrataXGS Tomahawk chipset? It doesn’t seem to be listed anywhere on the Cumulus Linux HCL that you so helpfully linked to from your blog post.
  4. Does Cumulus Linux currently run on any switches which support 25G, 50G or 100G Ethernet ports? These also seem to be conspicuously absent from the Cumulus Linux HCL.
  5. When will Cumulus Networks offer a fully featured MPLS implementation on their Cumulus Linux control plane?

4GB of RAM on a Juniper J-Series router (J6350)

Wednesday, May 2nd, 2012

Officially the Juniper J-series routers such as the J6350 only supports a maximum 2GB of RAM. The J6350 comes with 1GB of RAM installed and if you want to add more then you have to buy your RAM from Juniper at inflated prices, however as the J-series are standard x86 machines with Netburst era Celeron and Pentium 4 processors you can simply install standard DDR400 RAM if you aren’t worried about being covered by JTAC support.

Not only does installing your own RAM save you a shedload of money compared to the Juniper equivalent part (JXX50-MEM-512M-S), but you can also exceed the “supported” 2GB maximum 4x512MB configuration, which provides additional memory to the control plane. The four memory slots present on a J6350 can take a 1GB DIMM each, however thanks to a 32bit architecture and mapping of the PCI bus into the same address space, you can only actually use 3.5GB of that 4GB.

The J-series routers are picky about what RAM they use however, so I like to stick to Crucial sticks; partly as that’s what Juniper use but mostly because I use Crucial elsewhere for their great customer service and a genuinely quality product. If you want to stick with a 2GB maximum then you can use Crucial part number CT2KIT6464Z40B, which provides 2x512MB sticks. Alternatively, Crucial part number CT2KIT12864Z40B provides 2x1GB sticks, allowing you to max the chassis out at 4GB across all four slots.

Once you’ve got all 4GB of memory installed in the chasis, boot the router up and from the JUNOS operational mode CLI issue the command “show chassis routing-engine” – you should see a total of 3584MB of memory split between 3008MB of control plane memory and 576MB of data plane memory. If you only opted for 2GB of memory then the 2048MB total will be split between 1472MB of control plane memory and 576MB of data plane memory.

Remember, you replace the RAM in your routers at your own risk and doing so will likely void your warranty as well as rending your system unspported by JTAC.

RouterOS slow learning BGP routes with Winbox open

Thursday, April 28th, 2011

After banging my head against a wall waiting for a RouterOS powered router to re-learn the 330,000 routes that currently make up the global routing table, I was surprised to find that seemingly Winbox slows the learning of BGP routes to a crawl. Closing Winbox allowed the router to process the entire global routing table in the normal minute or so, including passing through some complex filters.

It would seem that in RouterOS 4.x at least, the router is pushing details of all learned routes to any Winbox clients connected and slowing itself to a crawl in the process. I haven’t had a chance to verify if this affects all versions of RouterOS 4.x yet or test it on RouterOS 5.x

Cisco DHCP snooping with a Cisco DHCP relay (ip helper) and DHCP option-82

Wednesday, November 3rd, 2010

By default, the Cisco DHCP snooping code on the Cisco Catalyst switches inserts option-82 into the DHCP packet but sets giaddr to 0.0.0.0, which causes the Cisco DHCP relay (ip helper) to drop all DHCP packets from a Cisco switch configured with DHCP snooping.

To work around this, you can either disable the insertion of Option-82 on the switch performing the DHCP snooping with:

no ip dhcp snooping information option

Or alternatively you can configure the Cisco device acting as the DHCP relay to trust DHCP packets with giaddr set to 0.0.0.0. This can either be done on all interfaces with the global command

ip dhcp relay information trust-all

Or on a per-interface basis with

ip dhcp relay information trusted

Remember, if you are applying the trust to a specific interface then it has to be the layer 3 interface with the IP helper on it (such as an SVI) and not the layer 2 interface that the DHCP packets are received on.

SSH on a HP ProCurve

Sunday, July 4th, 2010

By default HP ProCurve devices (like most switches) use telnet and TFTP (Trivial File Transfer Protocol) for management access, firmware upgrades and config backups. As these are both unencrypted protocols, it is a good idea to switch to using SSH and SCP/SFTP in order to secure your management access and all important configuration, which you can do with the following commands from configure mode:

crypto key generate ssh
ip ssh
ip ssh version 2
ip ssh filetransfer

This generates the keys that SSH requires, forces SSH to use the newer version two of the protocol and enables SCP/SFTP support for copying files to and from the flash.

As soon as you enable SSH filetransfer (basically SCP/SFTP) support then TFTP is disabled, but you have to disable telnet access manually in configuration mode with:

no telnet-server

Changing the MAC address of a VLAN interface in Mikrotik RouterOS

Saturday, July 3rd, 2010

Do you want to change the MAC address of a VLAN interface in Mikrotik RouterOS? Are you baffled by the fact that although the VLAN interface has a MAC address property inherited from the parent Ethernet interface, it isn’t editable?

Well, you’re in luck, it isn’t actually impossible to give your VLAN interface a different MAC address to it’s parent interface, you just have to go about it in a somewhat roundabout way by making what is effectively a virtual Ethernet interface and bridging it to the VLAN interface. You then add your layer 3 IP functions to the bridge interface instead of to the VLAN interface.

First, you need to create a bridge and give it a name, then add the VLAN interface who’s MAC address you want to change to the bridge as a port. Finally, set the “auto-mac” property on the bridge to “no” and then change “admin-mac” property for the bridge to be whatever you want your new MAC address to be

/interface bridge add name=newmac disabled=no auto-mac=no admin-mac=”00:00:00:00:00:00″
/interface bridge port add bridge=newmac interface=vlan1

RouterOS v4.x and BGP

Wednesday, January 20th, 2010

Just a quick heads up for those using upgrading from RouterOS 3.x to 4.x and using BGP to announce a default route to any of your peers; you need to set “default-originate” to “always” or “if-installed” for each peer you have configured in RouterOS if want to announce the default route to. This setting is off by default in v4.x so can cause havoc when you upgrade! 🙁

On the warpath

Sunday, August 3rd, 2008

Hey, guess what? In typical Edward style, it has been ages since I updated this thing and I still haven’t got the site working fully or using a custom skin. I have an excuse… I am busy/lazy (take your pick!) 😉

I got back from going to see “The Dark Night” a couple of hours ago. It’s a bloody good film but ‘m annoyed that I saw the plot twist coming right from the start – being a bit of a batman fan, I recognised the character as soon as a bloke called Harvey showed up with what correctly I guessed a double headed coin that he uses to “make his own luck” 😉

When I got back I set about unlocking Naomi’s old Sony Ericcson phone that she kindly gave me to replace my ageing Panasonic GD67 (circa 2003 and a hand me down via Matt) that does interesting things including randomly turning itself off.

6 weeks ago I requested a NUC (network unlock code) from Vodafone which they said would take between 5 days and 6 weeks to generate. So I patiently waited and when 6 weeks rolled around on Friday, I sent them a very angry e-mail telling them to pull their collective fingers out. This morning I got a reply telling me that they had generated a new code on the 24th of June (4 days after I had e-mailed them jumping through numerous hoops to prove that I hadn’t stolen the phone from Naomi) but that they “forgot” to e-mail it to me.

Incompetence or company policy not to co-operate with NUC requests? I’d go for the second one personally.

Phone unlocked, I set about learning how to use it and telling Naomi it was finally working. It seems quite nice but it’s such a change it’s going to take a lot of getting used to. At least it’s well built (unlike the Panasonic) and has fairly intuitive menus (unlike the Panasonic). It’s still not a patch on my 2G iPhone though 😉

My good mood was destroyed shortly after my unlocking success when I attempted to order a pair of power supplies from Rapid Electronics (you don’t get a link you bunch of incompetent tits!). My order was very simple, 2 power supplies delivered to one address but billed to another. Yet, despite providing a text field for your billing address, it’s not editable. At first I thought this was a browser issue so I changed from Safari to Firebox but still it didn’t work, They seem to want me to call their sales line for what is clearly a complicated procedure for them (instead of standard everywhere else) so instead I sent them an indignant e-mail telling them to learn how to build web-sites. I don’t expect that it will make the blindest bit of difference but it calmed me down somewhat.

If anyone from Rapid is reading this, the solution to your problem involves a 9mm bullet and the head of everyone in your web design department 😉

In an attempt to restore my mood (or possibly swing me ever deeper into a pit of despair) I set about the task of conducting a post-mortem on the two RouterBOARD 433AH boxes that were playing up when I tried to put them in Node4 almost a month ago.

At the time, one of the power supplies decided to fry itself and then the box running on the remaining power supply started behaving erratically. When setting it up I had been able to log into it fine but now my SSH session would hang as soon as the management shell spawned after authenticating.

Because of this we made the decision that we couldn’t trust any of the equipment and aborted the install until we had been able to examine what the problem was.

After about five minutes I managed to work out the really stupid and annoyingly simple reason for the SSH sessions hanging… there is an incompatibility between Mac OS X’s Terminal.app and the management shell in RouterOS version 3.x. The simple fix for this is to re-seize the Mac OS X terminal window as soon as you log in. This forces some kind of refresh which fires the RouterOS management shell back into life.

It seem that MikroTik have no intention of fixing this annoying bug and are blaming it on Apple instead 🙁

With that fixed (or at least explained), as soon a I can order some power supplies from a slightly more competent supplier than Rapid then maybe we can finally get this equipment installed.

One good thing did come out of the problems with the RouterBOARDs, I stumbled across the wiki page detailing the new support for Xen virtulization in RouterOS 3.11, a fantastic feature that I’ve been campaigning for for a long time but somehow missed the announcement for! I will have to have a play with it some time, but for now my bed beckons as tomorrow, more DIY awaits… 🙁