Tag Archives: Switching

CCNP certified

CCNP_large

The last couple of weeks I’ve spent some time dealing with a little adversary. The Cisco CCNP has been a want for a while and I started the quested and my pace did slow off. Well finally I made it last Friday and validated two years of hard work by earning my CCNP in Routing and Switching.

Route

In September 2011 I sat my first exam. I had been studying for close to 5 months. At this stage I worked in an environment that was basic switching and minimal routing. I was exposed to GNS3 and such tools to aid myself. This was fantastic. I managed to make and reproduce diagrams in the Official Certification Guide and Foundation Learning Guides. These enabled me to learn what was being taught. What I did lack though was the confidence to explore and see how they applied to business solutions. This is one weakness of most certification streams.

On a rainy September day back in 2011, I sat down to an exam I thought I was under-prepared for. The exam itself was surprisingly easy in comparison to the material and labs I was working on. I faced a good selection of questions from all topics. A lot focused on OSPF and not a lot else! This was good for me but it felt a little biased. I walked out of that exam having seized a score of 864/1000. Not bad for a young upstart who had a Microsoft background.

Switch

I’ve never liked switching – this is due to my loathing of STP – and I’ve found the content dry. I think my disposition worked against me in the earlier days. Using the SWITCH books from the OCG and FLG series, I proceeded to study and learn. I only had a production environment to learn on and resources at hand. It found command line were the biggest issues.

The first time I failed. I got a 781/1000. Those who have sat this know this is excruciatingly close to a pass. I was annoyed. I blamed external factors initially but upon reflection I saw it as a blessing in disguise. I learnt my weaknesses, I learnt my weak spots. I found out where gaps in my knowledge really were. VACLs and other silly things. Little things. I learnt also to read the words closely. Acronyms or phrases used in a book such as Cisco Press might be named differently in an exam. I fired up the exam engine after spending some time chasing some other certifications (JNCIA-JUNOS, JNCIS-ENT, and moving jobs). I passed. This time I scored a 846 and felt a great sense of relief. This allowed me to affirm my skill set and I attribute my job change to a larger switched environment on this new knowledge.

Troubleshoot

This exam is fantastic. Honestly, I did not study for this. I read the first chapter of the book for the multiple choice theory based answers. The rest I just walked in. At this stage I had a decent set of switching and troubleshooting skills. These skills have allowed me to develop as an engineer. This exam is based on 13 troubleshooting tickets. Each ticket allows you to use a static topology and identify issues as they arise. Pretty awesome if you ask me. A real world simulation.

Well needless to say this exam was a blast and I put my skills into full flight. I attempted this exam and scored a 1000/1000. It was a thorough and fair test though my only gripe is the following. You can use your fancy show commands to validate and test (the ones they allow you to use)  but you can play spot the difference with show output and figure the issue.

Final Thoughts

Well, I am now a CCNP Routing and Switching. This is something I’ve wanted for some time now. Having this certification means now I can close a chapter of on a certification. Three exams, one certification, and one good sense of feeling inside. Now on the radar, I have planned JNCIS-SEC and VCP5 DCV, and then a chat to the wife before I walk down the path of CCIE for real. I think I can knock off the written by the end of the year!

I’d like to extend a thank you to everyone who has supported me or offered help, and to the blog writers and readers in our community. The Network Engineering fraternity is a superb group of people!

NX-OS and Cisco Nexus Switching

The data center is ever evolving and in the heart of many is the Cisco Nexus platform. This device series has many different opinions based on who you speak to. Birthed out of a secret project, the Nexus family hit the market with a modular OS, and focused on fast DC switching.

This book reviewed will be the subject of this post. Ron Fuller gave me an electronic copy of this book via Ciscopress.com. This was a gesture of good faith from an industry professional to another. No expectation of a blog was discussed let alone anything in return for this.

About the Book

Ron Fuller, Technical marketing engineer for the Nexus 7000, has gathered with fellow authors once again. Their unrivaled knowledge has been pooled and they have delivered the second edition of the ever popular NX-OS and Cisco Nexus Switching: Next-Generation Data Center Architectures.

Released by Cisco Press on the 18th of March this book is a 847 page whopper. Delivered in a variety of formats it will appeal to those with a physical or digital need. Cisco Press online allow for delivery in pdf, mobi, and epub formats. PDF is great for reading on my mac book whilst epub suits my train ride with my Nexus 7. The watermark is subtle with the note “From the Library of Anthony Burke” on each page down in the right hand corner. I like this minimal amount of watermark as I find some can be painful. A bonus too is that it is not a secure PDF or locked with LockLizard or something like that.

Book overview

The style of this book alternates between a technical recital and then an example. The tone used by the authors change a little between sections. Albeit I do not know who wrote each section you can determine a different author here and there. This is not a bad thing but I definitely preferred one sections writing style to another.

The style of the book plays well to my learning habits. I like the technical nature upfront then some configuration examples. This allows you to playt along at home. After the basics have been covered alternates and add ons are introduced. If you follow the flow of the book you can start out with nothing and end up with a very functional DC skill set. Each chapter builds on each one before it but if you have had exposure you can pick up any topic at any place.

The chapters I found most interesting we definitely OTV and LISP. The overlays were discussed in detail with references to external resources and strong implementation knowledge. I felt like I could go an apply an overlay with confidence. The LISP chapter also brought to the forefront the technology behind it and also how it is achieved. The use cases came very apparent after a re-read.

With virtualisation rife throughout DC’s world-wide, network virtualisation is a hot word of CEO’s lips. This book focuses a lot on how to unlock the Nexus platform’s ability to accommodate multi-tenant data centers and hosted offerings.

The best addition was a case study at the end. This focused on an existing environment moving to the nexus platform. It outlined goals, the design, the migration plan, example outage windows and what occurred within each, and ended with ongoing windows and a summary. If you weren’t a customer before hand, they definitely demonstrated the power that NX-OS can bring to your DC.

Rating

Overall this book follows up on the precedence the first set. A technically accurate book with clever and relevant examples serves as a good desk side reference for any DC engineer. I give this book a 8.5/10.

Thanks Ron, David, and Matthew.

 

Plexxi Control

The previous post to this one in my Plexxi series discussed the platform in which Plexxi deliver their software solution. The hardware was rounded off and numbers fired off. The optical cable pass through and topologies were discussed. That was a beginning. If you were wowed back then, wait to see what Plexxi control can do for your network.

The word affinity has now become synonymous with Plexxi in the SDN space. Affinity based networking is what their caper is. Well what is it? First lets define affinity.

A similarity of characteristics suggestion a relationship‘. Think on that whilst incorporating network traffic and their flows. Storage traffic requires fast forwarding, cannot tolerate loss, and cannot tolerate corruption. Web traffic is bursty, transactional, and bandwidth can spike on demand. Plexxi seeks class traffic with affinities and then take it one step more. Bandwidth sensitive? No worries. An affinity can command x amount of bandwidth. A customer requires path isolation for their payment gateway to the exclusion of all others? Sure, assign your requirement to your relevant traffic affinity and you have the magic. Now this is all well and good assigning requirements and stipulations to affinities but how does one apply them. Plexxi Control helps us out here. This Virtual machine or hardware platform is the smarts behind the solution.

Plexxi Control leverages a broker to conduct communications between the controller and switches. The broker is the conduit between the two devices. Control and the underlying topology work on the theory that you are going to device your important affinities first. This can be done through an automated set and get. Over time as you learn and classify your traffic you can improve your affinities over time. You can create manual overrides too or set affinities to take place. An example of such would be Backup or vMotion traffic every Tuesday, or dynamic bandwidth allocation based on a event. Every time an affinity is laid down, the Plexxi controller will rework the topology to suit. This logical adjustment leverages the LightRail technology as discussed in the previous post. Dynamic flow based network topologies are here!

The venerable Terry Slattery asked two important questions. The first ” How can you track and create affinities ” and the second ” What if you had 1,000,000 affinities or flows per second?”. Both of these questions were very well thought out in my opinion. The reason being Plexxi’s target market is the Data Center. This without a doubt can scale from a dozen flows to countless numbers. If all customers required path isolation, having 12 east and 12 west will quickly dry you up. This is something that I believe we will see answered in time with tried and true deployments. Plexxi were rather tight lipped regarding some deployments. Feel free to comment if you’re reading guys!

Now with all of these smarts in the box many of you may be screaming “STAHP” Isn’t this a single point of failure? Well it is though it isn’t performance affect. You lose the ability to define and push out new affinities. What ever affinities are down on the Plexxi Switches stay on there all the while forwarding, and very fast forwarding at that , is continuously occurring. When the Control VM comes back on line you will gain your web interface back.

My thoughts on Plexxi control were initially mixed. At the start, I saw the potential then started to think of scale. They addressed some points which garnered confidence then Terry broke my vision open again. I know as the product matures, their engineers, lead by brilliant minds such as Derick, Mat, Martin, and others, will overcome this. In the brave new world of SDN and flow defined automation, someone has to start somewhere. Plexxi are a long way ahead of many companies. Most of those are still defining, most of those still wallowing.

 

 

Who needs more than 4094 VLANs?

First world DC problems

Cloud computing has thrust multi-tenant DC’s forward in their advancements. The elasticity required for rapid deployment has pushed the bounds of many fields including storage, virtualisation, server architectures, and orchestration. As our environments onboard different customers in a multi tenant data centre, path isolation, and Equal Cost Multi Path (ECMP) becomes a requirement.

Path isolation can be performed at Layer 2 and Layer 3. Traditional Layer 2 isolation has been performed by putting Customer A into VLAN 10, Customer B into VLAN 11. Layer 3 isolation can per applied through VRFs, overlays, and other technologies.

If a cloud provider services a bulk of customers that all require path isolation – and you expect this to be the case – then VLAN allocation will dry up fast. A DC may want to offer ECMP to a customer providing them with an interconnection with the use of IP for interconnection. They will also want to maintain and preserve the Layer 2 model for inter-VM communications.

Encapsulated overlay

A solution exists. It has been put forth by our pals at Cisco and VMware is VXLAN. Entitled VXLAN: A Framework for Overlaying Virtualised Layer 2 Networks over Layer 3 Networks.

VXLAN is an overlay network that helps alleviate the problems of the cloud network environment. By addressing L2 and L3 DC network challenges of ever moving virtual machines, administrators can over come constraints of traditional networking.

You can like VXLAN to Layer 2 over Layer 3. Each different overlay is referred to as a VXLAN segment. VXLAN segments differs from a VLAN segment in that it uses a 12 bit – opposed to 12 bit – segment ID. This allows 16,000,000 VXLAN segments to be assigned. A vast improvement over 4096. The VXLAN Network Identifier (VNI) represents the segment.

The VNI wraps itself around the existing MAC frame that came from the existing VM. It protects the existing frame this way, allowing new information to be written and interpreted by network devices along a given path.

Screen shot 2013-03-21 at 2.17.31 PM

VXLAN is , due to the outer wrapper, or envelope, essentially a tunnelling mechanism. With L2 wrapped around the traditional L3 and L2 packet. VLAN Termination end points (VTEP) are located in hypervisors on servers. These VTEPs strip VNI information before the hypervisor passes a VXLAN frame to the server. The guest never sees it. Hardware termination of a VTEP inside a switch is also possible, though it requires certain chipsets such as a Trident II. The Trident II supports VXLAN and VTEP termination.

My mind wanders to two hosts that are separated by a layer 3 segment. They could even be in the same layer 2 segment. They could be in different racks in different parts of a data centre. VXLAN would then be overlaid upon the aforementioned networks.

Half a dozen VNI’s could be in each hypervisor of each host. Between each host in separated L3 subnets, a logical tunnel is formed between VTEPs. Guests on the host seeking to communicate to other hosts with the VNI can due to the overlay. The host believes it is in an adjacent network.

A switch acting as a VTEP gateway could host servers behind it and do the termination on the switch itself. This would allow a different topology to be formed. This requires support in the hardware as well as software. Over time this will be default in silicon.

My thoughts

The notion is how MPLS label switches across a WAN core and strips labels accordingly. Well, at least it is in my head. Moving forward I believe this overlay may find more traction as it can be terminated in a hypervisor. Upgrade your cluster and you’ll have support. With announcement of NSX, it is time to understand VXLAN overlays.

 

 

 

 

VMware NSX

For a while I pondered the benefits of a vSwitch and enjoyed the notion of a distributed vSwitch. These items were extremely flexible for virtual networking in VMware’s hypervisor switching construct. The ability to create VLANs, port groups, PVLANs, automated deployment, and adapt to pretty interesting networking requirements in software was nifty. The let downs were there though. It seemed that VMware’s switching construct was missing something. Then the announcement that made sense came, albeit in a “I can do anything, anything better” way.

Fresh of the bat of the Nicira purchase, the virtualisation platform that was snapped up by VMware has bore fruit. Under the ever watchful eye of Brad Hedlund, VMware has produced a programmable, flow defined, networking construct.

The human friendly web-driven GUI allows for simple and easily deployed networking assets. Distributed cluster wide across multiple ESXi hosts, an engineer can engage in fast forwarding, feature rich, software networking virtualisation. Programmable API’s allow access into the NSX platform to provide harmonious integration with VMware and OpenStack.

he VMware NSX platform is launches with five cornerstones: Controller Cluster, Hypervisor vSwitches, Gateways, Ecosystem partners, and NSX Manager.

Controller Cluster

This virtualised x86 application takes northbound API requests and turns them into operations. The NSX controller cluster is logically centralised but physically distributed amongst cluster hosts. As an environment grows, the ability to extend the controller cluster is as  simple as expanding the control cluster. The NSX controller has visibility of all network devices and guests deployed with NSX.

Hypervisor vSwitches

The control cluster takes control of the in built in kernel vSwitch already existing in each host. Intelligence in the networking software coupled with scalable flow programming switching opens many doors. By leveraging such technologies as VXLAN and STT, IP encapsulation can take place between hypervisors. This notion brings to networking what virtualisation brought to physical servers.

Gateways

Gateways are what provides a path back into the physical world, or as VMware state, the edge of the software defined data centre. NSX Gateway nodes can be deployed in active/active HA pairs, and offer IP routing, MPLS, NAT, Firewall, VPN, and Load Balancing services. This allows many engineers to securely control northbound and southbound traffic at borders of NSX networks. I am picturing these gateways like a NSX distribution layer. It is also possible to create a Layer 2 gateway.

Well played VMware.

Ecosystems Partners

This part I need to read more on but from what I can gather this is about open source communication and creating a well-defined trust relationships within the network. Read more here.

NSX Managers

NSX manager is the GUI that controls the network above. It is a dashboard that contains logs, network information, deployment status, and traffic information right at an engineers finger tips. This will be the heart of NSX deployments as it is rolled out. THe physical and virtual world will be easily mapped with diagrams and charts automatically generated. I like this automatic documentation! The system is also capable of automatic snapshots and system recovery; the same as a guest current has access to now.

Thoughts

This is the first real viewing of what Niciras acquisition by VMware has eventuated to. By first accounts I am impressed by some things such as programmability and the fluid deployment nature. I still worry that ESXi administrators won’t consult with networking staffs who provide their DC platform for their servers. Hopefully the NSX push will bring the silos together. At the moment, it feels like server, networks, and applications are being smooshed together like a terrine. Prepare for terrine takeover Q3, 2013.

Plexxi Switch

The Plexxi switch is an offering from Plexxi networks that forms a part of their overall SDN package. This device differs from traditional hardware solutions in ways that are quite unexpected. Built on merchant silicon, namely the Trident II chipset from Broadcom, this device, known a Switch 1, offers 32 x 10GB SFP+ ports, 2 x 40GB QSFP+ ports in a 1 RU device. Switching capacity sits around 1.28 Tbps which provides a 3:1 ratio. With the Trident II chipset a technology called Smart NV allows VXLAN and VTEP support out of the box. This chipset can even blast 100 x 10GB ports which is quite frankly awesome.

Where the real difference in the Plexxi offering comes with the LightRail technology. This technology offers passive optical multiplexing IN the device. This allows for terabits of data across one single cable. Using up to 24 2-degree WDM fibers split across two groups, Plexxi Switch 1′s can form a number of physical topologies which very high bandwidth throughput. By building this technology inside the switch you essentially eliminate the need for old styled aggregation switching. A reduction in complexity, design, and TCO.

An alarm bell might ring with some of you thinking about your cabling passing through a switch? Fear not. Being passive pass through, the Plexxi Switch’s LightRail still functions when a device turns off or fails. You still can pass traffic through a device that is offline. With 24 fiber cores per link per switch, you many and varied number of paths to move data affinities* around to isolate a switch to be replaced. With 24 x 10GB fibres as mentioned in the Network Field Day 5 presentation, they are broken into a 12 east, 12 west layout. That is around 240Gb per switch and when you look at a 10 to 11 Plexxi switches in a ring you will be looking at 2.64Tb forwarding capacity!

With infrastructure patching literally in the switch and LightRail cables pushing terabytes of data a thought must be spared for design. It gets gosh darned simplified physically. One cable into the switch and one cable out of the switch.

Screen Shot 2013-03-17 at 8.19.25 PM

The NFD5 videos discussed in two parts – the hardware and the software. Within the hardware video they drilled the notion of a physical token-ring-esque network topology. This topology suits Plexxi well due to the fact you can pass through and terminate your fiber anywhere thanks to the passive pass through LightRail. Below is a Plexxi before and after diagram of their view.

When you have a larger Plexxi deployment the focus shifts from circles, to patching and joining multiple circles. Every single topology I thought about with a Plexxi Switch 1 made me think of the following.

I can see it now. Large datacenters as Venn diagrams. Not a bad design at all and when you couple the smarts of Plexxi Control into your network you start to get giddy.

I for one am very excited about what Plexxi is offering. Although Plexxi control is the heart of their offering, I thought it was important to look at the physical side first. The breakthroughs on merchant silicon are superb. The notion of cabling and patching inside the switch is ingenious. With data centers being distributed and fabrics being stretched like a hide across DC’s, over subscription seems to become accepted. With one cable you can move a vast amount of data between devices!

If you think this physical stuff is impressive, wait until you see Plexxi Control!

* Affinities and Plexxi will be discussed in the software blog coming shortly.

JUNOS routed interfaces

Quick one today and a memory refresh for myself. Routed L3 links between a SRX and an EX2200-C. I have currently two up links connected between the two. I want to advertise a L3 VLAN across to the SRX. I want the interconnect to be two L3 point to point link. First lets create the routed point to point links. The SRX first.

set interfaces fe-0/0/4 unit 0 family inet address 172.16.1.1/30
set interfaces fe-0/0/5 unit 0 family inet address 172.16.1.5/30

Now time for the EX.

set interfaces ge-0/1/1 unit 0 family inet address 172.16.1.6/30
set interfaces ge-0/1/0 unit 0 family inet address 172.16.1.2/30

With the links up we will create a vlan with a layer three interface on the EX switch. Put an interface with an active interface into the VLAN.

set interfaces vlan unit 15 description "ENGINEERING L3 INT"
set interfaces vlan unit 15 family inet address 10.0.15.1/24

set vlans ENGINEERING description "Engineering Department"
set vlans ENGINEERING vlan-id 15
set vlans ENGINEERING l3-interface vlan.15

set interfaces ge-0/0/10 unit 0 family ethernet-switching vlan members ENGINEERING

Juniper doesn’t have the equivalent of the Cisco auto-state ignore feature. This removes the pre-requisite of an active port in the VLAN for SVI up status. Now, with my Advanced Features licence, I can run OSPF on my EX. The following commands will advertise the required interfaces into OSPF.

set protocols ospf area 0.0.0.0 interface ge-0/1/0.0
set protocols ospf area 0.0.0.0 interface ge-0/1/1.0
set protocols ospf area 0.0.0.0 interface vlan.15

Then put the following configuration onto the SRX to advertise the required networks to the EX.

set protocols ospf area 0.0.0.0 interface fe-0/0/4.0
set protocols ospf area 0.0.0.0 interface fe-0/0/5.0
set protocols ospf area 0.0.0.0 interface vlan.0
set protocols ospf area 0.0.0.0 interface vlan.20

Now let us check the OSPF status to confirm a relationship and a L3 routed interface.

root@AU-MEL-DMZFW-01> show route 10.0.15 

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.0.15.0/24       *[OSPF/10] 00:01:28, metric 2
                      to 172.16.1.2 via fe-0/0/4.0
                    > to 172.16.1.6 via fe-0/0/5.0

root@AU-MEL-DMZFW-01> show ospf interface 
Interface           State   Area            DR ID           BDR ID          Nbrs
fe-0/0/4.0          BDR     0.0.0.0         10.0.15.1       1.1.1.1            1
fe-0/0/5.0          BDR     0.0.0.0         10.0.15.1       1.1.1.1            1

Awesome. Note that you can access the 10.0.15.0/24 network via two routed interfaces. The > denotes that it is the selected route. You have achieved two cool things in this lab. A routed interface and advertised a VLAN Layer 3 interface.

Disclaimer

I do have a disclaimer about my blog and how I operate in the blogging world with integrity. I do declare here and with other posts that this Juniper Networks EX2200-12P switch was provided to me by Francois Prowse, on behalf of Juniper Networks. I was not asked for positive, marketed, vendor drivel. I will blog honestly about the platform and my experiences and share what I find, good or bad.

i(OS)Message

Ever needed to deploy a device where multiple engineers are working in tandem. This could possibly be from different sites or someone peer reviewing configurations with you. I have. I have also not be able to access a phone or been somewhere very noisy. You have the ability to chat across vty lines on IOS. This isn’t new and has been around since before I was born but Today I will show you how you can add this tool to your skill set.

Let see what line the other engineer is using. We do have our name stating who we are but in case you forget there is out little asterisk to remind us.

4500-lab-01#sh user
    Line       User       Host(s)              Idle       Location
*  1 vty 0     aburke     idle                 00:00:00 192.168.22.50
   2 vty 1     sburns     idle                 00:00:19 192.168.22.57

  Interface      User        Mode                     Idle     Peer Address

Now I have noticed an error on interface T7/3 with an error count. I can’t call sburns nor do I have internet access. Time to let him know what I want him look to to confirm my findings.

4500-lab-01#send vty 1 
Enter message, end with CTRL/Z; abort with CTRL/C:
Have a look at the interface T7/3's error count. Do you think it is a bit high? 
Lets reset the counters and check.
^Z
Send message? [confirm]
4500-lab-01#

On sburns screen we can see what appears in the console.

4500-lab-01#

***
***
*** Message from tty2 to tty1:
***
Have a look at the interface T7/3's error count. Do you think it is a bit high? 
Lets reset the counters and check.

I have clearly and effectively communicated to my coworker the information I needed to get to him. Rather cool. It is just something you can use in your toolkit. This could also be perfect for those moments when you don’t want to deal with the person on the end of the phone. 

 

 

 

Branch Considerations with Juniper

Micro and Small branch considerations are far and wide between depending on what is the requirements are. From experiences I have found this to be a nightmare with some vendors. A set solution may not exist or the solutions that do are very expensive and over specced. This post sets out to look at requirements and thoughts of the Branch; emphasis on micro and small.

In the lab I have a EX2200 12 port compact switch with POE and a SRX110 High Memory ADSL2+ firewall. These devices funnily enough are utilised in Juniper’s design solution and considerations document. I am going to take the interesting parts from the book and discuss them here.

Branch Definition

First of all we need to define our branch size. Size, in the sense of port density and number of uses, guides us to what branch design we select. Options do change based on branch size including physical, logical, and software considerations.

Screen Shot 2013-02-24 at 5.25.32 PM

Note the clear delineation between each sized branch. You can clearly see the port capacity and thought of product placement shines through between Micro and Small. With micro’s port capacity sitting around 5-8, a single SRX110 with ADSL connection would fit the bill. Something a bit larger such as a Small would encompass an SRX firewall and EX series switch.
An SRX in either one of these deployments allows WAN termination, security services (UTM), VPN connectivity, and firewall zoning.

Topologies in the branch

Screen Shot 2013-02-24 at 3.57.25 PM

The New Network – Global reach

Screen Shot 2013-02-24 at 3.53.15 PM

SRX WAN termination options are sky high

Screen Shot 2013-02-24 at 3.52.29 PM

Two devices – a lot of potential

The small considerations

In a micro branch deployment choices need to be made regarding features and what is deployed. From an end-user perspective a micro branch should be like working at headquarters. It should be made clear that branch connectivity for end users provides an end point at a remote location at the expense of some HA/FT and redundancy technologies. From an administration point of view points such as secure connectivity, simplicity are paramount in a micro branch where HA technologies are deployed where possible.

Small branches generally contain a few more end users and considerations change slightly. An end-user will still expect the same things though with a few more people in this branch productivity loss would have a larger impact. Outage avoidance some into consideration for administration. Still, for administrators, important areas such as secure connectivity and simplicity are required. Technical staff will still be remote with local hands providing physical assistance. Design and scoping for High Availability, POE for some end devices, and considerations for High scalability must be thought about. Some small branch could have local server infrastructure which can alter logical network topologies.

Bandwidth and speed requirements

It does help these days that 1000 BASE-T to the desktop is cheaper than ever. Although 90 percent of end points do not require this to the desktop, let alone use it, uplink and total bandwidth needs to be considered.

In a micro and small branch you are limited by the speed of your WAN connection. This generally can vary from 10Mbps to 100Mbps. Both speeds are slower than the devices slowest interface. In a Micro branch end users would have minimal north south and minor east west. A small branch would need to consider north south between the two devices. Aggregation can assist here. If a local server is deployed, then correct placement must be adhered too lest bottlenecks decrease performance.

  • Micro – 100/1000 BASE-T connection, aggregation if used; LAG
  • Small – 100/1000 BASE-T connection, aggregation used; LAG

Due the collapsed notion of micro and small branches there are additional benefits that may not come to the forefront immediately. In a traditional three-tier access, aggregation, and core design, cons such as complexity, management difficulty, and maintenance increase. Due to the number of devices, it easily can become an issue to maintain budgets to ensure latest and supported hardware. Legacy devices and more management nodes increase capital and operational expenditure.

Build it and they will come

Access layer connectivity services should be considered against features offered by the platform. JUNOS offers a vast array of access-layer technologies that are standard in our industry. Underpinning all these are security and business policies.

I would recommended determining the services running then consider the following.

  • Ensure scalability and plan for growth.
  • Consider logical separation through VLANs and Zones
  • Consider POE and usage budgets where applicable
  • High Availability depends on requirements of branch/applications running
    • Consider physical HA  such as devices and power.
    • Link HA  including redundant links and aggregation.
    • Network HA that utilises software features to provide failover.

Spanning-tree

Good old spanning-tree less important due to device topology. This is due to the single or dual device topology. If redundant devices are used or HA is required, then design considerations must be made. Larger devices (EX2200-48 or EX3200) can use Virtual Chassis which eliminates the need for STP.

Routing

Due to the FIB requirements of the small and micro branch designs, the EX2200 and SRX can easily handle any routing scenarios. The SRX can terminate VPNs and interact with BGP, ISIS, OSPF, and RIP neighbours to form peers. WAN options are extremely flexible including the ability to use VRFs for logical routing security.

High level device placement

Micro branch (SRX)

  • SRX acts as collapsed core/aggregation/access
  • VPN termination to head office
  • WAN termination
  • Strong security feature-set
  • Moderate L2 switching feature-set

Small branch (SRX+EX2200)

  • Higher Availability
  • Faster access
  • POE
  • Local server infrastructure (throughput)
  • Strong L2/L3 switching feature set

Thoughts

There are some great avenues of thought on branch scenarios and many of which aren’t covered here. It does all depend on your requirements of the site. For an office branch or retail branch the information above can provide insights that may be overlooked. I suggest reading this in its entirety. Juniper’s offering of a micro or small branch is extremely cost-effective. Current prices (no one pays list) put the devices around 700 dollars each which can drop considerably without POE on the EX. You could source both for under 800 depending on contacts. Another benefit of the compact branch design is the silent and fan less operation. In a small or micro branch there isn’t always a dedicated room for networking equipment. In a lockable cabinet the device may reside but a wall or cube might become the MDF. Fan less is definitely a benefit in this case.  The rescue configuration button allows the defining of a last known working config. This is great if a central administrator makes a mistake and the local hands to fix.

Considering other offerings on the market that supposedly are affordable and scalable, Juniper offers a game-winning solution for a price that is worth considering. That being said there are a few caveats such as IPv6 ISP DHCP client and the compact model can cause heat concerns in a poor ventilated environment. I did find my SRX with the EX (both compact) stacked on top were quite warm though they ran inside Juniper’s safe operating temperate ranges.

I am lucky enough to run these at home and will eventually show my workings of my home SRX and EX environment. This reflects a small branch though my SLA’s may be different. Those with wives and girlfriends can appreciate the different SLA’s for internet we adhere too!

Additional Reading - Branch LAN Connectivity Design Guide (8020006)

Disclaimer

My Disclaimer is here regarding this device. Although my studies and recent works have leant towards a vendor, I am an independent blog who maintains a “right tool for the job” view. I do declare here and with other posts that this Juniper Networks EX2200-12P switch was provided to me by Francois Prowse, on behalf of Juniper Networks. I was not asked for positive, marketed, vendor drivel. I will blog honestly about the platform and my experiences and share what I find, good or bad.

Lateral considerations

I have been working on deploying some Nexus fabric over the last few months. The standard life cycle comes and passes and as I was sating my want to know about everything I was reading some interesting information. It is well-known the Nexus 2000 devices act as remote line cards for their older 5000 or 7000 brothers. Any layer 2 lookup or transaction is passed upwards to the master device before being forwarded on. This is a standard action you might say; I don’t think you expected this on neighbouring ports.

On neighbouring ports a normal switch such as a 3750 with a standard architecture would perform the lookup and forwarding decision on the switch and forward out another port on the device. With the distributed architecture of the Nexus family the brains of the platform reside in the 5000 or 7000. With the 2000 acting as ToR switch it must pass traffic up towards a 5000 or 7000 to perform lookup and forwarding decisions. This requires some thought. If you are placing a series of VMware hosts onto the access layer fabric some traffic considerations need to be made.

Screen Shot 2013-02-21 at 10.45.14 PM

Same switch chatter can be bad on uplinks

In the example below a VMware device may have two hosts of different clusters. A guest on cluster A may communicate to a guest on cluster B. This would mean traffic would traverse up and down a single uplink port channel. From a design consideration your East West traffic needs to be taken into consideration. The traffic that is intraDC such as vMotion between cluster hosts, Database backups, storage vMotion or DRS.

Screen Shot 2013-02-21 at 10.52.18 PM

Situational harmony

The above picture shows a bit more balance. Across two 5000′s traffic patterns can be balanced. This would be when VM load distribution is optimal. If an evacuation of a cluster host occurs or LUN abandoning is in progress such patterns need to be catered for. Sometimes you cannot always optimise but situations can arise where a sub optimal situation are for a short period of time.

Understanding the dependencies of your application architecture is paramount to a good East West traffic management. Ask good questions of your applications team. Speak to your storage team. iSCSI and FCoE users in particular. Teamwork is key here. The network is the fabric that binds us and we need to share it. Don’t be a jerk and accuse or belittle. Respect their application and they will respect your network. Just remember, vMotion/Storage vMotion/Unified vMotion respects no one and will use ALL THE BANDWIDTH!

Slices and JUNOS

In the land of JUNOS, in the fires of Mount Doom. No, I’ll resist but I felt like I had Eye of Sauron on me. On a UNIX OS a concept of slices exist. The reason these exist are due to the resilient boot architecture of JUNOS. Having dual-boot partitions you have a designated backup copy that allows device boot when something occurs.

JUNOS will slice up your internal flash to separate or partition to ensure resiliency and stability. It also means you won’t lose everything in event of an issue. By default the EX flash is divided into four slices. Two identical copies of JUNOS are stored on slice 1 and slice 2. Slice 3 contains the contents of /var with slice 4 holding /config. Due to the high level of read  and writes to /var and the potential chance of corruption, isolation works a treat to avoid entire partition corruption.

Testing some failover mechanisms I was cutting the power to the EX. It generally cannot hurt and in this particular test I was pulling the plug out. I boot back on and I was greeted by this prompt.

****************************************************************************************
** **
** WARNING: THIS DEVICE HAS BOOTED FROM THE BACKUP JUNOS IMAGE **
** ** 
** It is possible that the primary copy of JUNOS failed to boot up **
** properly, and so this device has booted from the backup copy. **
** **
** Please re-install JUNOS to recover the primary copy in case **
** it has been corrupted. **
** **
****************************************************************************************

I kind of filled my pants. Before researching what had occurred I thought I had broken my new device. Luckily this wasn’t the case. What I had done is I had corrupted the primary boot slice. I had done no damage to the secondary and it booted from this. I powered off and restarted hoping it would work and I was met by the same screen. Not to worry. I noticed there was a red light on the chassis. I checked the system alarms.

user@switch> show chassis alarms
1 alarms currently active
Alarm time Class Description
2013-02-18 09:34:21 PST Minor Host 0 Boot from backup root

Again it had booted from the backup. Time to discover what the onboard help had to offer.

After using help apropos I discovered the command that might save me.

request system snapshot media internal slice alternate

This command allows repair of the primary slice by copying the image from the backup to the primary. Then a reboot is needed to ensure your EX boots of the primary partition.

request system reboot slice alternate media internal

Now it should be happy days once you reboot. You have tested (unintentionally) your backup partition. After the reboot you can confirm JUNOS is installed correctly on each slice by issuing the following.

show system snapshot media internal slice 1
show system snapshot media internal slice 2

At the time I did honestly contemplate zeroing the device.. This restores it to a factory state and I had no issue copying my config back on. I thought though there would have to be a fix for production devices. I am glad I found it. Now with the worry gone I know I have a way to fix it and a way to fix it. If single chassis it will require a restart to clear the alarm but if running with dual RE’s or in a virtual chassis then you could shift the workload and active gateways. +1 to my neck beard skills.

Further reading : Understanding Resilient Dual-Root Partitions on Switches

Interesting limitations or silly Anthony?

As previous blogs have indicated I have my hands on a Juniper Networks EX-2200. This device has great functionality what I found great was the dual-purpose uplink ports. As pictured below these ports are linked and can take either a RJ-45 port or an SFP port. These two ports I had connected via the copper ports up linked to an SRX110. I had some Cisco SFP’s for fiber lying around and I placed them into the slots to protect them.

I boot the device up and happily perform some base configurations. This works well. I establish connection and configure the LLDP settings I wanted from the previous blog. Superb. It was then I noticed I didn’t have a connection upstream to my device. The infamous up/down scenario. I was remotely labbing from the lounge so I didn’t see my front panel which taught me to hunt more in the CLI. I checked configs, interface status and more. Then I thought more about dual-purpose. It dawned on me that maybe it is one or the other. Well it is, kind of.

A SFP module takes priority over a RJ-45. The SFP I plugged in kept me down as it was just chilling there with no fiber cable installed. Juniper has by default an internal priority. Unless you specify otherwise, the SFP takes precedence.

There is a fix and I will show you how I got it working below. With this change my device came up and it was happy days.

root@EX2200# set interfaces ge-0/1/0 media-type copper
root@EX2200# set interfaces ge-0/1/1 media-type copper

So be aware that there are some hardware limitations. The name, dual-purpose port, should have given it away but I have to admit I was excited to get this puppy in the lab. In doing so I may have not read all the manual. RTFM? Yeah, I got bitten. This switch has made a great addition to my lab and expect some cool JUNOS stuff in the future. Awesome features thus far. It is like a mini 3560 without the price-tag.

Disclaimer I do have a disclaimer about my blog and how I operate in the blogging world with integrity. I do declare here and with other posts that this Juniper Networks EX2200-12P switch was provided to me by Francois Prowse, on behalf of Juniper Networks. I was not asked for positive, marketed, vendor drivel. I will blog honestly about the platform and my experiences and share what I find, good or bad.

LLDP in the lab

LLDP is the non proprietary version of CDP. This discovery protocol has applications that can make an administrators life much easier. Now with two physical devices I am going to implement LLDP on JUNOS with the EX-2200 and SRX110. First of all we need to note that the SRX hasvLLDP off by default. The EX has it enabled by default.

Enabling LLDP is not a hard but some considerations have been made. I personally would not like to enable it by default globally on a firewall. I don’t mind this on a switch that is internal to your enterprise. If it was a DMZ firewall or switch you should control who sees what. To allow it per interface you just denote what interface in the command.

root@EX2200-C> show configuration protocols lldp                                            
interface all;

This default on the switch is okay as my switch is an internal device. Time to enable LLDP on the interface fe-0/0/7 of the SRX.

root@SRX110# set protocols lldp interface fe-0/0/7.0

Now both of our devices have active LLDP, it is time to check out what our SRX and EX sees.

root@SRX110> show lldp neighbors                                                            
Local Interface    Parent Interface    Chassis Id          Port info          System Name   
fe-0/0/7.0         -                   08:81:f4:a9:14:80   ge-0/1/0.0         EX2200-C

Now from the other side.

root@EX2200-C> show lldp neighbors                                                          
Local Interface    Parent Interface    Chassis Id          Port info          System Name   
ge-0/1/0.0         -                   b0:a8:6e:66:e2:40   fe-0/0/7.0         SRX110

There we go. Easily configured and extremely helpful. I find LLDP useful when applied carefully. If you work in a secure environment I would suggest enabling it on a need to know basis!

Pins in the fabric

The Nexus series of data center switches by Cisco allow for an extended fabric configuration. By utilising the notion of remote line cards, an engineer can deploy Nexus 2200 series switches as Top of Rack. These top of rack switches allow for data center access for servers. Nexus 5000 series (or 7000) for that matter act as the master. These are what the Nexus 2000 series pin back to.

With the mindset of remote line card now in your head let’s get on the job about pinning one. This exercise will show you how to pin a Nexus 2248TP to a Nexus 5548UP switch. The term FEX is used and is short for Fabric Extenders, referring to the Nexus 2200 series.

Screen Shot 2013-02-16 at 2.40.35 PM

The above diagram shows you how we are going to pin our access layer devices to each switch. Below we will pin our device with the following configuration. I have two 10Gb Twinax cable links connected from Nexus 2248TP up to the 5548UP. I am going to single home each FEX to an upstream Nexus 5548. Aligning even-numbered FEX and odd-numbered FEX to their own upstream 5548 allows for rack redundancy in the situation of a failure. Servers has a choice to be connected to both FEX’s allowing diverse paths. The above deployment would suit three Racks worth of switches for fabric redundancy. You can dual home your FEX devices and Tony Mattke goes in depth about design considerations.

Ensure your Nexus 5000 device is powered on and the Nexus 2200 device is not before continuing.

LAB-N5548-1(config)# int e1/5-6
LAB-N5548-1(config-if-range)# channel-group 101
LAB-N5548-1(config-if-range)# int po101
LAB-N5548-1(config-if)# switchport mode fex
LAB-N5548-1(config-if)# fex ass 101
LAB-N5548-1(config-if)# exit

The commands are easy enough. Add ethernet 1/5 and 1/6 to channel-group 101. Under the interface of port-channel 101 the switchport mode is not access or trunk but something unique to the NX-OS. Fex. Fex ports tell NXOS to expect a remote line card on this port. Then associate and identify that FEX number 101. Ahh, I have a thing with consistency in my deployments. Port group 101, Fex 101…. You get the idea! :) So let us confirm what is happening now.

LAB-N5548-1# sh fex
  FEX         FEX           FEX                       FEX
Number    Description      State            Model            Serial
------------------------------------------------------------------------
---       --------             Connected     N2K-C2224TP-1GE   SSI163504DR

Okay so a downstream device is connected. This is good. The serial number matches up which is handy. Let us check the detailed output.

LAB-N5548-1# sh fex det
FEX: 101 Description: FEX0101   state: Image Download
  FEX version: 4.2(1)N2(1) [Switch version: 5.2(1)N1(1)]
  FEX Interim version: 4.2(1)N2(0.51)
  Switch Interim version: 5.2(1)N1(1)
  Module Sw Gen: 12594  [Switch Sw Gen: 21]
  post level: complete
 pinning-mode: static    Max-links: 1
  Fabric port for control traffic: Eth1/5
  FCoE Admin: false
  FCoE Oper: true
  FCoE FEX AA Configured: false
  Fabric interface state:
    Po101 - Interface Up. State: Active
    Eth1/5 - Interface Up. State: Active
    Eth1/6 - Interface Up. State: Active
Logs:
02/04/2009 02:58:28.251005: Module register received
02/04/2009 02:58:28.251699: Image Version Mismatch
02/04/2009 02:58:28.252053: Registration response sent
02/04/2009 02:58:28.252224: Requesting satellite to download image

Look at that. The FEX is downloading and installing a newer software from the Nexus 5000. I didn’t expect this to be running its own software by itself. Due to the nature of the Nexus 2000 requiring an upstream 5000 I naturally through it would be “boot from SAN” styled power on. Note that the 4.2 code is moving on up the parents 5.2. Upgrades! Time to grab a coffee whilst I wait.

LAB-N5548-1# sh fex det
FEX: 101 Description: THO-EST-FEX-P2-101 state: Online
FEX version: 5.2(1)N1(1) [Switch version: 5.2(1)N1(1)]
FEX Interim version: 5.2(1)N1(1)
Switch Interim version: 5.2(1)N1(1)
Extender Serial: SSI163504DR
Extender Model: N2K-C2224TP-1GE, Part No: 73-13373-01
Card Id: 132, Mac Addr: 88:75:56:c0:68:02, Num Macs: 64
Module Sw Gen: 12594 [Switch Sw Gen: 21]
post level: complete
pinning-mode: static Max-links: 1
Fabric port for control traffic: Eth1/5
FCoE Admin: false
FCoE Oper: true
FCoE FEX AA Configured: false
Fabric interface state:
Po101 - Interface Up. State: Active
Eth1/5 - Interface Up. State: Active
Eth1/6 - Interface Up. State: Active
Fex Port State Fabric Port
Eth101/1/1 Down Po101
Eth101/1/2 Down Po101
Eth101/1/3 Down Po101
Eth101/1/4 Down Po101
Eth101/1/5 Down Po101
<snip>
Logs:
02/04/2009 02:58:28.251005: Module register received
02/04/2009 02:58:28.251699: Image Version Mismatch
02/04/2009 02:58:28.252053: Registration response sent
02/04/2009 02:58:28.252224: Requesting satellite to download image
02/04/2009 03:07:32.676640: Image preload successful.
02/04/2009 03:07:33.816624: Deleting route to FEX
02/04/2009 03:07:33.825731: Module disconnected
02/04/2009 03:07:33.826383: Module Offline
02/04/2009 03:07:33.846159: Deleting route to FEX
02/04/2009 03:07:33.853588: Module disconnected
02/04/2009 03:07:33.854835: Offlining Module
02/04/2009 03:08:28.252593: Module timed out
02/04/2009 03:08:51.563834: Module register received
02/04/2009 03:08:51.565068: Registration response sent
02/04/2009 03:08:51.782832: Module Online Sequence
02/04/2009 03:08:56.416394: Module Online

LAB-N5548-1#

Note the state has change from Image Download to Online. This is noted also by the FEX log at the bottom. Looking also at the output the FEX has added interfaces with a slot aligned with the FEX number. I have cut some out for brevity but Eth 101/1/1-24 now exist! You can pin-up to 12 FEX’s to a Nexus 5000 series. You can appreciate the flexibility this gives opposed to chassis switches. It is important to take into consideration failure domains and what affects this on uplink bandwidth. This allow for great expansion, flexibility with different access layer mediums, and ease of management.

 

My other ride is an EX

Today was a good day. I had a new arrival into the family. The Juniper Networks EX-2200 12-C PoE+. In addition to my SRX110-H-VA Firewall I now have a fully fledged JUNOS switch with all the bells a whistles. Juniper place the fanless L2/L3 switch in the sights of those with (micro) branch, retail, and workgroup deployments.

It comes with 12 x 10/100/1000 access ports with PoE+ support. There is also two, shared gig copper or SFP uplinks. The PoE+ support allows for voice handsets, cctv camera, access points, and other PoE compatible devices. The feature set of JUNOS allows L2/L3 functions on the base licence.

Now this beast is a fierce switch. It can provide extremely flexible options in regards to deployment scenarios. I am eager to explore what I can actually achieve with this device in conjunction with the SRX. I will also explore the technologies of the advanced switching features that Juniper offers; in turn providing others with the insight into this platform.

My topology will be fleshed out as I go but physically this is what I am doing at this stage. Keep in mind that I have only just unboxed this device and just plugged it into my Macbook Pro.

photo

So above you can see my SRX and the EX switches. Simple interconnect, an uplink into my ISP modem/router and from my macbook two uplinks into the EX. I am eager to see what this platform can do as the specifications sheet is out of control! Join me over the coming weeks as I dig and find out more.

Disclaimer - I do have a disclaimer about my blog and how I operate in the blogging world with integrity. I do declare here and with other posts that this Juniper Networks EX2200-12P switch was provided to me by Francois Prowse, on behalf of Juniper Networks. I was not asked for positive, marketed, vendor drivel. I will blog honestly about the platform and my experiences and share what I find, good or bad.