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

City of Lights Hosts First Global MPLS/SDN Event

City of Lights Hosts the First Global MPLS/SDN Event

by Brian Boyko, Technology Commentator  - March 18, 2014

Packet Design will be attending the 2014 MPLS SDN World Congress this week in Paris. This is the 16th edition of the event, but this year it becomes the MPLS SDN World Congress (formerly known as the MPLS & Ethernet World Congress). According to the event producer Upperside Conferences, this is the first worldwide event in MPLS and SDN. Attendees will come from more than 65 countries, and more than 50 percent of this audience works for service providers. 

Considering that we have customers on five continents, the majority of those customers are service providers, and that we are working on an SDN management prototype, this is an exciting event for us. Our CTO Cengiz Alaettinoglu, who is attending the event for the seventh time, is particularly excited to share our SDN vision and meet with service providers, customers and peers. He will be speaking about “Real-Time Analytics and Policy Management for Software Defined Networking.” Here’s a quick summary of his presentation: 

North-bound SDN APIs allow creation of network-aware applications. Cloud and data center applications have successfully taken Continue reading

SSH for Python – In search of API perfection

My mission is simple: Establish an SSH connection to a device and run some commands in as few lines as possible. The contenders? Paramiko, Spur and Fabric.

The Scenario

I have a network device, 192.168.1.254. I want to log in via SSH with a username of dave and password of p@ssword123. Once logged in, I want to execute the command display version and print the result.

Now to the code...

The Code

Paramiko

Paramiko is the go to SSH library in Python. Let's see how it shapes up in the simple scenario:

import paramiko
client = paramiko.SSHClient()
client.load_system_host_keys()
client.set_missing_host_key_policy(paramiko.WarningPolicy())
client.connect("192.168.1.254", username="dave", password="p@ssword123")
stdin, stdout, stderr = client.exec_command('display version')
for line in stdout:
    print line.strip('n')
client.close()

8 lines of code. The API here is very powerful, but requires me to put up some scaffolding code (Key Management) before I actually get around to connecting an executing my command. That said, it gets the job done.

Spur

Spur is a wrapper around Continue reading

ONS 2014: Looking at Programmable NFV, Google, MSFT, Embrane, and Big Switch

It’s been two weeks since I attended my 3rd consecutive Open Networking Summit (ONS) and I’m glad to say, I finally found some time to get some notes and thoughts on paper about the conference.  Here are some on SDN at Google and Microsoft, and how they compare and contrast to industry incumbents’ solutions, but also how programmable NFV can be game changing in the Enterprise.  I also include thoughts on how Embrane and Big Switch play into this.
Enter Andromeda

Google talked about their [home grown] network virtualization solution.  It leverages a custom SDN controller called Andromeda that controls physical switches, virtual switches, programmable NFV devices, and also ties into the storage platforms deployed.  Google talked about how they have showed industry leadership with technologies such as GFS, MapReduce, B4 WAN, etc.  If I extrapolate, they expect Andromeda to do for data center networking what GFS is doing for distributed scale out storage.  Who will be the Nutanix of networking?

Google, like few others, still define SDN as the separation of the control plane and data plane.  Google states, “logically centralized/ hierarchical control plane with peer to peer data plane beats full Continue reading

Tourist trip to MX fabric

Tourist, because it's mostly original research so quality may be dubious.

You can infer lot about the fabric by looking at 'show hsl2 ...' commands. Let's start.

NPC0(test13nqe1-re1.dk vty)# show hsl2 asic mqchip(0) serdes MQCHIP(0) serdes table : MQCHIP(0)-Avago 65NM-0 [0xf300000]: 24 links 0 - 23 MQCHIP(0)-Avago 65NM-1 [0xf304000]: 24 links 24 - 47 MQCHIP(0)-Avago 65NM-2 [0xf308000]: 8 links 48 - 55 MQCHIP(0)-Avago 65NM-3 [0xf309000]: 8 links 56 - 63 MQCHIP(0)-Avago 65NM-4 [0xf30a000]: 8 links 64 - 71 MQCHIP(0)-Avago 65NM-5 [0xf30b000]: 8 links 72 - 79 MQCHIP(0)-Avago 65NM-6 [0xf30c000]: 8 links 80 - 87 MQCHIP(0)-Avago 65NM-7 [0xf30d000]: 8 links 88 - 95 MQCHIP(0)-Avago 65NM-8 [0xf30e000]: 8 links 96 - 103 MQCHIP(0)-Avago 65NM-9 [0xf30f000]: 8 links 104 - 111 MQCHIP(0)-Avago 65NM-10 [0xf310000]: 8 links 112 - 119 MQCHIP(0)-Avago 65NM-11 [0xf311000]: 8 links 120 - 127 MQCHIP(0)-Avago 65NM-12 [0xf312000]: 8 links 128 - 135 MQCHIP(0)-Avago 65NM-13 [0xf313000]: 8 links 136 - 143 MQCHIP(0)-Avago 65NM-14 [0xf318000]: 2 links 144 - 145 MQCHIP(0)-Avago 65NM-15 [0xf31a000]: 2 links 146 - 147

Avago is well known manufacturer of SerDes (SERialization / DESerialization), 65NM probably means Avago's 65nm lithography line of products. SerDes presentation here is unidirectional. But that is still quite large number of SerDes Continue reading

Using Next Generation MVPN to optimize your MPLS core – Part 1

Like many network engineers I have had difficulties with multicast, the logic is all messed up right!? The only implementation of mVPN I had seen in test or production was Draft Rosen (RFC6037). Now I know Draft Rosen works well but it does have its limitations and I’m a firm believer in getting unnecessary junk […]

Author information

Keith Humphreys

Keith Humphreys

Keith is a network architect and CCIE #40869 working for the Irish arm of a global service provider. His main focus is on IP/MPLS design and he is a big fan of Alcatel-Lucent SR-OS. Follow him on Twitter and check out his blog over at iamjeffvader.com

The post Using Next Generation MVPN to optimize your MPLS core – Part 1 appeared first on Packet Pushers Podcast and was written by Keith Humphreys.

Capture your fancy, part two, Trio

Like with 7600/PFC3, it is possible to capture transit traffic on Juniper Trio (MPC, MX80, MX104, FPC5 etc). First decide what you know about the packet and convert that data to hex, it can be pretty much anywhere in the packet in the first 320B or so.

[[email protected] ~]% pry [1] pry(main)> '194.100.7.227'.split('.').map{|e|"%02x" % [e.to_i]}.join => "c26407e3" [2] pry(main)> '91.198.120.24'.split('.').map{|e|"%02x" % [e.to_i]}.join => "5bc67818"

I'm using boringly IPv4 addresses but I could have used anything. Unlike in PFC3 you do not need tell the location in the packet where the pattern must occur, you just tell pattern and any packet having that pattern anywhere is triggered, let's try it:

[email protected]> start shell pfe network tfeb0 TFEB platform (1000Mhz MPC 8544 processor, 1024MB memory, 512KB flash) TAZ-TBB-0(mec-pe1-re0.hel.fi vty)# test jnh 0 packet-via-dmem enable TAZ-TBB-0(mec-pe1-re0.hel.fi vty)# test jnh 0 packet-via-dmem capture 0x3 5bc67818c26407e3 TAZ-TBB-0(mec-pe1-re0.hel.fi vty)# test jnh 0 packet-via-dmem dump Received 116 byte parcel: Dispatch cookie: 0x0074000000000000 0x00 0x08 0x80 0xf0 0x80 0x08 0x5c 0x5e 0xab 0x0b 0x6e 0x60 0xb0 0xa8 0x6e 0x7c 0x60 0x52 0x88 0x47 Continue reading

1 … 3,750 3,751 3,752 3,753 3,754 … 3,841