Showing posts with label cisco. Show all posts
Showing posts with label cisco. Show all posts

29 December, 2014

Open networking; leaf-spine...

I recently came across a norwegian tech-article regarding open networking vs proprietary networking.

More specifically, it talks about the Open Compute Project - for those of you who don't know, read this. More information can be found here.

The project discusses the use of open standards when building huge, energy-demanding and efficient data-centers. Basically, OCP talks about replacing the common standard networking architecture with something (kind of) new, to meet the ever evolving (and consequently; demanding) bandwidth and streaming of tomorrows data-centers. Mainly, replacing the tree-span network-design with the leaf-spine network-design.

A leaf-spine network design consists of the following:

  • Top-of-rack (leaf) switches (leading to spine-switches).
  • Spine-switches (between leaf- and core-layers in a leaf-spine network).
  • ... and other hardware and software solutions for rack-use.
LEAF-SPINE NETWORK
In a so-called "leaf-spine" layer-2 network; the spanning-tree protocol is often replaced with either a version of Transparent Interconnection of Lots of Links ("TILL") or Shortest Path Bridging ("SPB").

In a leaf-spine layer-3 network; each link is a routed link. Open Shortest Path First ("OSPF") is often used as the routing-protocol to compute paths between leaf and spine switches.

The norwegian in me thinks the reporter has (way too) big expectations, especially if he's counting on norwegian authorities and heavy industry for this (quite HUGE) change to take place.

But on the other hand, my inner sysadmin really likes the possibility of administrating a data-center with fully open networking-protocols / -equipment and/or -hardware :)



My own little ยต-datacenter is based on open protocols, open systems, and somewhat open hardware.
http://blog.pizslacker.org/2014/10/datacenter-so-far.html

Norwegian article:
http://www.cw.no/artikkel/kommentar/apent-ikke-proprietaert


14 April, 2008

Cisco Turns Routers Into Linux Application Servers

I've always had a good eye to Cisco's networking equipment, due to the fact that they are administered through a CLI (Command Line Interface), i.e.: POSIX-style ;^)

Now they're integrating a GPL'ed Linux environment on certain so-called "AXP" switches/routers to allow for hosted applications developed with the accompanying standardized SDK and API (which includes standard support for C, Java and Python).

"From a GPL perspective, we've taken all the things that are GPL and reciprocated the code back to the community," Conover said. "Obviously if a developer built an application on top of a GPL platform, that doesn't imply that they have to GPL that code. "


The GPL is a reciprocal license that requires any modification made be contributed back to the community.


Overall, Cisco expects the AXP to reduce the hardware footprint at branch offices and provide deeper network integration that provides IT managers with more control over what they can monitor.

I suppose they realized the potential for hosted applications on network equipment after releasing the WRT54** series of routers through their sister company "Linksys". These routers offer the possibility to flash the firmware, allowing home-brewed firmware/software to be deployed. I have a WRT54GL router @ home, running "DD-WRT" with a few cross-compiled custom apps for network monitoring. And I must say, it gives me monitoring capabilities I never could have imagined a few years ago ;)

02 March, 2008

MASQUERADE / NAT

I knew this was some kind of unfinished technology, it somehow felt...like it wasn't a fully standardized method of implementation. Every time I've had more and more experience using this, I've always found new ways of using it, and alternative methods to boot. I don't fully understand the concept of complex protocol transmission yet, but my job let's me see the usage of NAT in WAN deployment.

This is the current, most widely used method of setting up transmission backbones from a large customer-base from within an ISP with limited IP ranges.

Or from my own setup @ my mom's place: forcing a medium-sized LAN to share an Internet access with 2 dynamic, restrictive IP addresses (one of which is switched between two internal cabled LANs, and the other serves as the Internet access for the wireless LAN) and one static, fully public, NAT'ed point-to-point IP address to serve my private DMZ.

Caveats using NAT

In computer networking, network address translation (NAT, also known as network masquerading, native address translation or IP masquerading) is a technique of transceiving network traffic through a router that involves re-writing the source and/or destination IP addresses and usually also the TCP/UDP port numbers of IP packets as they pass through.

[...] there are quite a lot of minor caveats with using NAT. The main problem is certain protocols and applications which may not work at all. Hopefully, these applications are not too common in the networks that you administer, and in such case, it should cause no huge problems.

The second and smaller problem is applications and protocols which will only work partially. These protocols are more common than the ones that will not work at all, which is quite unfortunate, but there isn't very much we can do about it as it seems. If complex protocols continue to be built, this is a problem we will have to continue living with. Especially if the protocols aren't standardized.

The third, and largest problem, in my point of view, is the fact that the user who sits behind a NAT server to get out on the internet will not be able to run his own server. It could be done, of course, but it takes a lot more time and work to set this up. In companies, this is probably preferred over having tons of servers run by different employees that are reachable from the Internet, without any supervision. However, when it comes to home users, this should be avoided to the very last. You should never as an Internet service provider NAT your customers from a private IP range to a public IP. It will cause you more trouble than it is worth having to deal with, and there will always be one or another client which will want this or that protocol to work flawlessly. When it doesn't, you will be called down upon.

As one last note on the caveats of NAT, it should be mentioned that NAT is actually just a hack more or less. NAT was a solution that was worked out while the IANA and other organisations noted that the Internet grew exponentially, and that the IP addresses would soon be in shortage. NAT was and is a short term solution to the problem of the IPv4 (Yes, IP which we have talked about before is a short version of IPv4 which stands for Internet Protocol version 4). The long term solution to the IPv4 address shortage is the IPv6 protocol, which also solves a ton of other problems. IPv6 has 128 bits assigned to their addresses, while IPv4 only have 32 bits used for IP addresses. This is an incredible increase in address space. It may seem like ridiculous to have enough IP addresses to set one IP address for every atom in our planet, but on the other hand, noone expected the IPv4 address range to be too small either.
The only grieveance for me in this sense, is the loss of opportunity to serve. I cannot set up SSH, Apache or any other form of server-application to establish outgoing connections based on incoming requests through this NAT setup. So, that's why I had to acquire a point-to-point IP address and route it manually to my DMZ. The problem I have now, is the lack of cabled internals in our house. I had to devise a hybrid LAN on both cabled and wireless connections to achieve my goal.