Showing posts with label switch. Show all posts
Showing posts with label switch. Show all posts

Thursday, October 2, 2014

Is it the end of the TOR as we know it?

There are two driving forces that may break the TOR (Top of Rack) switch market.

The first one is the spiraling fall of switch prices. Competition among white box switch makers Cumulus and Pica8, incumbents such as Juniper and Cisco and new startups Arista are pushing margins ever so slim. Pretty much all the vendors sell the same exact TOR switch. Currently it’s a 40x10GE port switch with 4x40G uplinks with a Broadcom chip set. The only difference really is the Operating System. All this competition basically means a race to the bottom. I see a few outcomes of this market. 

If you’re an enterprise like Facebook or Google, you have the technical savvy and economics of scale, to OEM just the physical hardware components and put on it a stripped down version of linux that does specifically what you need. Facebook already has a blue print for one called the Wedge. This means, none of the vendors can sell to these customers.

Next you have a customer that is DevOps savvy, but doesn’t want to build their own switches. These can be startups or large customers that have a good engineering team. They probably buy a TOR switch such as Pica8 or Cumulus and automate on top of these boxes. They don’t need much support.

Last you have a customer who just needs support so they just buy a brand named switch. These can be large Enterprises that are not technical enough to program their switches. These are the Coca-Colas and traditional companies where technology is not in their wheel house. I mean does Coca-Cola need SDN? 

The second driving force is on the physical hardware side. Intel has announced the roadmap of the Rack Scale Architecture (RSA). They want to dominate the cloud computing infrastructure by providing mega scale data centers with a highly scalable solution. To understand what this means we have to see the trends of the current data center.




Currently in a typical rack you have several servers. Each server is usually kept in a server tray or server blade. If you break it down, a server has the following components. A CPU, Memory, Storage (HDD or SSD) and a Network Card. You might have some other peripherals, but you don’t really need them. All of these components interconnect via a PCIe fiber connection. Now this PCIe fiber connection is the key component.






If you disaggregate servers, you can create pools of resources. You can have a pool or tray of CPUs, a pool of Memory and a pool of storage. When you need to upgrade, you pull out the tray and  swap in a new tray of resources. To connect all these together, Intel created silicon photonics PCIe (SiPh). These have speeds between 40-50Gbps in a single optical fiber. If you think about it, a majority of traffic runs east and west in a datacenter. With SiPh you can send traffic, intra-Rack at 50Gbs. 


You don’t need a TOR switch because you can do this using a virtual switch and SiPh. You can bypass ethernet connections by connecting directly to another logical server over the PCIe connection. Why waste time going out an ethernet port up to a ToR switch and go back down to another NIC to get to a server when you can directly. You can shave even more nano seconds of networking speed.

Now you can say that traffic going between logical servers could eat up CPU, therefore you need a ToR switch to speed this up.  If you need hardware acceleration, then Intel could just place a Fulcrum Switch Chip in the rack as a resource. North/South traffic or Inter-Rack traffic would egress the RSA via uplink ethernet connections. Again with RSA, you could create a separate Ethernet Resource pool of NIC for interconnects. Some people may wonder why? I mean have separate servers does the job just nicely. Also with all the resources pooled together, you really need  DevOps team that can program the Rack. Well if I was Intel I'd target the Financial Industry. They would pay for the shaving of speeds that RSA could save. They have an Army of DevOps who can do this.

Wednesday, June 18, 2014

Op script - Interface auto-description based on lldp learned neighbors

A coworker said that Arista had this python PortAutoDescription script that auto populates the ports on a switch with it's neighbor description learned through lldp. He was wondering if Juniper had such an implementation. Well this is not built into Junos, but is really easy to do as a SLAX script.

Here it is in action:

{master:0}[edit]

jnpr@SW1# run show lldp neighbors

Local Interface    Parent Interface    Chassis Id          Port info          System Name

ge-0/0/47.0        -                   00:21:59:c7:09:40   ge-0/0/47.0        SW3b               

ge-0/0/44.0        -                   78:19:f7:9f:77:00   ge-0/0/44.0        SW2b               



{master:0}[edit]

jnpr@SW1# show interfaces

ge-0/0/44 {

    unit 0 {

        family ethernet-switching {

            port-mode trunk;

            vlan {

                members all;

            }

        }

    }

}

ge-0/0/47 {

    unit 0 {

        family ethernet-switching {

            port-mode access;

            vlan {

                members v100;

            }

        }

    }

}



{master:0}[edit]

jnpr@SW1# run op IntAutoDesc

lldp-local-interface ge-0/0/47.0 connected to lldp-remote-system-name SW3b

configuration check succeeds

commit complete

lldp-local-interface ge-0/0/44.0 connected to lldp-remote-system-name SW2b

configuration check succeeds

commit complete



{master:0}[edit]

jnpr@SW1# show interfaces

ge-0/0/44 {

    description to-SW2b;

    unit 0 {

        family ethernet-switching {

            port-mode trunk;

            vlan {

                members all;

            }

        }

    }

}

ge-0/0/47 {

    description to-SW3b;

    unit 0 {

        family ethernet-switching {

            port-mode access;

            vlan {

                members v100;

            }

        }

    }

}

SOURCE CODE
----------------------------------

version 1.0;

ns junos= "http://xml.juniper.net/junos/*/junos";

ns xnm= "http://xml.juniper.net/xnm/1.1/xnm";

ns jcs= "http://xml.juniper.net/junos/commit-scripts/1.0";

import "../import/junos.xsl";

match /

{

    <event-op-results> {

        var $lldp-info = <command> "show lldp neighbor ";

        var $lldp-result = jcs:invoke($lldp-info);

        var $con = jcs:open();
        for-each($lldp-result/lldp-neighbor-information)

        {
                var $lldp-int = current()/lldp-local-interface;
                var $lldp-remote = current()/lldp-remote-system-name;
                <output>local-name($lldp-int) _ " " _ $lldp-int _ " connected to " _ local-name($lldp-remote) _ " " _ $lldp-remote;

        var $if = substring-before($lldp-int, ".");
        var $int = <configuration> {
           <interfaces> {
              <interface> {
                       <name> $if;
                       <description> "to-" _ $lldp-remote;
               }
             }
        }

        call jcs:load-configuration($connection = $con, $configuration = $int);


        }

        expr jcs:close($con);

      }

}

Thursday, April 24, 2014

Python on the Juniper QFX 5100

I noticed that the Juniper QFX5100 has a python interpreter included in Junos. This is new to the Juniper platforms. From the data sheet this is for management support. I know that Arista allows python scripting on their switches, so my guess is this is supported to keep up with the competition. This is a good first step for Juniper. While slax scripting is powerful, the learning curve for most networking engineers is steep and almost proprietary as you really have to know Junos. Slax is not transferrable to other vendor platforms, while python is.

Juniper's Python is accessible from the shell.

user@QFX5100> start shell

root@QFX5100% python
Python 2.7.1 (r271:86832, Jan 21 2014, 12:38:40)
[GCC 4.2.1 (for JUNOS)] on junos
Type "help", "copyright", "credits" or "license" for more information.

However I don't know what modules bundled in the OS are used to actually access Junos API.

>>> help ('modules juniper')

Here is a list of matching modules.  Enter any module name to get more help.


>>> help ('modules junos')

Here is a list of matching modules.  Enter any module name to get more help.


>>> help ('modules jnpr')

Here is a list of matching modules.  Enter any module name to get more help.

I did find that it does support telnetlib.


>>> help ('modules telnet')

Here is a list of matching modules.  Enter any module name to get more help.

telnetlib

>>> exit()

Which means you can actually access the QFX via telnet. In the below script I telnet to the switch and send a broadcast message

root@QFX5100% python hello.py
                                                                             
Broadcast Message from jnpr@SW3a                                            
        (/dev/ttyp2) at 22:32 PDT...                                        
                                                                             
hello world                                                                  

----------

I'm not when the Junos API will be available or how to access it. I'm guessing there may be some restrictions for this as you wouldn't want have a hacker creating mischief with python scripts.


source code:
root@QFX5100% more hello.py
---------------------                                                                            

import sys
import telnetlib

HOST = "192.168.1.1"
tn = telnetlib.Telnet(HOST)

user = "user"
password = "password"

tn.read_until("login:")
tn.write(user + "\n")

tn.read_until("Password:")
tn.write(password + "\n")

tn.read_until(">")
tn.write('request message all message "hello world" \n')
tn.read_until(">")
tn.write("exit\n")

tn.close