Show 139 – Making Your Way Down The Path To Nirvana

Regular hosts Greg Ferro & Ethan Banks are joined by Brandon Carroll, Josh O’Brien, and Tom Hollingsworth in Packet Pushers Weekly Show 139. We translate all the SDN hype into a more practical conversation about what network engineers should be doing to update their skills. This is a mostly raw podcast with little editing – just […]

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 3M 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 139 – Making Your Way Down The Path To Nirvana appeared first on Packet Pushers Podcast and was written by Ethan Banks.

Quick Tip: Improvised File Transfer

The Python module "SimpleHTTPServer" is traditionally a quick and dirty way to test web code without the overhead of installing a full webserver. You can also use it as a quick way to transfer files between systems, if you have Python available:

jswan@ubuntu:~$ python -m SimpleHTTPServer 8080
Serving HTTP on 0.0.0.0 port 8080 ...

This causes Python to make all the files in the current directory available over HTTP on port 8080. From the client system, you can then use a browser, curl, or wget to transfer the file.

No, it's not secure, and yes, it may violate data exfiltration policies (and as an aside, Bro detects this by default). But I've used it fairly often to move files between Windows and Mac or Linux in situations where SCP isn't available and I don't feel like setting up a fileshare.

I've also used this in conjunction with the "time" command to test the effects of latency on various network protocols, and as an improvised way to test WAN optimization software.


Rambling on about IP fragmentation

Fragmentation! Squarely on-topic for this blog, I guess.

An issue on a customer's network had me thinking about IP fragmentation recently, and now I find myself pounding some things that I find interesting about fragmentation into my keyboard.

Where should an oversized datagram be sliced?
RFC791 suggests a scheme by which an IP datagram is sliced up so that the resulting fragments just fit out the constraining interface. This seems sensible, but there are some gotchas:
  • If we fragment a 1500 byte packet to fit into a PPPoE link, we might wind up with 1492 bytes in the first datagram (20 bytes header, 1472 bytes payload) and 28 bytes in the second packet (20 bytes header, 8 bytes payload). This works great until that first fragment tries to transit a GRE tunnel (MTU 1476) further along its path. If the PPPoE router had chopped the datagram in half, both fragments would fit through the GRE tunnel without any problem.
  • Depending on the MTU, we might not be able to make precisely MTU-sized fragments. This is because the fragment offset value in the IP header is expressed in terms of 8-byte chunks. Every IP fragment must have an offset that's a multiple Continue reading

Network Field Day 5

Yesterday kicked off the 5th iteration of Network Field Day. For those that haven’t heard of Tech Field Day, you need to check it out - there’s something for everyone, and it’s a great event that gets the technical details from vendors on their solutions. The delegates that are invited are what I consider thought leaders in each field. I’ve had the privileged of blogging, podcasting, and even meeting with them in person over the past few years, and they’re just the right kind of folks to help keep these vendors honest.

Network Field Day 5

Yesterday kicked off the 5th iteration of Network Field Day. For those that haven’t heard of Tech Field Day, you need to check it out - there’s something for everyone, and it’s a great event that gets the technical details from vendors on their solutions. The delegates that are invited are what I consider thought leaders in each field. I’ve had the privileged of blogging, podcasting, and even meeting with them in person over the past few years, and they’re just the right kind of folks to help keep these vendors honest.

Extracting The Most Value From Network Vendor Presentations

Vendors love nothing more than getting in front of their customers and talking about their products. You’ll always learn something from a presentation, but mostly they are an exercise in death-by-powerpoint. In this post, I’ll provide some some tips on getting the most from your time in these presentations. Vendor presentations can be really informative […]

Author information

John Harrington

John is an experienced data center engineer with a background in mobile telecoms. He works as a network test engineer for a large cloud service provider, and is gradually accepting that he's a nerd. He blogs about network technology and careers at theNetworkSherpa.com. You can reach him on twitter at: @networksherpa

The post Extracting The Most Value From Network Vendor Presentations appeared first on Packet Pushers Podcast and was written by John Harrington.

Why Would A Vendor Care About Network Field Day Events?

I’m in San Jose, California as a member of the Network Field Day 5 delegation this week. NFD is under the Tech Field Day umbrella of events, and is not a Packet Pushers event as such – although we’ve been a part of them, and Greg in particular has helped to organize some of them. […]

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 3M 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 Why Would A Vendor Care About Network Field Day Events? appeared first on Packet Pushers Podcast and was written by Ethan Banks.

What did West Virginia officials buy exactly?

The state of West Virginia has landed in the headlines a couple of times recently due to their purchase of wildly inappropriate Cisco routers for over 1000 locations around the state. There have been no shortage of commenters laying the blame at Cisco's feet, but the auditor's report disagrees. It's back in the headlines now because of the recent release of the report, and because of Cisco's pledge to buy the gear back and help the state buy more appropriate equipment.

The auditor's report is an interesting read. Here are some of the highlights from my reading of it:

3945 routers were selected because of two key requirements communicated by the state:

  • Dual internal power supplies, which narrows the selection to 3925 and 3945 models
  • Use of two service module slots on day one, and a desire to have the option to grow beyond these two at some point in the future.

Unfortunately, these two requirements seem to have been communicated in a meeting, because no emails were available to corroborate them, but members of the team who purchased the gear acknowledge that the requirement did originate with the state. So, that's how they wound up in a 3945 chassis.

Continue reading

Why do we need specialized switches in Data Centers?

data center

Whats the big deal about Data centers and why do they need special routers and switches anyway? Why cant they use the existing switches that folks use in their back offices or service providers in their networks. What’s so special, really, about a bunch of servers that need Internet connectivity, huh?

Working in the metro Ethernet space all my life I wasn’t sure if I really understood the hype and the reason why Data centers required specialized HW.

It’s only once I started reading about Data centers and how they work and what they’re supposed to do that I was able to appreciate their need for specialized HW – and why the existing products may not be cut for them.

In the world of Wall Street, milliseconds can mean billions of dollars. Really, am not kidding here. Packets carrying Wall Street transactions get delivered to the switch and are then forwarded to the server in the Data Center. There they ride up the protocol stack to the application that executes the trade. The commit message then has to go back down the stack and then be sent over the wire to the switch. The switch does a lookup in its Continue reading

An Operational Reason for Knowing Trivia

I've been largely out of touch with the IT certification scene lately, but I'm sure that people are still complaining incessantly about the fact that they need to memorize "trivia" in order to pass certification tests. Back when I was teaching Cisco classes full-time, my certification-oriented students were particularly bitter about this. Of course, this is a legitimate debate and the definition of "trivia" varies from person to person.

When I saw this article about CloudFlare's world-wide router meltdown, however, I immediately felt a bit smug about all those hours spent learning and teaching about packet-level trivia. If you don't want to read the article, here's the tl;dr:

  • their automated DDoS detection tool detected an attack against a customer using packets sized in the 99,000 byte range.
  • their ops staff pushed rules to their routers to drop those packets
  • their routers crashed and burned
So at this point you should be saying what some of the commenters did: huh? IP packets have a maximum size of 65,536 bytes, because the length field is 16 bits long.

In order for this meltdown to happen, they had to have a compounded series of errors:

MAC Cloning on Linksys router for Internet connectivity


When you start an Xfinity (Comcast) Internet service, the activation process involves plugging in your service provider provided modem's cable port to a cable outlet, and the connecting the modem's ethernet port to your laptop. You see the green blinking lights for RX/TX and a steady green light for Internet. 

However, if you connect the modem's ethernet port to a wireless router (Linksys E2000 in my case), assuming you have correctly configured all LAN settings, wifi settings, you may still not be able to connect to the Internet. 

Log in to the router's admin page, typically http://192.168.1.1, with username admin and password admin (again, unless you have changed these default settings). Go to the status page and notice the IP address. What you'll see is a '0.0.0.0' IP Address for the router's Internet connection.

I tried everything to get a public IP (from Comcast's range) here. Then I read Comcast's documentation which says connect a laptop to the ethernet port on the modem. Well, what's so special about a laptop which a router can't do?

Not always, but some times Comcast's modem expects a laptop on the other end of the ethernet Continue reading

Show 138 – HP’s Software-Defined Networking (SDN) Strategy and Solution

Show 138 – HP’s Software-Defined Networking (SDN) Strategy and Solution [Written by HP.] There has been a lot of interest in the market place recently around software-defined Networking (SDN). HP has been a leader in SDN technologies from the very beginning. HP has played an instrumental role in the development of OpenFlow and continues 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 3M 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 138 – HP’s Software-Defined Networking (SDN) Strategy and Solution appeared first on Packet Pushers Podcast and was written by Ethan Banks.

OpenFlow, Controllers – Whats missing in Routing Protocols today?

openflowThere is a lot of hype around OpenFlow as a technology and as a protocol these days. Few envision this to be the most exciting innovation in the networking industry after the vaccum tubes, diodes and transistors were miniaturized to form integrated circuits.  This is obviously an exaggeration, but you get the drift, right?

The idea in itself is quite radical. It changes the classical IP forwarding model from one where all decisions are distributed to one where there is a centralized beast – the controller – that takes the forwarding decisions and pushes that state to all the devices (could be routers, switches, WiFi access points, remote access devices such as CPEs) in the network.

Before we get into the details, let’s look at the main components – the Management, Control and the Forwarding (Data) plane – of a networking device. The Management plane is used to manage (CLI, loading firmware, etc) and monitor the device through its connection to the network and also coordinates functions between the Control and the Forwarding plane. Examples of protocols processed in the management plane are SNMP, Telnet, HTTP, Secure HTTP (HTTPS), and SSH.

The Forwarding plane is responsible for forwarding frames Continue reading

Q-in-Q

Q-in-Q
——-
Consider a situation where service providers want to offer transparent LAN services that preserve a customers VLAN tags across your Layer-2 network.This can be done by the Q-in-Q IEEE 802.1q standard which allows us to use a single VLAN to transport multiple VLANS across the MAN or WAN. In doing so, we stack on an extra 802.1q tag to the customer’s traffic at the provider’s edge (PE). The original 802.1Q specificationallows a single VLAN header to be inserted into an Ethernet frame.A port configured to support 802.1Q tunneling is called a tunnel port. When you configure tunneling, you assign a tunnel port to a VLAN that is dedicated to tunneling. Each customer requires a separate VLAN, but that VLAN supports all of the customer’s VLANs.

How It works
——————-

qinq&

Referece pic: Cisco Site

Customer Edge1——(802.1Q Trunk port having cutomer Vlan Ids)

                                 V
                                 V
                                 V

Service Provider edge switch1 —-(Packets entering the tunnel port on the service-provider edge switch, which are already 802.1Q-tagged with the appropriate VLAN IDs, are encapsulated with another layer of an 802.1Q tag that contains a VLAN ID unique to the customer).

Continue reading

Creating a CCNA Voice Lab

I've been working on something that at this point in my career I never thought I'd be doing: another Cisco Certified Network Associate (CCNA) certification. The CCNA Voice, to be exact. Now that I'm in a job role where I'm expected to be somewhat of a jack-of-all-trades, I can no longer avoid learning voice :-) For a long time I've focused on just the underlying network bits and left the voice “stuff” to others. Since I now need to talk intelligently about Cisco voice solutions, products, and architectures, I decided to go through the CCNA Voice curriculum as a way to establish some foundational knowledge.

This post is about the tools and methods I used to build a small lab to support my studies.

Rapid Spanning Tree and PortFast


PortFast is a feature enabled on switchports, specifically 'edge' ports that reduces convergence time by transitioning to forwarding state quickly bypassing 30 seconds of listening and learning. When you connect an end device like a PC, server, phone etc, the switchport almost instantly starts forwarding frames.

PortFast also suppresses TCN BPDUs (Topology Change Notification Bridge Protocol Data Units). However, it sends BPDUs and actively participates in the STP topology mechanism. 

Why would one want an edge port to send BPDUs? Well, if you 'accidentally' connect a switch (managed or unmanaged) to an edge port configured with PortFast, that switch needs to know it is connected to a switch. 

If this port were to receive a BPDU, it would lose its PortFast status and transition to a normal STP port. This could be dangerous. You would want to block this port and prevent a loop from occurring. 

In order to accomplish the above, PortFast must be configured in conjunction with BPDUGuard. If a port configured with PortFast BPDUGuard receives a BPDU, it disables the port. The switchport moves into error-disabled state. And you need to manually shut and no shut the port to bring it back up, although Continue reading

The VAR-y good upsides to being a consultant!

Earlier today Ethan Banks wrote a really good blog posts about “Thoughts on Working as a Consultant for a VAR“. I found his point of view quite interesting and I will say I can understand his points. I can also say that I would rather be a consultant than a full time engineer at a customer site. As a little bit of background I have spent most of my career working as a consultant. I did do a two year stint as network operations manager for a wireless ISP which itself was quite fast paced, but other than that Ive work as a consultant in one form or another.

consultant_Problem

Maybe I have ADD, maybe I just need to focus, but I have found that constantly having different projects going allows me to satisfy these tendencies. I feel I work better with more than one thing to occupy my time. I see friends who work for enterprise customers who spend their days submitting change requests that third party support companies fulfil, or spend months writing detailed design guides for projects that inevitably get canceled and all that time is spent without getting to touch the things they got into this Continue reading

My First Junos Switch: Detailed Review After Three Days Under The Covers

Background This post is the story of my first practical look at Junos on Juniper EX-series switches. One day last December, Skeeve Stevens from eintellego opened a can of worms by offering a deal on Juniper equipment to all network engineers on the AusNOG mailing list. I had been looking for an excuse to try […]

Author information

Paul Gear

Paul is a freelance consultant working in Linux system administration, virtualisation, programming, and networking. When not working, he can often be found enjoying the surf near his home on Australia's Sunshine Coast.

The post My First Junos Switch: Detailed Review After Three Days Under The Covers appeared first on Packet Pushers Podcast and was written by Paul Gear.