Let me start by laying out this disclaimer: This is in no way intended to devalue or criticize any vendor or vendor neutral certified folks or programs. Since the mid-1990s I’ve done many certification programs. In fact, I’ve actually lost track and I can’t even remember them all, so this is not a commentary by someone […]
Dotfiles are all those . files that sit in your ~ and customize your system. Here are mine.
Dotfiles are all those . files that sit in your ~ and customize your system. Here are mine.
Until a few weeks ago I had no idea that people hosted their dotfiles on GitHub, and now I am one of them... There are two reasons for this:
To point 2, I've gone one step further than just including my dotfiles. I've also included all of my system customizations and installers for the packages I use most. Why a new repository and not a fork you might ask? The honest answer is that there wasn't one repo that fit my tastes well enough so I ended up taking what I considered to be the "best" elements from a number of other repos. This is still a work-in-progress and I am comitting changes every time I find somehting new and exciting, or tire of a specific setting.
.symlink are symlinked to the home folderBy now just about everyone has realized that OpenFlow is just vaporware. Technically, there was never any content behind the hype. The arguments used to promote OpenFlows revolutionary properties where simply the ignorance of all previous technologies that used the exact same design ideas from SS7 to PBB-TE.
Rumor has it that even the most religious OpenFlow supporters from Mountain View to Tokyo have realized that OpenFlow is pretty much dead. If you look back at it, it was a pretty silly set of assumptions to start with: that hardware design and not software the the limiting factor in network devices; and that you can define a low-level forwarding language based on the concept of a TCAM match that is going to be efficient across general purpose CPUs; ASICs and NPUs. Both assumptions can easily be proven to be false.
But OpenFlow’s promise was “too good to be true”. So a lot of people preferred to ignore any hard questions in search of the illusory promises of a revolution in networking. By now though, everyone gets it.
As an industry, what is the expected reaction to the OpenFlow hangover ? One would expect a more down-to-earth approach. Instead we get “Segment Continue reading
In one of my rants, I asked people to kindly stop with the "All Network Guys will Need to be Programmers" FUD. My recommendation was basically for Networkers to be open to change, and to start broadening their horizons. DevOps is coming to networking and that is a FACT. You might be wondering what skills a Network DevOps Engineer needs and here I attempt to answer that.
In one of my rants, I asked people to kindly stop with the "All Network Guys will Need to be Programmers" FUD. My recommendation was basically for Networkers to be open to change, and to start broadening their horizons. DevOps is coming to networking and that is a FACT. You might be wondering what skills a Network DevOps Engineer needs and here I attempt to answer that.
I'm going to state this upfront here. You need to be good at Networking for any of the other skills here to be useful. Continue along vendor certification tracks, follow the IETF, join NANOG, experiment with new technologies. This is all invaluable.
A lot of the DevOps skills have roots in Software Engineering. Being a Network Guy ™ this may seem like a little bit of a paradigm shift but here's something cool. Would you believe that some of these software engineering concepts have more to do with engineering best practice than with software, and are in fact relevant to the work you are doing today? Also, your SysAdmin buddies already know this and started their DevOps pilgrimage a while ago.
Unit/Functional/Integration Testing, Version Control, Agile, Continue reading
Selecting shapes and connectors one-by-one in Visio can be tedious, especially when working with large or repetitive drawings. If you've been drawing for a while, you've probably gotten the hang of selecting just the right subset of shapes using the rectangular select tool, and employing the control key to add or remove any outliers as desired. This can be time-consuming though, especially when you want to pick out just a few connectors from a jumble of criss-crossing lines.
Here's a trick to try next time you find yourself excessively control-clicking: Identify each logical group of shapes or connectors that you'll likely want to tweak, and bundle them up into to their own layer. You can then use Visio's "select by layer" option to grab them all at once later. Take the drawing below, for instance.
In one of my rants, I asked people to kindly stop with the "All Network Guys will Need to be Programmers" FUD. My recommendation was basically for Networkers to be open to change, and to start broadening their horizons. DevOps is coming to networking and that is a FACT. You might be wondering what skills a Network DevOps Engineer needs and here I attempt to answer that.
Dotfiles are all those . files that sit in your ~ and customize your system. Here are mine.
The final installment in this three part series. This covers installing Dokku and publishing your pelican blog to you new Docker-powere mini-Heroku.
The final installment in this three part series. This covers installing Dokku and publishing your pelican blog to you new Docker-powere mini-Heroku.
If you haven't read Part 1 or Part 2 yet, this should give you some background as to what I'm doing, why I'm doing it and how I built it. In this installment I'll focuse on the publishing side of things.
My former blog was hosted on a Linode 1024 VPS, which had a healthy 1GB RAM. I've been very happy with Linode and would recommend them to anybody who needs hosting, but for the convenience of having prebuild Ubuntu images with Dokku installed, I opted to host my blog with DigitalOcean. They have a full tutorial on their website that makes this very easy to set up.
One of the big benefits of using a static site generator is that the memory requirement is a lot less than Apache+PHP or Nginx+PHP. I'm hosting my site now on a $5/month VM from DigitalOcean which is a $15/month saving on my Wordpress site.
Once you have your Dokku installation set up, you can push your application to Continue reading
I'm using Cisco vocabulary 'glean' here as I don't know better word for it. Glean is any IPv4 packet which is going to connected host which is not resolved. It is NOT an ARP packet, so ARP policers won't help you. They are punted, since you need to generate ARP packet and try to resolve them.
In 7600 we can use 'mls rate-limit unicast cef glean 200 50' to limit how many packets per second are punted to control-plane for glean purposes. How can we limit this in JunOS? As far as I can see, there is no way. But I remember testing this attack and was unable to break MX80, so why didn't it break?
First let's check what does connected network look like
[email protected]> show route forwarding-table destination 62.236.255.179/32 table default Routing table: default.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif 62.236.255.0/24 intf 0 rslv 828 1 xe-0/0/0.42
Ok, fair enough. Type 'rslv', which we can guess means packet is punted to control-plane for resolving ARP. Let's try to ping some address rapidly which does not resolve and check what it looks like
Some HP L3 Switches Comware based, brings the concept of “switchports” as Bridge and Route mode.
The Bridge mode (port link-mode bridge) works the same way that any other access Switches.
When using Route mode (port link-mode route) the port is converted into a layer 3 interface, which need an IP address. All STP messages will be ignored.
Example
# interface GigabitEthernet4/0/1 port link-mode route ip address 192.168.1.1 255.255.255.0 # interface GigabitEthernet4/0/2 port link-mode bridge port link-type access port access vlan 2 #
Regards
In Parts 1, Part 2 and Part 3 we saw we can use the CEF table to express all sorts of different QoS policies. In Part 4 we describe how to attach a policy to the packet that will follow it around the network. Like many policies (security, shaping, etc.) it’s best to classify the […]
The post Secret CEF Attributes, Part 4 appeared first on Packet Pushers Podcast and was written by Dan Massameno.
Ladies and gentleman, unicorns of all ages, get ready for the greatest podcast on earth, Healthy Paranoia. Where the email is always encrypted and the firewalls are ever stateful. On this episode, we’ll be discussing Net Neutrality. Joining us is Sherry Lichtenberg, Principal for Telecommunications at the National Regulatory Research Institute; Andrew Gallo, network architect […]
The post Healthy Paranoia Show 22: The Three Ring Circus of Net Neutrality appeared first on Packet Pushers Podcast and was written by Mrs. Y.
Back in September 2013 I wrote a piece on why you would deploy VMware NSX with your Cisco UCS and Nexus gear. The gist being that NSX adds business agility, a rich set of virtual network services, and orders of magnitude better performance and scale to these existing platforms. The response to this piece was phenomenal with many people asking for more details on the how.
The choice is clear. To obtain a more agile IT infrastructure you can either:
To help you execute on choice #2, we decided to write a design guide that provides more technical details on how you would deploy VMware NSX for vSphere with Cisco UCS and Nexus 7000. In this guide we provide some basic hardware and software requirements and a design starting point. Then we walk you through how to prepare your infrastructure for NSX, how to design your host networking and bandwidth, how traffic flows, and Continue reading
Back in September 2013 I wrote a piece on why you would deploy VMware NSX with your Cisco UCS and Nexus gear. The gist being that NSX adds business agility, a rich set of virtual network services, and orders of magnitude better performance and scale to these existing platforms. The response to this piece was phenomenal with many people asking for more details on the how.
The choice is clear. To obtain a more agile IT infrastructure you can either:
To help you execute on choice #2, we decided to write a design guide that provides more technical details on how you would deploy VMware NSX for vSphere with Cisco UCS and Nexus 7000. In this guide we provide some basic hardware and software requirements and a design starting point. Then we walk you through how to prepare your infrastructure for NSX, how to design your host networking and bandwidth, how traffic flows, and Continue reading
Back in September 2013 I wrote a piece on why you would deploy VMware NSX with your Cisco UCS and Nexus gear. The gist being that NSX adds business agility, a rich set of virtual network services, and orders of magnitude better performance and scale to these existing platforms. The response to this piece was phenomenal with many people asking for more details on the how.
The choice is clear. To obtain a more agile IT infrastructure you can either:
To help you execute on choice #2, we decided to write a design guide that provides more technical details on how you would deploy VMware NSX for vSphere with Cisco UCS and Nexus 7000. In this guide we provide some basic hardware and software requirements and a design starting point. Then we walk you through how to prepare your infrastructure for NSX, how to design your host networking and bandwidth, how traffic flows, and Continue reading
