0

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

0

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.

0

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.

0

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

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

0

How to ‘Sell’ IPv6 to Executive Management – Guidance for Engineers

 (aka ‘IPv6 for Managers for Network Engineers’) “Genius!”, the CEO says as he enters your office (ok more likely your cubicle or desk-space or whatever corner of the office you prefer to go hide out in to concentrate), “I’ve been … Continue reading →

0

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

The post Why Would A Vendor Care About Network Field Day Events? appeared first on Packet Pushers Podcast and was written by Ethan Banks.

0

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

0

Why do we need specialized switches in Data Centers?

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

0

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:

• the attack detection tool was coded to Continue reading

0

MAC Cloning on Linksys router for Internet connectivity

0

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

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.

0

OpenFlow, Controllers – Whats missing in Routing Protocols today?

There 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

0

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
——————-

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

0

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.

0

Rapid Spanning Tree and PortFast

0

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.

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

0

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

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.

0

Thoughts On Working As A Consultant For A VAR

One of the questions I’m frequently asked via e-mail is how to get started in networking and/or whether or not a particular job change is a good idea. Those are always hard questions to answer intelligently because everyone’s individual situation is different. In addition, everyone’s personality is different. Different jobs work for different people. It […]

Author information

The post Thoughts On Working As A Consultant For A VAR appeared first on Packet Pushers Podcast and was written by Ethan Banks.

0

Healthy Paranoia Show 10: Beware the Shmoo

Darkness falls across the land, The hacker hour is close at hand. Creatures crawl in search of 0-days To terrorize your enterprise. And whosoever shall be found, Without the soul for clamping down, Must stand and face the nerds of hell, And rot inside a clear text shell. The foulest stench is in the air, […]

Author information

The post Healthy Paranoia Show 10: Beware the Shmoo appeared first on Packet Pushers Podcast and was written by Mrs. Y.

0

A /64 On Every Link? Are You Crazy?

I’ve had some great conversations lately with a lot of folks on the topic of IPv6 prefix length in a variety of applications, specifically one very good discussion on just about anything IPv6 between me, the kind folks over at The Class-C Block and Tom Hollingworth (aka The Networking Nerd). For many folks that are considering the impact of going dual-stack in their environments, the idea of using a /64 on all links is still a point of contention.