October 01, 2014

Packet Pushers Blog/Podcast

Traveling Light – 15 Things in an Engineer’s Bag (including the bag)

My day job involves traveling around northern Europe and occasionally further afield. I often get little notice of where I’m going, or how long I’m going for. This makes for a lot of trudging along train platforms and across departure lounges. Hauling too much stuff around is guaranteed to ruin my day. Traveling light becomes a necessity, […]

Author information

Glen Kemp

Professional Services Consultant at Fortinet, Inc

Professional Services Consultant. Designing & deploying “keep the bad guys out” technologies. Delivering elephants and not hunting unicorns.

Please free to add me on , follow me on Twitter or check out my other blogs on Fortinet Blog, sslboy.net and SearchNetworking.

The post Traveling Light – 15 Things in an Engineer’s Bag (including the bag) appeared first on Packet Pushers Podcast and was written by Glen Kemp.

by Glen Kemp at October 01, 2014 02:25 PM

Networking Now (Juniper Blog)

Black Hat Amsterdam 2014

blackhat.pngLooking for an excuse to visit the charming city of Amsterdam? Then look no further - your excuse is Black Hat Europe 2014.


by Mora Gozani at October 01, 2014 02:04 PM

Cisco IOS Hints and Tricks

Tech Talks: MPLS Traffic Engineering Basics

After covering the basics of MPLS, the discussion I had with Seamus Gilchrist turned to the basics of MPLS Traffic Engineering.

The video of that discussion is available online on the ipSpace.net Tech Talks web page.

by Ivan Pepelnjak (noreply@blogger.com) at October 01, 2014 01:49 PM

PacketLife.net Blog

Cumulus Linux: First Impressions

Typically, when you buy a network router or switch, it comes bundled with some version of the manufacturer's operating system. Cisco routers come with IOS (or some derivative), Juniper routers come with Junos, and so on. But with the recent proliferation of merchant silicon, there seem to be fewer and fewer differences between competing devices under the hood. For instance, the Juniper QFX3500, the Cisco Nexus 3064, and the Arista 7050S are all powered by an off-the-shelf Broadcom chipset rather than custom ASICs developed in-house. Among such similar hardware platforms, the remaining differentiator is the software.

One company looking to benefit from this trend is Cumulus Networks. Cumulus does not produce or sell hardware, only a network operating system: Cumulus Linux. The Debian-based OS is built to run on whitebox hardware you can purchase from a number of partner Original Device Manufacturers (ODMs). (Their hardware compatability list includes a number of 10GE and 40GE switch models from different vendors.)

Cumulus Linux is, as the name implies, Linux. There is no "front end" CLI as on, for example, Arista platforms. Upon login you are presented with a Bash terminal and all the standard Linux utilities (plus a number of not-so-standard bits). Like any OS, Cumulus handles interactions with the underlying hardware and among processes.


Continue reading · 2 comments

by Jeremy Stretch at October 01, 2014 02:05 AM

XKCD Comics

September 30, 2014

Honest Networker
Networking Now (Juniper Blog)

The US Department of Defense Certifies more Juniper Networks EX Switches

The Department of Defense (DoD) Unified Capabilities Approved Product List (UC APL) may be the most challenging certification in networking. 

by bshelton at September 30, 2014 02:41 PM

Packet Pushers Blog/Podcast

What The Heck Is SPDY?

A10‘s presentation at NFD8 seemed to generate a bit of interest (dare I say excitement) and many a question around the SPDY (pronounced ‘speedy’) protocol. I promised Lindsey Hill (@northlandboy) on Twitter that I’d write a blog post about it and here it is. It took me rather longer to write than I thought and […]

Author information

Steven Iveson

Steven Iveson

Steven Iveson, the last of four children of the seventies, was born in London and has never been too far from a shooting, bombing or riot. He's now grateful to live in a small town in East Yorkshire in the north east of England with his wife Sam and their four children.

He's worked in the IT industry for over 15 years in a variety of roles, predominantly in data centre environments. Working with switches and routers pretty much from the start he now also has a thirst for application delivery, SDN, virtualisation and related products and technologies. He's published a number of F5 Networks related books and is a regular contributor at DevCentral.

The post What The Heck Is SPDY? appeared first on Packet Pushers Podcast and was written by Steven Iveson.

by Steven Iveson at September 30, 2014 01:56 PM

Cisco IOS Hints and Tricks

Replacing a Central Firewall

During one of my ExpertExpress engagements I got an interesting question: “could we replace a pair of central firewalls with iptables on the Linux server?

Short answer: Maybe (depending on your security policy), but I’d still love to see some baseline scrubbing before the traffic hits the server – after all, if someone pwns your server, he’ll quickly turn off iptables.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at September 30, 2014 01:39 PM

Potaroo blog

What's so special about 512?

The 12th August 2014 was widely reported as a day when the Internet collapsed. Despite the sensational media reports the following day, the condition was not fatal, and perhaps it could be more reasonably reported that some parts of the Internet were having a bad hair day. What was happening was that the Internet’s growth had just exceeded the default configuration limits of certain models of network switching equipment. In this article I'll look at how the growth of the routing table and the scaling in the size of transmission circuits impacts on the internal components of network routing equipment.

September 30, 2014 12:30 PM

The Networking Nerd

The Atomic Weight of Policy


The OpenDaylight project put out a new element this week with their Helium release.  The second release is usually the most important, as it shows that you have a real project on your hands and not just a bunch of people coding in the back room to no avail.  Not that something like that was going to happen to ODL.  The group of people involved in the project have the force of will to change the networking world.

Helium is already having an effect on the market.  Brocade announced their Vyatta Controller last week, which is based on Helium code.  Here’s a handy video as well.  The other thing that Helium has brought forth is the ongoing debate about network policy.  And I think that little gem is going to have more weight in the long run than anything else.

The Best Policy

Helium contains group-based policies for making groups of network objects talk to each other.  It’s a crucial step to bring ODL from an engineering hobby project to a full-fledged product that can be installed by someone that isn’t a code wizard.  That’s because most of the rest of the world, including IT people, don’t speak in specific terms with devices.  They have an idea of what needs to be done and they rely on the devices to implement that idea.

Think about a firewall.  When is the last time you wrote a firewall rule by hand? Unless you are a CLI masochist, you use the GUI to craft a policy that says something like “prevent DNS queries from any device that isn’t a DNS server (referenced by this DNS Server object list)”.  We create those kinds of policies because we can’t account for every new server appearing on the network that wants to make a DNS query.  We block the ones that don’t need to be doing it, and we modify the DNS Server object list to add new servers when needed.

Yet, in networking we’re still playing with access lists and VLAN databases.  We must manually propagate this information throughout the network when updates occur.  Because no one relies on VTP to add and prune information in the network.  The tools we’ve been using to do this work are archaic and failure-prone at best.

Staying Neutral

The inclusion of policy components of Helium will go a long way to paving the road for more of the same in future releases.  Of course, there is already talk about Cisco’s OpFlex and how it didn’t make the cut for Helium despite being one of the most dense pieces of code proposed for ODL.  It’s good that Cisco and ODL both realized that putting out code that wasn’t ready was only going to hurt in the long run.  When you’ve had seven or eight major releases, you can lay an egg with a poorly implemented feature and it won’t be the end of the world.  But if you put out a stinker in the second release, you may not make it to the third.

But this isn’t about OpFlex.  Or Congress. Or any other policy language that might be proposed for ODL in the future.  It’s about making sure that ODL is a policy-driven controller infrastructure.  Markus Nispel of Extreme talked about SDN at Wireless Field Day 7.  In that presentation, he said that he thinks the industry will standardize on ODL as the northbound interface in the network.  For those not familiar, the northbound interface is the one that is user-facing.  We interact with the northbound controller interface while the southbound controller interface programs the devices.

ODL is making sure the southbound interface is OpenFlow.  What they need to do now is ensure the northbound interface can speak policy to the users configuring it.  We’ve all heard the rhetoric of “network engineers need to learn coding” or “non-programmers will be out of a job soon”.  But the harsher reality is that while network programmers are going to be very busy people on the backend, the day-to-day operations of the network will be handled by different teams.  Those teams don’t speak IOS, Junos, or OpenFlow.  They think in policy-based thoughts.

Ops teams don’t want to know how something is going to work when implemented.  They don’t want to spend hours troubleshooting why a VLAN didn’t populate only to find they typoed the number.  They want to plug information into a policy and let the controller do the rest.  That’s what Helium has started and what ODL represents.  An interface into the network for mortal Ops teams.  A way to make that work for everyone, whether it be an OpFlex interface into Cisco APIC programming ACI or a Congress interface to an NSX layer.  If you are a the standard controller, you need to talk to everyone no matter their language.

Tom’s Take

ODL is going to be the controller in SDN.  There is too much behind it to let it fail.  Vendors are going to adopt it as their base standard for SDN.  They may add bells and whistles but it will still be ODL underneath.  That means that ODL needs to set the standard for network interaction.  And that means policy.  Network engineers complain about fragility in networking and how it’s hard to do and in the very same breath say they don’t want the CLI to go away.  What they need to say is that policy gives everyone the flexibility to create robust, fault-tolerant configurations with a minimum of effort while still allowing for other interface options, like CLI and API.  If you are the standard, you can’t play favorites.  Policy is going to be the future of networking interfaces.  If you don’t believe that, you’ll find yourself quickly crushed under the weight of reality.

by Tom Hollingsworth at September 30, 2014 03:10 AM

September 29, 2014

Packet Pushers Blog/Podcast

Show 206 – Brocade’s OpenDaylight-Based Vyatta Controller – Sponsored

If you watch the software defined networking space, you might have noticed that Brocade has been quietly hiring a sharp group of actual (not self-proclaimed) thought leaders and developers. The question has been, "To what end? What's Brocade going to do with all of these capable folks?" Today, we can answer that question. Brocade has built an SDN controller based on OpenDaylight. This makes sense, as folks like Tom Nadeau (featured on the show today), David Meyer, and Colin Dixon are all heavily involved with ODL in various capacities as well as being a part of the Brocade family. Okay. So...yet another SDN controller entrant to a suddenly crowded market. Why should anyone care about the Brocade Vyatta Controller? The big thing to know about this product is that it is truly a child of open source. As Lisa Caywood (also featured on the show today) points out, "Vyatta means 'open' in Sanskrit," and thus Brocade is leveraging their Vyatta brand to reinforce the notion of openness in this new controller product. If you think of the ODL project as an open source foundation on which other companies can base their own controller on, then you get the idea of what Brocade has done here. The Brocade Vyatta controller is ODL at the base, meaning that SDN apps written for ODL will work on the Brocade controller. That gives businesses some flexibility - a move towards a genuinely open ecosystem of SDN apps that will be multi-vendor. Apps are what SDN is going to be all about going forward. Apps really, really matter, since businesses buy the functionality technology brings -- not technology for its own sake. The other side of the equation here is support. Many businesses don't want to deal with open source software platforms unless they can get a support wrapper built around them. Red Hat has made a business model out of this. Brocade is doing much the same thing here. Take the ODL controller, polish it up (contributing much of that "polish" back to the ODL project, by the way), add some interesting extensions that improve platform functionality without breaking ODL compatibility, and wrap it in a safety bubble of end-to-end SDN architecture support, even if your network switches aren't from Brocade. The point being, a business can move ahead with SDN using a controller based on genuinely open standards and still get help from experts when they need it. Give the show a listen today, and you'll hear... What the Brocade Vyatta Controller is. Reasons to care, including specific use-cases & problems the platform addresses. A high-level overview of how it works. Links Brocade Vyatta Controller landing page Brocade Vyatta Controller Data Sheet Brocade Community on SDN & NFV Curt Beckmann on Open vs. Proprietary Lisa Caywood on the Brocade Approach to SDN

by Packet Pushers Podcast at September 29, 2014 02:25 PM

Cisco IOS Hints and Tricks

Building a Small Cloud with UCS Mini

During the last round of polishing of my Designing Infrastructure for Private Clouds Interop New York session (also available in webinar format) I wondered whether one could use the recently-launched UCS Mini to build my sample private cloud.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at September 29, 2014 01:26 PM

Packet Pushers Blog/Podcast

The Seven Layer Model is Dead

Whether we have the funeral in New Orleans style (with a lot of brass and, well, other stuff), or in the more somber style we’re all so accustomed to– or even perhaps dance down the road singing, “ding dong, the model’s dead” — it’s time to pack the seven layer model into a virtual coffin […]

Author information

Russ White

Russ White
Principle Engineer at Ericsson

Russ White is a Network Architect who's scribbled a basket of books, penned a plethora of patents, written a raft of RFCs, taught a trencher of classes, and done a lot of other stuff you either already know about, or don't really care about. You want numbers and letters? Okay: CCIE 2635, CCDE 2007:001, CCAr, BSIT, MSIT (Network Design & Architecture, Capella University), MACM (Biblical Literature, Shepherds Theological Seminary). Russ is a Principal Engineer in the IPOS Team at Ericsson, where he works on lots of different stuff, serves on the Routing Area Directorate at the IETF, and is a cochair of the Internet Society Advisory Council. Russ will be speaking in November at the Ericsson Technology Day. he recently published The Art of Network Architecture, is currently working on a new book in the area of network complexity with Addison Wesley, a book on innovation from within a Christian worldview, and he blogs at ntwrk.guru on network engineering.

The post The Seven Layer Model is Dead appeared first on Packet Pushers Podcast and was written by Russ White.

by Russ White at September 29, 2014 01:00 AM

XKCD Comics

September 28, 2014

Cisco IOS Hints and Tricks

It’s the Application Development, Stupid

I love reading blog posts on Plexxi blog (you SHOULD add them to your RSS reader) and the “It’s the Application, Stupid” series from Mat Matthews is no exception. What pleasantly surprised me was that a large enterprise came to the same conclusions I’m preaching for the last few years.

by Ivan Pepelnjak (noreply@blogger.com) at September 28, 2014 04:12 PM

September 27, 2014


Shellshock: a bug bigger than Heartbleed?

Recently, the Red Hat team have found a critical remotely exploitable vulnerability in the Bash (aka the GNU Bourne Again Shell), that allow a remote attacker to inject arbitrary commands. GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash […]

by Fabio Semperboni at September 27, 2014 09:52 PM

CCIE Journey

Sometimes The Path You Are On Needs To Be Altered

“We keep moving forward, opening new doors, and doing new things, because we’re curious and curiosity keeps leading us down new paths.” -Walt Disney

Well, I have been prepping for the CCNA Voice the last four weeks, and was feeling pretty good about how far I have come. Now though, that plan is going to be put on a hold for a little bit. Due to big things coming down the pipe at work, I am going to have to start some Nexus, and data center training. That is going to have to be my path for the foreseeable future which I am very excited about. I started training and preparing for the data center written late last year, only to quit because I felt that without real day-to-day, hands-on experience, I would only become a paper tech. But now, the real hands-on, day-to-day work is coming, whether I am prepared, or not. I would rather be prepared. :) So this will be my new path going forward, from here on out. I will continue on with all my INE data center material, and hopefully get the written done well before summer goes full tilt here in Western New York.

To all my friends out there, I have one word for you…. “Squirrel!”

by CCIE Journey at September 27, 2014 04:39 PM

Cisco IOS Hints and Tricks

TCP Is a Stream Protocol

I hope you know TCP provides a reliable stream service not reliable packet delivery, but you might not have realized all the implications – I found an old post by Robert Graham explaining how things really work and how you can use them to bypass quick-and-dirty IDS that rely on signatures instead of doing proper protocol decodes.

by Ivan Pepelnjak (noreply@blogger.com) at September 27, 2014 08:15 AM

September 26, 2014

Cisco IOS Hints and Tricks

Schprokits with Jeremy Schulman on Software Gone Wild

Jeremy Schulman was the driving force behind the Puppet agent that Juniper implemented on some Junos switches (one of the first fully supported Puppet-on-a-switch implementations). In the meantime, he quit Juniper and started his own company focused on a network automation product – more than enough reasons to chat with him on Software Gone Wild.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at September 26, 2014 08:19 AM

XKCD Comics

September 25, 2014

Security to the Core | Arbor Networks Security

FCC advised on Remediation of Server-based DDoS Attacks

Yesterday, the Communications Security, Reliability and Interoperability Council (CSRIC), a federal advisory committee to the Federal Communications Commission (FCC), submitted its final report on Remediation of Server-based DDoS Attacks.

The CSRIC’s Working Group 5 was tasked with developing recommendations for communications providers to enable them to mitigate the impact of high volume DDoS attacks launched from large data center and hosting environments.

The final report includes a comprehensive look at the DDoS threat landscape, covering everything from the massive size of today’s attacks, to the potential for collateral damage. The report describes how DDoS attacks are becoming increasingly complex, how they are being used as a diversion “to distract security resources while other attacks are being attempted, e.g., fraudulent transactions.” The report also discusses how botnet architectures are becoming more sophisticated and difficult to trace.

Given this complex and challenging threat landscape, we were grateful for the opportunity to contribute. The CSRIC has adapted Arbor Networks best practices for DDoS incident response as the Six Phases for DDoS Attack Preparation & Response.


Roland Dobbins, senior analyst with Arbor’s Security Engineering & Response Team (ASERT), served as the Internet sub-group chairman of CSRIC IV WG5 – Server-Based DDoS Attacks. 

Roland has nearly 30 years of operational experience in the service provider and large enterprise arenas. His experience includes designing, deploying, operating, securing, maintaining, troubleshooting and defending many of the highest-visibility networks in the world. He is a recognized industry leader in the fields of operational security and network telemetry with extensive background in security product/feature innovation, devising operational security requirements for network infrastructure devices and protocol design. His focus is on extending the availability, scalability and security of the network infrastructure and the applications/services it enables, with an emphasis on flexible and resilient global service delivery capabilities.

by Arbor Networks at September 25, 2014 05:16 PM

Packet Pushers Blog/Podcast

PQ Show 33 – Intel Rack Scale Architecture – Real or Impractical ?

At the IDF 2014 conference, Intel made a big song and dance about their Rack Scale Architecture which removes the need for "top of rack" networking and changes the nature of servers in a big way. My initial impression is that this has limited application in the enterprise or cloud providers but might be useful for appliance makers in storage or as a replacement for proprietary blade servers. Scott Lowe and I debated the finer points of the technology at the event and today we discuss it again with the benefit of hindsight.   Show Notes This is the presentation that I referenced in the podcast. Rack Scale Architecture – Platform and Management SF14_DATS008_104f Redfish Specification | a Modern Datacenter Manageability Specification Proposal

by Packet Pushers Podcast at September 25, 2014 05:00 PM

Cisco IOS Hints and Tricks

Quick Guide to my Interop New York Sessions

I’m running or participating in five workshops or sessions during next week’s Interop New York. Three of them build on each other, so you might want to attend all of them in sequence:

Designing Infrastructure for Private Clouds starts with requirements gathering phase and focuses on physical infrastructure design decisions covering compute, storage, physical and virtual networking, and network services. If you plan to build a private (or a reasonable small public) cloud, start here.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at September 25, 2014 08:34 AM

September 24, 2014

My Etherealmind

Musing: Cisco Buys Tail-F and Disrupts Competitor Product Development

It has been a while since Cisco acquired Tail-F but no one seems to have noticed how this acquisition impacts Cisco's competitors by upsetting the software development plans.

The post Musing: Cisco Buys Tail-F and Disrupts Competitor Product Development appeared first on EtherealMind.

by Greg Ferro at September 24, 2014 07:44 PM

Peter's CCIE Musings and Rants

Retrieve MOH files


  1. Connect (using SSH) to the CUCM node that has the MoH audio server role or the publisher node.
  2. To list the music files use the command: file list activelog mohprep.
  3. You will see a list of MoH files in various formats (ulaw, alaw, g729, etc.). Identify the file(s) you would like to download.
  4. Retrieve the file using the command: file get activelog mohprep/
    1. You can use specific filename: e.g. mohprep/mymohfile.ulaw.wav
    2. You can use a mask: e.g. mohprep/*.ulaw.wav

by peter_revill (noreply@blogger.com) at September 24, 2014 10:34 AM

How to navigate around the CUCM Database using run sql, show tech systables and more tips

Hi Guys

so you may already know about the run sql command, but when it comes to finding what you need... sometimes it's tricky to  work out the structure of the table, or even what table you might want to look at.

Here is how to see a list of tables:

admin:show tech systables
------------------------Show tech system tables-----------------------


Here is how to see all the entries for that table:

admin:show tech table srst
------------------------ Show tech table -------------------

Output is in /cm/trace/dbl/srst_table1411574818655.out
Use "file view activelog /cm/trace/dbl/srst_table1411574818655.out" command to see output

admin:file view activelog /cm/trace/dbl/srst_table1411574818655.out
2014-09-24 12:07:21,271 INFO  [ClassExecutionThread] cli.CliSettings - VMware = false

pkid                                 name                ipaddr1       port1 ipaddr2 port2 ipaddr3 port3 usermodifiable tksrstoption certificate issecure certificateproviderport sipipaddr1 sipipaddr2 sipipaddr3 sipport1 sipport2 sipport3 resettoggle tkreset
==================================== =================== ============= ===== ======= ===== ======= ===== ============== ============ =========== ======== ======================= ========== ========== ========== ======== ======== ======== =========== =======
c80cafe0-af65-43d6-a1f1-435ad998bd26 Use Default Gateway               2000          2000          2000  f              2                        f        2445                                                     5060     5060     5060     f           2

So now I know what the columns are, I can run sql queries:

admin:run sql select pkid, ipaddr1, name from SRST
pkid                                 ipaddr1       name
==================================== ============= ===================
c80cafe0-af65-43d6-a1f1-435ad998bd26               Use Default Gateway
cd241e11-4a58-4d3d-9661-f06c912a18a3               Disable
3bc40e86-e06f-4e4a-9679-a6ef5d7f6d05 MIKE_SRST
65cd53b4-3c1a-413f-acc9-c92f0eff9a52  DAVE_SRST
f5ad268e-7a37-8d6e-9783-f415ca3c9629 PETE SRST

by peter_revill (noreply@blogger.com) at September 24, 2014 10:10 AM

Full shout out to ucguerrilla for this (How to get a list of fast dials and speed dials using SQL)

Hi Guys!

First of all full props to ucguerrilla for what i am about to post, His website: http://www.ucguerrilla.com

Is AWESOME for UC Engineers and has some great great stuff

Anyway he has two entries about extracting fast dials and speed dials from CUCM using sql queries that I found very useful, here is the sql query to extract fast dials:

select uid.userid,  fd.personalfastdialindex, fd.phonenumber as fastdialdest,        pab.firstname as AddressBookFirstName, pab.lastname as AddressBookLastName from personalphonebook as fd inner join enduser as uid on fd.fkenduser=uid.pkid      inner join typepersonalphonenumber as tppn on fd.tkpersonalphonenumber=tppn.enum      left outer join personaladdressbook as pab on fd.fkpersonaladdressbook=pab.pkid order by uid.userid, fd.personalfastdialindex

Here is his relevant blog posts:



by peter_revill (noreply@blogger.com) at September 24, 2014 09:31 AM

Cisco IOS Hints and Tricks

Network Programmability 101: The Problem

In the first part of the Network Programmability webinar Matt Oswalt described some of the major challenges most networks are facing today:

  • Why is everyone claiming that the network is so slow to change?
  • Is that really the case? Why?
  • Why is the manual configuration culture so widespread in networking?
  • How does the holistic thinking in the design phase dissolve into the box mentality of CLI commands?
  • How does the box mentality limit the scalability of network deployments?

by Ivan Pepelnjak (noreply@blogger.com) at September 24, 2014 08:57 AM

XKCD Comics

September 23, 2014

Networking Now (Juniper Blog)

Juniper Firefly Perimeter 12.1x47 D10.2 Release

Several weeks ago, Juniper Networks officially released an updated version of Firefly Perimeter. The version is 12.1x47 D10.2. We provided a lot of new and amazing updates in to the product. I wanted to take this opportunity to provide you with an understanding of what is currently available in this code. 



  • Unified Threat Management ( UTM ) ( VMware and KVM ) 
  • Intrusion Prevention System ( IPS ) ( VMware and KVM ) 
  • vSphere 5.5 support ( VMware ) 
  • Transparent Mode ( VMware and KVM ) 
  • Transparent Mode Chassis Cluster Support  ( VMware and KVM ) 
  • Chassis Cluster Support for VirtIO driver ( KVM only )
  • Deterministic NAT ( VMware and KVM ) 
  • Port Block Allocation ( PBA ) NAT ( VMware and KVM ) 
A lot of these new features are self explanatory but I think that UTM needs some extra special explaining.
UTM is an industry term identifying a traditional firewall with security functions.
In the Firefly Perimeter realm UTM means
  • Web Filtering ( included Enhanced Web Filter )
  • Anti-virus
  • Anti-spam
  • Content Filtering
Anti-virus helps you with blocking malware, trojans, and viruses.
Anti-spam helps you with… wait for it… spam. That is right, the anti-spam feature in UTM, blocks spam.
Content filtering blocks or permits traffic based on MIME type, file extension, protocol command, and embedded object type. For instance, content filtering would block files that end in .exe or zip files. 
Web filtering and enhanced web filtering allow to block or permit access to particular websites. For instance, if you wanted to block access to Facebook, you could use this capability ( past experience has proven that this does not make for happy employees but I think you get the idea ).
Now I have just given you a snippet of what these enhanced security features are capable of but I think it is important to understand what this means for you and your virtual environment. You now have the capability of implementing these security features in a virtual machine that is already capable of firewall protection, NAT, VPN, etc. and you still manage this from a single interface ( Junos Space ). Having the ability to manage everything in one virtual machine saves frustration, saves you time, improves your security capabilities through easier management. It is all around an amazing opportunity in your hand. 
If you are interested in evaluating Firefly Perimeter 12.1x47, feel free to download here
If you are interested in Firefly Perimeter documentation, click here

by banksek at September 23, 2014 09:31 PM

The Networking Nerd

SDN Use Case: Content Filtering

K-12 schools face unique challenges with their IT infrastructure.  Their user base needs access to a large amount of information while at the same time facing restrictions.  While it does sound like some corporate network policies, the restrictions in the education environment are legal in nature.  Schools must find new ways to provide the assurance of restricting content without destroying their network in the process.  Which lead me to ask: Can SDN Help?

Online Protection

The government E-Rate program gives schools money each year under Priority 1 funding for Internet access.  Indeed, the whole point of the E-Rate program is to get schools connected to the Internet.  But we all know the Internet comes with a bevy of distractions. Many of those distractions are graphic in nature and must be eliminated in a school.  Because it’s the law.

The Children’s Internet Protection Act (CIPA) mandates that schools and libraries receiving E-Rate funding for high speed broadband Internet connections must filter those connections to remove questionable content.  Otherwise they risk losing funding for all E-Rate services.  That makes content filters very popular devices in schools, even if they aren’t funded by E-Rate (which they aren’t).

Content filters also cause network design issues.  In the old days, we had to put the content filter servers on a hub along with the outbound Internet router in order to insure they could see all the traffic and block the bad bits.  That became increasing difficult as network switch speeds increased.  Forcing hundreds of megabits through a 10Mbit hub was counterproductive.  Moving to switchport mirroring did alleviate the speed issues, but still caused network design problems.  Now, content filters can run on firewalls and bastion host devices or are enabled via proxy settings in the cloud.  But we all know that running too many services on a firewall causes performance issues.  Or leads to buying a larger firewall than needed.

Another issue that has crept up as of late is the use of Virtual Private Networking (VPN) as a way to defeat the content filter.  Setting up an SSL VPN to an outside, non-filtered device is pretty easy for a knowledgeable person.  And if that fails, there are plenty of services out there dedicated to defeating content filtering.  While the aim of these service is noble, such as bypassing the Great Firewall of China or the mandated Internet filtering in the UK, they can also be used to bypass the CIPA-mandated filtering in schools as well.  It’s a high-tech game of cat-and-mouse.  Blocking access to one VPN only for three more to pop up to replace it.

Software Defined Protection

So how can SDN help?  Service chaining allows traffic to be directed to a given device or virtual appliance before being passed on through the network.  This great presentation from Networking Field Day 7 presenter Tail-f Networks shows how service chaining can force traffic through security devices like IDS/IPS and through content filters as well.  There is no need to add hubs or mirrored switch ports in your network.  There is also no need to configure traffic to transit the same outbound router or firewall, thereby creating a single point of failure.  Thanks to the magic of SDN, the packets go to the filter automatically.  That’s because they don’t really have a choice.

It also works well for providers wanting to offer filtering as a service to schools.  This allows a provider to configure the edge network to force traffic to a large central content filter cluster and ensure delivery.  It also allows the service provider network to operate without impact to non-filtered customers.  That’s very useful even in ISPs dedicated to education institutions, as the filter provisions for K-12 schools don’t apply to higher education facilities, like colleges and universities.  Service chaining would allow the college to stay free and clear while the high schools are cleansed of inappropriate content.

The VPN issue is a thorny one for sure.  How do you classify traffic that is trying to hide from you?  Even services like Netflix are having trouble blocking VPN usage and they stand to lose millions if they can’t.  How can SDN help in this situation? We could build policies to drop traffic headed for known VPN endpoints.  That should take care of the services that make it easy to configure and serve as a proxy point.  But what about those tech-savvy kids that setup SSL VPNs back home?

Luckily, SDN can help there as well.  Many unified threat management appliances offer the ability to intercept SSL conversations.  This is an outgrowth of sites like Facebook defaulting to SSL to increase security.  SSL intercept essentially acts as a man-in-the-middle attack.  The firewall decrypts the SSL conversation, scans the packets, and re-encrypts it using a different certificate.  When the packets come back in, the process is reversed.  This SSL intercept capability would allow those SSL VPN packets to be dropped when detected.  The SDN component ensures that HTTPS traffic is always redirected to a device that and do SSL intercept, rather than taking a path through the network that might lead to a different exit point.

Tom’s Take

Content filtering isn’t fun.  I’ve always said that I don’t envy the jobs of people that have to wade through the unsavory parts of the Internet to categorize bits as appropriate or not.  It’s also a pain for network engineers that need to keep redesigning the networking and introducing points of failure to meet federal guidelines for decency.  SDN holds the promise of making that easier.  In the above Tail-f example, the slide deck shows a UI that allows simple blocking of common protocols like Skype.  This could be extended to schools where student computers and wireless networks are identified and bad programs are disallowed while web traffic is pushed to a filter and scrubbed before heading out to the Wild Wild Web.  SDN can’t solve every problem we might have, but if it can make the mundane and time consuming problems easier, it might just give people the breathing room they need to work on the bigger issues.

by networkingnerd at September 23, 2014 03:36 PM

My Etherealmind

Do You Really Need Investment Protection for Your Network ?

When the sales grunt talks about investment protection, its sure sign that they have run out of features, functions or value propositions to sell you. But do you really need investment protection or is it just another revenue stream for vendors (and a cost for you).

The post Do You Really Need Investment Protection for Your Network ? appeared first on EtherealMind.

by Greg Ferro at September 23, 2014 01:40 PM

Cisco IOS Hints and Tricks

Connecting Virtual Routers to the Outside World

Stefan de Kooter (@sdktr) sent me a follow-up question to my Going All Virtual with Virtual WAN Edge Routers blog post:

How would one interface with external Internet in this scenario? I totally get the virtual network assets mantra, but even a virtual BGP router would need to get a physical interconnect one way or another.

As always, there are plenty of solutions depending on your security needs.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at September 23, 2014 08:32 AM

September 22, 2014

Packet Pushers Blog/Podcast

IPv6 Networking Detection Case #141 – Part 2: The Solution

Part 2: The Solution Ready for part 2? Have you read part 1 w/ the facts and clues?  If not, go read that now before you continue. Part 1: The Facts and Clues   Review the Facts and Clues Again   Last we played we were ON R1 and unable to ping the IPv6 address […]

Author information


Denise "Fish" Fishburne
CPOC Engineer at Cisco Systems

Denise "Fish" Fishburne, (CCIE #2639, CCDE #2009:0014, Cisco Champion) is a team lead with Cisco's Customer Proof of Concept Lab in Research Triangle Park, N.C. Fish loves playing in the lab, troubleshooting, learning, and passing it on.

The post IPv6 Networking Detection Case #141 – Part 2: The Solution appeared first on Packet Pushers Podcast and was written by Denise "Fish" Fishburne.

by Denise "Fish" Fishburne at September 22, 2014 09:43 PM

My Etherealmind

Internets of Interest – 22 September 2014

Collection of useful, relevant or just fun places on the Internets for 22 September 2014 and a bit commentary about what I've found interesting about them:

The post Internets of Interest – 22 September 2014 appeared first on EtherealMind.

by Greg Ferro at September 22, 2014 05:39 PM

Cisco IOS Hints and Tricks

SDN Deployment Considerations

Are you lucky enough to be one of the 87% of North American enterprises that plan to have SDN in production by 2016 or one of the 53% of the companies that plan to have SDN deployed in the near future? Even though we all know how inflated these claims are, you might have to start considering the deployment aspects of a solution a $vendor will persuade your CIO to buy.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at September 22, 2014 03:15 PM

Formal Announcement: Software Gone Wild Podcast

If you’ve been reading my blog in the last few months, you might have noticed that I started a new podcast focused on software-defined everything (hence the name: Software Gone Wild – thanks to Jason Edelman).

The latest episodes are always available on this page; you can also subscribe to the podcast feed in RSS, Atom or iTunes format… and if you wonder why we need yet-another podcast, read the About Software Gone Wild document.

by Ivan Pepelnjak (noreply@blogger.com) at September 22, 2014 08:12 AM

In Search of Tech

Where Is Cisco UCS Headed?

UCS-Grand-Slam-Social_Baseball2_v1-300x300If you happen to read my writing(as infrequent as it is these days), you know that I am a networking focused person. I live my day to day within the walls of routing, switching, wireless, and other “network centric” platforms and technologies. The days of Unix, Windows, and other generalist type administration duties are gone for me. However, like many IT professionals, I have a strong desire to understand all of the different areas in order to enhance my capabilities within the networking space. If you wish to implement IT in any particular silo, it helps to understand all the different pieces. With that in mind, I happily accepted my invite to the Cisco UCS Grand Slam event in New York City a few weeks ago. My involvement with Cisco UCS usually stops at the fabric interconnect point, and occasionally down into the virtual networking piece as well.

I mention that to state that while I understand the moving parts within storage, compute, and virtualization, I DON’T understand it at the level of people who live in those worlds full time. In light of that, I have to point out that I may be completely wrong in my predictions or thoughts around this particular launch. Then again, I may be 100% right in where this is all headed. Time will tell, and right or wrong, this will be available on the Internet until I am shamed into the void of abandoned blogs, or offered a very lucrative gig shilling for one of the billion flash storage companies.

UCS Mini

Coming into the Cisco UCS Grand Slam event, I knew about the UCS mini. Everyone knew about this. A fabric interconnect(FIC) for UCS that fits into the Cisco 5108 blade chassis. Great for smaller customers that didn’t want to go all in and buy the larger 6200 series FICs for a handful of servers. Not so great for customers that needed a ton of UCS servers and already had the larger 6200 series FICs.

Hooray! The mid market customer finally got some UCS love apart from owning a handful of C series UCS boxes. The use case was put forth for a large branch office, and since I live a lot of the time in healthcare environments, I can see that use case in hospitals. However, I still think it is a larger opportunity in the data center of smaller companies.

Here is a video I shot of one of these 6300 series FICs at the event. I can tell you that this little guy was not light, but then again, they had to pack a fair amount of technology in this smaller form factor.

But Wait, There’s More

A couple of interesting things were also announced at the event.

First, there was the M4308 modular server chassis. It is a 2U box that can hold up to 8 M142 compute cartridges. Each cartridge is actually 2 different servers. Well, it is really just a processor and memory. The M4308 uses shared network(2x40Gbps uplinks) and storage(up to 4 SSDs). Cisco has effectively decoupled everything from the server itself other than processor and memory. Why would you want to do something like this you ask? Well, the way I see it, it gives you the potential for a lot of distributed computing power without the typical expense involved in buying regular servers. Maybe you don’t need anything but a lot of processing horsepower for a particular application. Maybe you just need small servers to run a bunch of smaller applications that require their own dedicated box. It could be used for any number of things I suppose.

M4308 Front Picture

M4308 Front







M4308 – Rear Portion Open

M4308 Open Rear







M4308 Rear Picture Showing Drive Bays and Network Connections

M4308 Rear






M142 Compute Cartridge

M142 Front








M142 Cartridge Opened

M142 Open







Second, the C3160 server was announced. Basically, this is a big storage box. It can hold up to 360TB of storage. It has 64 drive bays. While Cisco isn’t the first to release a server with tons of storage space like this, it does make their compute offering a little more complete.

C3160 Server









Is That All There Is?

Okay, so we have some new hardware that gives us more options. That’s always a good thing, right? Other, more qualified server/storage/virtualization folks, would have a lot more content regarding these products, and you can find their posts linked at the bottom of this page. I would normally end things here. A basic piece about the new UCS offerings.

But then I read this piece from Stephen Foskett, where he discusses virtualized and distributed storage…….

That added some more info to what I had already been pondering in regards to the future of UCS. I also ran across this post from Colin Lynch, and he makes some very interesting statements that caught my eye:

“You need to embrace the concept that UCS is not a Chassis Centric architecture”

“There is no intelligence or hardware switching that goes on inside a UCS Chassis.”

Now consider the rise of solutions like Nutanix and Scale Computing. Consider how they differ from the traditional big storage and big compute silos that we tend to pack into data centers. They converge it all down into nodes that intelligently link together. It’s a clever way to provide somewhat similar services, but with the ability to scale out linearly in both storage and compute within the same box/vendor.

Here’s where I am going to take a wild guess. I think that in the coming years, Cisco will be able to provide the compute, storage, and networking, but in a variety of different building block sizes. From the compute perspective, they already have an interesting array of products. From the networking side within the data center, they have already demonstrated their ability to provide a variety of platforms to suit every need from 1Gbps up to 100Gbps. The missing piece is the storage aspect. Maybe that is where Invicta(Whiptail) comes in. If Stephen is right, distributed storage will be the future. Instead of very large centralized storage platforms, we’ll see lots of smaller platforms spread out across the data center.

As long as the distributed systems can provide the same or similar type of services that the large centralized storage platforms have, I think it can work. Since I am not a storage guy by trade, I have to assume that there are features and capabilities that the larger centralized storage platforms possess that would be hard for Cisco to duplicate with UCS. This would be similar to how larger chassis switches such as the Nexus 7000’s offer things that smaller 1RU switches typically do not. If I were to assume that less than a quarter of storage implementations utilized the largest arrays available, that leaves a considerable chunk of the storage market that can be served with a highly distributed model. I just made that 25% number up. I have no idea what the real number is of organizations that use something like VMAX from EMC. Even if that number is 50%, that is still a lot of customers that don’t need the largest storage platform.

Closing Thoughts

I’ll admit that there is a LOT that I don’t understand when it comes to storage and compute. However, I think at a basic level, we can all understand what the various pieces of the puzzle are within the data center when it comes to infrastructure. If there is something to be gained by using smaller components, while managing it all centrally to where it isn’t that much different than having massive compute, storage, and network blocks, then how bad can that be? I suppose it all hinges on the performance required for the business to function properly. Perhaps, if I look at this from an SDN perspective, it will make more sense. If I can get the same reliability and performance from a bunch of distributed switches throughout a data center and manage them centrally(not just NOC type monitoring, but distributed forwarding intelligence), as opposed to nailing up all 10/40/100Gbps connections to a monster chassis, how is that a bad thing? It should be cheaper, and it should allow for more flexibility.

If I were Cisco, I would want to own it all from the network port to the hardware the data lives on and is processed on. Provided it could all be managed and provisioned from a central location, that is a compelling offer. Vendor interoperability is a good thing, but outside of a single vendor, the single pane of glass concept is relatively unrealized.

I’ll end this post here, because I have started to ramble, and I am not entirely sure if I have made a whole lot of sense. What I am certain of is that Cisco has started creeping closer into the storage vendor’s territory. Will they end up making another acquisition in the storage world soon, or will the Whiptail acquisition provide them with as much of the storage piece as they want? I have no idea. What I do know is that they have managed to make a dent in the compute/server market with UCS in just a few short years. It seems to me that storage is the logical next step for them. If storage as we know it is changing into a more distributed model, I wouldn’t rule out some additional offerings from them. I have no firm insider information regarding their future plans. Just a hunch.

Disclaimer: My travel, lodging, and food expenses were covered by the Tech Field Day crew(Thanks again!), and I assume that Cisco ultimately footed the bill for my accommodations. I wasn’t asked to write anything in return, and based on the timing of this post(which I haven’t had time to finish until tonight in a hotel room), I can assure you that they have probably given up on me by now if they were expecting something. ;)

by Matthew Norwood at September 22, 2014 04:40 AM

XKCD Comics

September 20, 2014

Honest Networker