Taking a New Approach to Cisco Live 2014

It’s getting to be that time of year again when geeks across North America (and beyond) start getting excited for Cisco Live! The buzz is starting a bit early this year, but that’s because Cisco Live is about a month earlier this year (May 18-22) than it has been in recent years.

Introduction

Many of the exciting details of the event have surfaced at this point, including the announcement of Salman Khan, founder of Khan Academy as the closing guest keynote speaker, and that the Customer Appreciation Event will feature Lenny Kravitz and the Imagine Dragons as musical acts. We’ve even seen this year’s backpack design, courtesy of a couple Tweets from Cisco’s Kathleeen Mudge:

Last year, I put together a post of Cisco Live tips, most of which are just as applicable this year as last. My personal approach, however, will be a bit different this year.

Plans Continue reading

Show 184 – The Future of Networking Part 2 as Inspired by #NFD7

At Networking Field Day 7, the delegates were treated to vendor demonstrations that challenged our thinking about the future of networking. Perhaps the industry is not agreed on just how we’ll implement and operate our networks in the coming years, but one thing is for certain. The landscape will be different. In this and the previously […]

Author information

Ethan Banks

Co-host at Packet Pushers

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
TwitterGoogle+LinkedIn

The post Show 184 – The Future of Networking Part 2 as Inspired by #NFD7 appeared first on Packet Pushers Podcast and was written by Ethan Banks.

Review: Hadoop Operations

Hadoop Operations Eric Sammer Hadoop is one of those applications all data centers seem to need to support – and there is a lot of information out there about how Hadoop works, how to use it, and how to build Hadoop systems. From these, it’s pretty easy to glean a general set of requirements for […]

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 Continue reading

HP Comware-based Switches – Link Aggregation

The 3Com/HPN/H3C based Switches offers the utilization of interfaces such as Ethernet, Fast Ethernet, GigabitEthernet or TenGigabitEthernet. The Link Aggregation feature allows the gathering of many ports in order to increase the link’s velocity concerning the full duplex communication between the two devices.

In Link-Aggregation mode the ports are utilized in parallel, supporting the bandwith’s growth and expansion, without the need of buying an additional hardware.

For example, we can use four 100Mb ports in each device to form a communication between two switches using 400Mb among them. However, the utilization of redundant enlaces raises the possibility of loops within the network. Link Aggregation avoids the situation which the blocking state or loops, stop the gathered ports, treating them as one single interface. For the STP, SNMP and VLANs the interfaces are treated as one logical link.

Other name used for the Link Aggregation is EtherChannel.

The LACP protocol is part of the 802.3ad specification for Link Aggregation, allowing that switches and servers negotiate the port groups with different manufactures automatically. Both ports should offer constant support to the protocol, so that the Link Aggregation could work correctly.

Some Switch models can utilise the PagP (Cisco) protocol or interface Continue reading

A Reappraisal of Validation in the RPKI

I’ve often heard that security is hard. And good security is very hard. Despite the best of intentions, and the investment of considerable care and attention in the design of a secure system, sometimes it takes the critical gaze of experience to sharpen the focus and understand what’s working and what’s not. We saw this with the evolution of the security framework in the DNS, where it took multiple iterations over 10 or more years to come up with a DNSSEC framework that was able to gather a critical mass of acceptance. So before we hear cries that the deployed volume of RPKI technology means that its too late to change anything, let’s take a deep breath and see what we've learned so far from this initial experience, and see if we can figure out what's working and what's not, and what we may want to reconsider.

Packet Life Turns Six

Today marks Packet Life's sixth birthday, and I'm celebrating by launching the new site format I talked about in January. The relaunched site is hosted on an entirely new server from Linode, which means you can (finally) access packetlife.net via native IPv6! The entire code base has been rewritten on Django 1.6, and should feel lighter and more responsive. The layout has been rewritten as well using the Bootstrap CSS framework.

You might have noticed that some components of the old site are now gone: The discussion forums and wiki have been axed in favor of focusing more on the site's core content. The tools armory, which was initially in jeopardy, has been maintained in response to community interest (although I do intend to spend a good amount of time cleaning it up).

There are no doubt bits of code here and there that need a tweak or three, but generally speaking the site is up and running. If you do encounter an error, rest assured that I've been alerted and should have it fixed in little time. If you feel that something is terribly amiss, give me a shout on Twitter and I'll look into Continue reading

Get Another Network Cert Or Learn More About DevOps?

You can’t listen to an interview or podcast, an industry panel, or read a Q&A about the future of networking that doesn't involve skill sets.  The biggest question of them all – what skills should network engineers focus on so they don’t become irrelevant? If you really want to know what skills make sense, why ask, when you can do an easy search to see what skills companies are looking for these days in a variety of roles.  Combine SDN with DevOps into your search criteria and the results may surprise you.  They sure surprised me.  
I don’t usually peruse the job boards, but I’m on LinkedIn daily, so I figured I’d put their job site to the test and see what skills are in demand by searching for specific products and tools.  This is the best way to search, right?  I did numerous searches using the following keywords: SDN, Puppet, Chef, Ansible, Python, Cisco, network, and CCIE.

Here are the results:
  • There were only five (5) jobs available when searching for SDN, CCIE, and Python.  Reminder, I only searched LinkedIn.
  • The first was for a vendor as a “SDN Cloud Architect.”  Continue reading

Quick Thoughts on the Micro Data Center

Here's something that's been on my radar lately: while all the talk in the networking world seems to be about the so-called "massively scalable" data center, almost all of the people I talk to in my world are dealing with the fact that data centers are rapidly getting smaller due to virtualization efficiencies. This seems to be the rule rather than the exception for small-to-medium sized enterprises.

In the micro data center that sits down the hall from me, for example, we've gone from 26 physical servers to 18 in the last few months, and we're scheduled to lose several more as older hypervisor hosts get replaced with newer, denser models. I suspect we'll eventually stabilize at around a dozen physical servers hosting in the low hundreds of VMs. We could get much denser, but things like political boundaries inevitably step in to keep the count higher than it might be otherwise. The case is similar in our other main facility.

From a networking perspective, this is interesting: I've heard vendor and VAR account managers remark lately that virtualization is cutting into their hardware sales. I'm most familiar with Cisco's offerings, and at least right now they don't seem to Continue reading

Quick Thoughts on the Micro Data Center

Here's something that's been on my radar lately: while all the talk in the networking world seems to be about the so-called "massively scalable" data center, almost all of the people I talk to in my world are dealing with the fact that data centers are rapidly getting smaller due to virtualization efficiencies. This seems to be the rule rather than the exception for small-to-medium sized enterprises.

In the micro data center that sits down the hall from me, for example, we've gone from 26 physical servers to 18 in the last few months, and we're scheduled to lose several more as older hypervisor hosts get replaced with newer, denser models. I suspect we'll eventually stabilize at around a dozen physical servers hosting in the low hundreds of VMs. We could get much denser, but things like political boundaries inevitably step in to keep the count higher than it might be otherwise. The case is similar in our other main facility.

From a networking perspective, this is interesting: I've heard vendor and VAR account managers remark lately that virtualization is cutting into their hardware sales. I'm most familiar with Cisco's offerings, and at least right now they don't seem to Continue reading

Secret CEF Attributes Part 6, The BGP Connection

In the first five parts of this series we covered all the steps necessary to distribute QoS and monitoring to a large backbone. I guess at this point I should mention that this technology has a name (and acronym, of course.) Cisco calls it QoS Policy Propagation through BGP (QPPB.) I hope these blog posts […]

Author information

Dan Massameno

Dan Massameno is the president and Chief Engineer at Leaf Point, a network engineering firm in Connecticut.

The post Secret CEF Attributes Part 6, The BGP Connection appeared first on Packet Pushers Podcast and was written by Dan Massameno.

Mind the Gap

One of my pleasures of traveling is listening to the way people speak both with their dialects and their phrases. For those of you that have been to London and ridden “The Tube,” you know that familiar recording, “Mind the Gap.” After talking with several people at this year’s Open Networking Summit (ONS) this past week, I heard that same phrase in my head.

Why?

In this case, the “gap” is the chasm that early software defined networking (SDN) adopters have to cross to get started.  Because SDN is a new idea, crossing the gap represents being prepared to challenge old ideas about networking and even your own experiences.

If you really think about it, you don’t want to just mind the gap—you want to be careful not to fall into the old ways of thinking—but you want to cross that gap and keep moving forward. To do that from an open networking perspective, you have to create an opportunity and dig in, grab a controller and an SDN-ready switch and start hacking.

I had a fantastic discussion with a customer at the ONS week who had safely crossed the gap.  Let’s call him Joe. Joe is Continue reading

TCP/IP over VXLAN Bandwidth Overheads

A recent ‘conversation’ around VXLAN encapsulation and MTU with Matt Oswalt got me thinking about this subject recently. My calculations were mostly wrong (Matt’s were not) and I also found a shocking amount of incorrect information on the subject out on the ‘net too. So, let’s let the maths do the talking. TL;DR – As […]

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.

TwitterLinkedIn

The post TCP/IP over VXLAN Bandwidth Overheads appeared first on Packet Pushers Podcast and was written by Steven Iveson.

Cyber Spring Cleaning! Don’t Forget Your Wireless Router!

cleaning-productsAs the weather warms up articles to remind us about cleaning up our devices, online accounts, making backups, and changing passwords are sure to show up, but don’t forget to add your wireless router to this list. Over time the wireless environment may have changed and the number of devices connecting to the network has increased and you have noticed a decrease in the performance. I have listed some items to check to either improve the performance or security of your wireless network.

Upgrade the Router

Electronics age fast and if you’re still running an 802.11g router it is time to upgrade. Look for an 802.11n protocol wireless router or get the latest and greatest 802.11ac router and be ready for the next wave of wireless devices. Either way you’ll notice a performance boost and the router won’t create a bottleneck in the network.

Check for the Latest Firmware

While not as often as Windows or Apple software updates a routers software called firmware does get the occasional update. Firmware could add functionality, patch bugs, or add security features. When you log into the routers management interface look for the firmware section to verify the current version and download Continue reading

Hey, Remember vTax?

Hey, remember vTax/vRAM? It’s dead and gone, but with 6 Terabyte of RAM servers now available, imagine what could have been (your insanely high licensing costs).

Set the wayback machine to 2011, when VMware introduced vSphere version 5. It had some really great enhancements over version 4, but no one was talking about the new features. Instead, they talked about the new licensing scheme and how much it sucked.

wayback2

While some defended VMware’s position, most were critical, and my own opinion… let’s just say I’ve likely ensured I’ll never be employed by VMware. Fortunately, VMware came to their senses and realized what a bone-headed, dumbass move that vRAM/vTax was, and repealed the vRAM licensing one year later in 2012. So while I don’t want to beat a dead horse (which, seriously, disturbing idiom), I do think it’s worth looking back for just a moment to see how monumentally stupid that licensing scheme was for customers, and serve as a lesson in the economies of scaling for the x86 platform, and as a reminder about the ramifications of CapEx versus OpEx-oriented licensing.

Why am I thinking about this almost 2 years after they got rid of vRAM/vTax? I’ve been Continue reading

“Fun” with RFC4620 Section 6.4 and discovering IPv4 information over IPv6

As part of a request at work to figure out IPv4 addresses of devices on a network where broadcast pings don’t work, and no administrative access to the switches/routers, I took a look at solving this with IPv6. We know that you can ping6 the all-nodes multicast address, and get DUP! replies from IPv6 enabled hosts on that LAN segment. These will typically be link-local addresses, from which you can determine a MAC address. How to resolve that MAC address on a client host and not the router/switch, I was thinking reverse ARP or something, but support for that wasn’t present in my Ubuntu 13.10 kernel on the main machine I was working with. I started looking around for other options using IPv6 and found RFC4620, Section 6.4.

The gist of it is that you send an ICMPv6 Type 139 packet to an IPv6 address, asking if it has any IPv4 addresses configured either on that interface the target address is on, or any interfaces on the machine itself. And this is why this is disabled by default on hosts, and *IF* you insist on filtering ICMP6 Types, definitely make certain this is one of them. It works Continue reading

Show 183 – Storage Network Design

This week, the Packet Pushers talk about storage network design mostly in the context of converged infrastructure. Guests J Metz, Chris Wahl, and Russ White do all the heavy lifting of those storage-related packets from one end of the data center to the other. Show Outline When traditional network engineers think about designing for storage, […]

Author information

Ethan Banks

Co-host at Packet Pushers

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
TwitterGoogle+LinkedIn

The post Show 183 – Storage Network Design appeared first on Packet Pushers Podcast and was written by Ethan Banks.

Quick look at Trio ddos-protection with flow-detection

Some things are easy to protect with iACL and lo0 ACL but others are really hard, like BGP, you need to allow BGP from customers and from core, and it's not convenient or practical to handle them separately in lo0 ACL + policer. Luckily JunOS has feature called flow-detection, you turn it on with set system ddos-protection global flow-detection

I'm sending DoS from single source to lo0, my iBGP goes immediately down. After I turn on flow-detection iBGP connectivity is restored. Looking at PFE, we can see what is happening:

MX104-ABB-0(test13nqa1-re0.dk vty)# show ddos scfd asic-flows pfe idx rindex prot aggr IIF/IFD pkts bytes source-info --- ---- ------ ---- ---- ------- ------- -------- ---------- 0 0 721 1400 sub 338 21 79161 c158ef22 c158ef1f 53571 179 0 1 2679 1400 sub 356 11159404 2187242988 64640102 c158ef1f 179 179 0 2 2015 1400 sub 338 29 112468 c158ef23 c158ef1f 179 65020

Pretty nice and clear, 64.64.01.02 => c1.58.ef.1f is our attack traffic and it's getting its own policer, iBGP is stable, attack traffic is policed separately. Let's check those policers more closely:

MX104-ABB-0(test13nqa1-re0.dk vty)# show ddos scfd asic-flow-rindex 0 2679 PFE: 0 Flow Continue reading

1 … 3,757 3,758 3,759 3,760 3,761 … 3,849