The 5 Year Plan

I was recently asked what my 5 year career plan was and whether I wanted to go down the architect route. It threw me a little bit because I’ve never really been a 5 year type person. I have real trouble seeing where I’ll be beyond a year to 18 months.

So, this is my attempt to try and put something together. It doesn’t hurt to have a plan right?

Ideally, you need a short, medium and long term plan. A couple of these could be tech related (e.g: get to CCIE), but the pace technology moves at means the longest term one (if it’s longer than 3 years could well have moved goalposts, or died out). So, without ado, I give you the 3 – 6- 12 – 24 – 36 plan. Or 3,6,1,2,3 plan. This is my way of putting down what I want to have achieved in the next 3-6 months, year, 2 and 3 years.

3-6 months: Get my CCNP Security finished with, and maybe another associate level non-Cisco vendor certification.

1 year: Complete my CCIE written and be on my way to lab revision.

2 years: Completed, or have attempted the CCIE lab once.

Continue reading

Why you should want metered INET?

When people think about metered, they may think about mobile roaming or old outrageous per minute PSTN billing. Those are not fair prices, they are not what I'm talking about.

Also INET should be always on, billing should take this into consideration, maybe once you exceed your paid capacity, your connection is policed to 256kbps unless you pay for more. You could get notice when this limit is nearing by SMS and Email.

Flat-rate billing is based on assumption that on average INET is not used much at all, in such scenario it works. Consumers get flat-rate stove-gas in Helsinki, because its use is almost non-existing. But services like Youtube and Netflix which are relatively new can alone be 2/3 of all your traffic, meaning what ever average use you planned for, it's not true, average use is increasing as more services users care for appear.


1. Quality

When you pay flat rate there is financial incentive for your operator not to provide you bits, every bit not provided improves your margins. Operators today regularly keep some ports congested, because it would be expensive to upgrade, instead they try get someone else to pay for it, if they have the Continue reading

#NFD7 Real Time SDN and NFV Analytics for DDoS Mitigation


Today, at Networking Field Day 7, Ramki Krishnan of Brocade Networks demonstrated how the sFlow and OpenFlow standards can be combined to deliver DDoS mitigation as a service. Ramki is a co-author of related Internet Drafts: Large Flow Use Cases for I2RS PBR and QoS and Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks.
The talk starts by outlining the growing problem of DDoS attacks and the market opportunity for mitigation solutions, referencing the articles, Prolexic Publishes Top 10 DDoS Attack Trends for 2013, World's largest DDoS strikes US, Europe.
The diagram shows the unique position occupied by Internet Service Provider (ISP) and Internet Exchange (IX) networks, allowing them to filter large flood attacks and prevent them from overwhelming Enterprise customer connections - provided they can use their network to efficiently detect attacks and automatically filter traffic for their customers.
This diagram shows how standard sFlow enabled in the switches and routers provides a continuous stream of measurement data to InMon sFlow-RT, which provided real-time detection and notification of DDoS attacks to the DDoS Mitigation SDN Application. The DDoS Mitigation SDN Application selects a mitigation action and instructs the SDN Controller to push the action to Continue reading

Faking an ASA as a DNS Forwarder

I came across a good tip the other day that was very helpful during a small site firewall migration. Here’s the back story:

I was migrating a small single-site customer that had, up to this point, been using a FIOS-provided consumer-type router/firewall/access point to some Cisco gear including an ASA firewall for better firewall/VPN capabilities. This is fairly common with small businesses that start out with essentially consumer-style connectivity and finally begin to grow to a point of needing business-grade capabilities. My preparation went fine, and when the time came I swapped the ASA firewall in place of the FIOS-provided one. Then everything broke.

I had meticulously prepared the ASA to take over immediately from the old FIOS router, even going so far as to spoof the FIOS router’s MAC address on the ASA’s inside interface for now so as not to disrupt the 60-or-so clients that were all on the single attached internal subnet while their ARP caches timed out since we were doing the install and cut-over during working hours. I had set up a DHCP scope on the ASA as well, which instructed clients to use some public DNS resolvers as this small business has, so far, Continue reading

Goodbye Snowpocalypse, Hello Networking Field Day 7!

Snowpoc Resized

It’s been a long winter here in Pennsylvania. Near record-breaking for snowfall. But yesterday I traveled to beautiful and temperate San Jose to attend Networking Field Day 7!
I’m honored to have been selected as a delegate for another Tech Field Day event, as these events are a fantastic opportunity to engage with vendors and industry peers. I use the term “peers” only because we work in the same industry. Everyone else is smarter than me.

I’m excited to rub elbows and network with the exceptional delegate list. I have met nearly all of this event’s delegates before and I respect the expertise and experience of every single participant. I feel I have learned so much and made so many valuable connections through TFD events and I’m grateful to Gestalt IT and the TFD community for another opportunity to participate.

Most of all, I’m excited for the opportunity to represent you, the networking/IT community at large. Asking the questions you would ask. I will be live Tweeting during the presentations, so direct your questions my way and I’ll do my best to ask your questions if I miss something you want to know about.

Sponsors

I was going to Continue reading

BGP in 2013 – The Churn Report

When looking at the Internet's Inter-domain routing space, the number of routed entries in the routing table is not the only metric of the scale of the routing space – it’s also what the routing protocol, BGP, does with this information that matters. As the routing table increases in size do we see a corresponding increase in the number of updates generated by BGP as it attempts to find a converged state? What can we see when we look a the profile of dynamic updates within BGP, and can we make some projections here about the likely future for BGP?

25 – Why the DC network architecture is evolving to fabric?

The Datacenter network architecture is evolving from the traditional multi-tier layer architecture, where the placement of security and network service is usually at the aggregation layer, into a wider spine and flat network also known as fabric network ( ‘Clos’ type), where the network services are distributed to the border leafs.

This evolution has been conceived at improving the following :

  • Flexibility : allows workload mobility everywhere in the DC
  • Robustness : while dynamic mobility is allowed on any authorised location of the DC, the failure domain is contained to its smallest zone
  • Performance: full cross sectional bandwidth (any-to-any)  – all possible equal paths between two endpoints are active
  • Deterministic Latency : fix and predictable latency between two endpoints with same hop count between any two endpoints, independently of scale.
  • Scalability : add as many spines as needed to increase the number of servers while maintaing the same oversubscription ratio everywhere inside the fabric.

If most of qualifiers above have been already successfully addressed with traditional multi-tier layer architecture, today’s Data centres are experiencing an increase of East-West data traffic that is the result of:

  • Adoption of new software paradigm of highly distributed resources
  • Server virtualization and workload mobility
  • Migration to IP Continue reading

The Power of a Programmable Abstraction Layer

In the previous post, I talked about a common programmable abstraction layer (CPAL).  To better understand the thought process behind having a common PAL, it makes sense to review some of the work Jeremy Schulman has been doing.  Jeremy often refers to the Python interactive shell as the new CLI for networking.  When you watch him give a demo using the Python shell as a CLI, it is second nature and looks exactly like a network CLI.  It makes perfect sense.
It gives real time access to the network devices in a programmatic fashion.  Being programmatic is key here – no screen scraping, etc.  The downside --- you need to know Python.  Well, yes and no.  Of course, you would be using the Python interpreter so you’ll be leveraging programming concepts -- things like variables, functions, classes, etc. 

But, before you think you need to become a professional software developer, the other good news is that Jeremy has created the Junos OS PyEZ library that drastically simplifies the interaction and baseline knowledge to start programming Juniper devices.  Juniper supports native XML APIs, but the PyEZ module abstracts that and eliminates Continue reading

Cisco Nexus 9000 NX-API

A robust built-in API is not something you traditionally see in a Cisco router or switch. My first experience with anything like this on Cisco was with Unified Computing System. Though it’s a high-level API that interacts only with the UCSM application managing the entire stack, it’s still a robust way to configure policy and resources within UCS. ACI is recieving the same treatment, and though it’s true that there will be a slew of programmability options built into the APIC controller that is the cornerstone of the ACI fabric that we’ll be hopefully seeing later this year, there are also some very cool options on each individual switch in NXOS or Standalone mode as well.

Cisco Nexus 9000 NX-API

A robust built-in API is not something you traditionally see in a Cisco router or switch. My first experience with anything like this on Cisco was with Unified Computing System. Though it’s a high-level API that interacts only with the UCSM application managing the entire stack, it’s still a robust way to configure policy and resources within UCS. ACI is recieving the same treatment, and though it’s true that there will be a slew of programmability options built into the APIC controller that is the cornerstone of the ACI fabric that we’ll be hopefully seeing later this year, there are also some very cool options on each individual switch in NXOS or Standalone mode as well.

Show 180 – The Art of Network Architecture: Business-Driven Design

In this show, host Ethan Banks is joined by Russ White & Denise Donohue, co-authors of the soon-to-be-released CiscoPress title, The Art of Network Architecture: Business Driven Design. Orhan Ergun reviewed the book and also shares his perspectives. This isn’t just a book review, though. Really, the show uses the book as a springboard to […]

Author information

Ethan Banks

Ethan Banks, CCIE #20655, has been managing networks for higher ed, government, financials and high tech since 1995. Ethan co-hosts the Packet Pushers Podcast, which has seen over 2M downloads and reaches over 10K listeners. With whatever time is left, Ethan writes for fun & profit, studies for certifications, and enjoys science fiction. @ecbanks

The post Show 180 – The Art of Network Architecture: Business-Driven Design appeared first on Packet Pushers Podcast and was written by Ethan Banks.

Cisco ACI – Nexus 9000 Initial Configuration

I was fortunate enough to be given access to a pair of Nexus 9Ks in our lab, and I want to give a brief overview of the initial configuration process, and a brief introduction to some of the features initially presented to us on the switch platform. Here are a few summarized thoughts: Calling it a switch is actually kind of funny to me. All ports are routed and shutdown by default, and though you can obviously “no shut” them, and you can convert to a switchport, the switch is clearly built for all-L3 operations.

Cisco ACI – Nexus 9000 Initial Configuration

I was fortunate enough to be given access to a pair of Nexus 9Ks in our lab, and I want to give a brief overview of the initial configuration process, and a brief introduction to some of the features initially presented to us on the switch platform. Here are a few summarized thoughts: Calling it a switch is actually kind of funny to me. All ports are routed and shutdown by default, and though you can obviously “no shut” them, and you can convert to a switchport, the switch is clearly built for all-L3 operations.

Cisco ACI – Nexus 9000 Initial Configuration

I was fortunate enough to be given access to a pair of Nexus 9Ks in our lab, and I want to give a brief overview of the initial configuration process, and a brief introduction to some of the features initially presented to us on the switch platform. Here are a few summarized thoughts: Calling it a switch is actually kind of funny to me. All ports are routed and shutdown by default, and though you can obviously “no shut” them, and you can convert to a switchport, the switch is clearly built for all-L3 operations.

Programmatically Configuring Interface Descriptions from Phone Descriptions

I wrote some Python code that allows you to do the following:
  1. Query a Catalyst switch CDP neighbor table from its HTTPS interface,
  2. Extract the device names of the attached IP phones,
  3. Query Communications Manager for the IP phone device description, 
  4. Apply the device description as the switch interface description.
Obviously, this makes it much easier to see whose phone is attached to a switch port.

I hope that this example saves someone the head-banging that I incurred while trying to figure out the AXL XML/SOAP API for Communications Manager.

I haven't tested this extensively; all my testing has been on Catalyst 3560 and 3750 switches and CUCM version 8.6. Using the --auto switch to automatically configure the switch is quite slow; this is a limitation of the HTTPS interface rather than the script code. It may be faster to leave that option off and manually copy/paste the printed configuration if you're in a hurry.

Note that your switch must be configured to allow configuration via the HTTPS interface; you may need to modify your TACACS/etc. configurations accordingly.

All the relevant info is in the Github repo.

Programmatically Configuring Interface Descriptions from Phone Descriptions

I wrote some Python code that allows you to do the following:
  1. Query a Catalyst switch CDP neighbor table from its HTTPS interface,
  2. Extract the device names of the attached IP phones,
  3. Query Communications Manager for the IP phone device description, 
  4. Apply the device description as the switch interface description.
Obviously, this makes it much easier to see whose phone is attached to a switch port.

I hope that this example saves someone the head-banging that I incurred while trying to figure out the AXL XML/SOAP API for Communications Manager.

I haven't tested this extensively; all my testing has been on Catalyst 3560 and 3750 switches and CUCM version 8.6. Using the --auto switch to automatically configure the switch is quite slow; this is a limitation of the HTTPS interface rather than the script code. It may be faster to leave that option off and manually copy/paste the printed configuration if you're in a hurry.

Note that your switch must be configured to allow configuration via the HTTPS interface; you may need to modify your TACACS/etc. configurations accordingly.

All the relevant info is in the Github repo.

ESXi Server Build

With the release of the IOS XRv router, along with CSR (Cloud Services Router), its time that I go ahead and build myself a virtualization solution.

To that effect, I have just ordered the components for a home build server, which was the cheapest, not to mention most silent option available.

The components are:
Intel Xeon 3.2 Ghz processor (E3-1230).
32 Gig of memory.
Intel Micro ATX server motherboard (S1200V3RPL).
A 120 Gig Kingston SSD.
A supposedly silent PSU.
And to house it all, a Lian-Li Micro-ATX cabinet (PC-V300B).

Hopefully, everything will be here next week. Looking forward to it :)

Kicking tires on Cumulus Linux

So, I ended my last blog post with a wish – “hopefully someday I can get a real switch running Cumulus to play with ;-)”  Well, as it turns out, that post was somewhat popular, and caught the attention of some folks at Cumulus Networks (who kindly RT’d my tweet publicizing the post – thanks!) […]

Author information

Will Dennis

Will Dennis

Will Dennis has been a systems and network administrator since 1989, and is currently the Network Administrator for NEC Laboratories America, located in Princeton NJ. He enjoys the constant learning it takes to keep up with the field of network and systems administration, and is currently pursuing the Cisco CCNP-R/S certification. He can be found on the Twitters as @willarddennis, and on Google Plus.

The post Kicking tires on Cumulus Linux appeared first on Packet Pushers Podcast and was written by Will Dennis.