How Could MTU affect BGP Sessions ?
This post represents the solution and explanation for quiz-18.
It presents different MTU values, summarizes Path MTU Discovery and gives solutions to the quiz presented a while ago.
Please Fill Out Our 2014 Audience Survey
Packet Pushers is a big part of Greg’s & Ethan’s lives and the show is continuing to grow in 2014. We learn a lot, laugh a lot, and work hard to bring you the show every week and fresh content on the blog site. Despite enjoying editing and writing along with producing the podcast, the […]
Author information
The post Please Fill Out Our 2014 Audience Survey appeared first on Packet Pushers Podcast and was written by Ethan Banks.
Install Open vSwitch Networking on Red Hat Fedora 20
The following tutorial will bootstrap you in installing and configuring Open vSwitch on Red Hat Fedora 20. It also has some extras that are just general Fedora configuration tasks such as setting up networking along with Wireshark over an X11 ssh session. This is the first of lots of integration posts over the next year as we develop network virtualization ......
BGP Path Hunting/Exploration
Only one change or link flap can cause one hour or more traffic drop. It is weird, right? But this is true. In this article BGP Path Hunting/ Path Exploration behavior will be shown, BGP route flap dampening and its variants will be explained and how only one interface flap can cause very long down […]
Author information
The post BGP Path Hunting/Exploration appeared first on Packet Pushers Podcast and was written by Orhan Ergun.
Show 176 – Intro to Python & Automation for Network Engineers
Network engineers keep hearing about Software Defined Networking (SDN) and wonder, “Will I have to become a programmer to keep my job?” The answer is, “Probably not.” However, there’s still an awful lot to be said for network engineers becoming familiar with the tools of network automation. There’s a gain in productivity to be had […]
Author information
The post Show 176 – Intro to Python & Automation for Network Engineers appeared first on Packet Pushers Podcast and was written by Ethan Banks.
[Storage Flow Control] Part 2 – Implementation and Troubleshooting
This will be a short follow-up to my last post about the idea of Flow Control in storage protocols. As a review, the three main options in common use today are: IP Storage - uses TCP windowing to provide feedback to client on how much data to send Native Fibre Channel - uses buffer credits (typically on a hop-by-hop basis when using N_port to F_port) FCoE - uses Priority Flow Control to define a class of service on which to send Ethernet PAUSE frames to manage congestion The last item is really the only one that warrants any kind of configuration, as the first two are more or less baked into the protocol stacks.OpenDaylight Summit 2014
I will be at the OpenDaylight Summit in Santa Clara on February 4th and 5th. To me, OpenDaylight represents a platform on which we can test SDN ideas today, right here, and right now. In my day job I may never be called upon to help deploy OpenDaylight (here’s hoping!) but nonetheless, it’s projects like this where the best and the brightest come together to share ideas and help to form the technology that the industry will be using for the next few decades.[Storage Flow Control] Part 2 – Implementation and Troubleshooting
This will be a short follow-up to my last post about the idea of Flow Control in storage protocols. As a review, the three main options in common use today are: IP Storage - uses TCP windowing to provide feedback to client on how much data to send Native Fibre Channel - uses buffer credits (typically on a hop-by-hop basis when using N_port to F_port) FCoE - uses Priority Flow Control to define a class of service on which to send Ethernet PAUSE frames to manage congestion The last item is really the only one that warrants any kind of configuration, as the first two are more or less baked into the protocol stacks.[Storage Flow Control] Part 2 – Implementation and Troubleshooting
This will be a short follow-up to my last post about the idea of Flow Control in storage protocols. As a review, the three main options in common use today are: IP Storage - uses TCP windowing to provide feedback to client on how much data to send Native Fibre Channel - uses buffer credits (typically on a hop-by-hop basis when using N_port to F_port) FCoE - uses Priority Flow Control to define a class of service on which to send Ethernet PAUSE frames to manage congestion The last item is really the only one that warrants any kind of configuration, as the first two are more or less baked into the protocol stacks.OpenDaylight Summit 2014
I will be at the OpenDaylight Summit in Santa Clara on February 4th and 5th. To me, OpenDaylight represents a platform on which we can test SDN ideas today, right here, and right now. In my day job I may never be called upon to help deploy OpenDaylight (here’s hoping!) but nonetheless, it’s projects like this where the best and the brightest come together to share ideas and help to form the technology that the industry will be using for the next few decades.SDN 2014 – Make Our Garden Grow – Part 1
Let dreamers dream what worlds they please Those Edens can’t be found The sweetest flowers The fairest trees Are grown in solid ground We’re neither pure nor wise nor good We’ll do the best we know We’ll build our house and chop our wood And make our garden grow And make our garden grow These […]
Author information
The post SDN 2014 – Make Our Garden Grow – Part 1 appeared first on Packet Pushers Podcast and was written by Steven Iveson.
Why Network Engineers Should Learn Programming
Because Microsoft Excel is not a text editor. Seriously.This is a followup to the previous post, inspired by Ethan Banks of Packet Pushers. If you do operational networking at all, you deal with text files all the time: logs, debug output, configuration files, command line diagnostics, and more. I'm constantly amazed when I see people open Word or Excel to do their text editing, often one keystroke at a time.
The number one reason to learn basic programming is to automate that stuff. Personally, I use a combination of traditional Unix shell tools and Python to get the job done, but you could probably do it all with one or the other.
There are lots of other reasons to learn programming too, many of which will be discussed on an upcoming Packet Pushers episode. But if you don't believe any of those, this one alone makes it worth the effort.
Step away from the spreadsheet. Do it now.
Why Network Engineers Should Learn Programming
Because Microsoft Excel is not a text editor. Seriously.This is a followup to the previous post, inspired by Ethan Banks of Packet Pushers. If you do operational networking at all, you deal with text files all the time: logs, debug output, configuration files, command line diagnostics, and more. I'm constantly amazed when I see people open Word or Excel to do their text editing, often one keystroke at a time.
The number one reason to learn basic programming is to automate that stuff. Personally, I use a combination of traditional Unix shell tools and Python to get the job done, but you could probably do it all with one or the other.
There are lots of other reasons to learn programming too, many of which will be discussed on an upcoming Packet Pushers episode. But if you don't believe any of those, this one alone makes it worth the effort.
Step away from the spreadsheet. Do it now.
“VIF down” Issues with UCSM 2.2(1b)
Sadly, this will be another post regarding issues I’ve had with UCSM firmware release 2.2(1b). During the upgrade process, I experienced a lot of issues with data plane connectivity - after I activated (and subsequently rebooted) a Fabric Interconnect, and it came up with the new NXOS version, a slew of blades would have persistent errors regarding virtual interfaces (VIFs) that wouldn’t come back online. Here is the error report for a single blade where I was seeing these errors:“VIF down” Issues with UCSM 2.2(1b)
Sadly, this will be another post regarding issues I’ve had with UCSM firmware release 2.2(1b). During the upgrade process, I experienced a lot of issues with data plane connectivity - after I activated (and subsequently rebooted) a Fabric Interconnect, and it came up with the new NXOS version, a slew of blades would have persistent errors regarding virtual interfaces (VIFs) that wouldn’t come back online. Here is the error report for a single blade where I was seeing these errors:Super Easy Twitter Bots
Super Easy Twitter Bots
I often get really quite mad ideas on writing twitter bots, But I often get pretty bored of doing all of the boiler plate that is required when wanting to achieve these things.
The typical process to making a twitter bot
Cisco UCS – “Unable to Communicate With UCSM Controller”
When upgrading UCS firmware, it’s important to periodically check the state of the HA clustering service running between the two Fabric Interconnects. The infrastructure portions of UCS are generally redundant due to these two FIs but only if the clustering service has converged - so it’s important to use the “show cluster state” command to verify this is the case. During a firmware upgrade to 2.2(1b), I checked this: 6296FAB-A# connect local-mgmt 6296FAB-A(local-mgmt)# show cluster state Cluster Id: 8048cd6e-5d54-11e3-b36c-002a6a499d04 Unable to communicate with UCSM controller The error message - “unable to communicate with UCSM controller” worried me, and it was given when I ran the “show cluster state” command as well as the “cluster lead” command - the latter of which is necessary to switch an FI’s role in the cluster from subordinate to primary.Cisco UCS – “Unable to Communicate With UCSM Controller”
When upgrading UCS firmware, it’s important to periodically check the state of the HA clustering service running between the two Fabric Interconnects. The infrastructure portions of UCS are generally redundant due to these two FIs but only if the clustering service has converged - so it’s important to use the “show cluster state” command to verify this is the case. During a firmware upgrade to 2.2(1b), I checked this: 6296FAB-A# connect local-mgmt 6296FAB-A(local-mgmt)# show cluster state Cluster Id: 8048cd6e-5d54-11e3-b36c-002a6a499d04 Unable to communicate with UCSM controller The error message - “unable to communicate with UCSM controller” worried me, and it was given when I ran the “show cluster state” command as well as the “cluster lead” command - the latter of which is necessary to switch an FI’s role in the cluster from subordinate to primary.Cisco UCS – “Unable to Communicate With UCSM Controller”
When upgrading UCS firmware, it’s important to periodically check the state of the HA clustering service running between the two Fabric Interconnects. The infrastructure portions of UCS are generally redundant due to these two FIs but only if the clustering service has converged - so it’s important to use the “show cluster state” command to verify this is the case. During a firmware upgrade to 2.2(1b), I checked this: 6296FAB-A# connect local-mgmt 6296FAB-A(local-mgmt)# show cluster state Cluster Id: 8048cd6e-5d54-11e3-b36c-002a6a499d04 Unable to communicate with UCSM controller The error message - “unable to communicate with UCSM controller” worried me, and it was given when I ran the “show cluster state” command as well as the “cluster lead” command - the latter of which is necessary to switch an FI’s role in the cluster from subordinate to primary.Farewell to Networking
Almost twenty years ago, I began my career in networking. HP hubs and routers, no VLANs, one router PHY port per subnet. From there I installed an ATM backbone using LANE in the venerable Catalyst 5500 platform, then moved on to GigE in 3750 stacks and finally to 10G Nexuses (Nexa, Nexi?). I’ve seen WiFi […]
Author information
The post Farewell to Networking appeared first on Packet Pushers Podcast and was written by Matthew Mengel.