It’s been a long tradition around our house that I cook the Christmas dinner. I enjoy cooking but don’t get the time to do it as often as I would like; my wife does the great majority of day-to-day cooking, so she enjoys not having to cope with the Christmas feast. Read more
2008 was sort of a milestone year for IPv6. Foremost there was the much-touted US OMB Mandate which everyone got excited about back about 2005: By June of this year all federal agencies’ “infrastructure (network backbones) must be using IPv6 and agency networks must interface with this infrastructure.” In the years between that mandate and the deadline, however, the language and requirements slipped significantly. Read more
I picked up a G1 yesterday. It was a big step for me, because I’ve never really wanted a mobile phone that does more than make phone calls (and text messaging, since my teenagers seem to have lost the ability to communicate by any other means). When I was at Juniper, my boss and I fought a running battle for years: He wanted me to carry a Blackberry, and I didn’t want to be anywhere near that accessible. Read more
For all the harping I do on this blog about IPv4 address depletion and the need to prepare yourselves for IPv6, there is another number resource that is also being quickly depleted, and that I haven’t written about before: the 2-byte autonomous system numbers (ASNs). Read more
My last post talked about the need for enterprise network operators, even if they think they will not need IPv6 for their internal networks in the foreseeable future, to take into account their public-facing servers. Although there are few IPv6 users trying to reach those servers at present, their numbers will grow over the next few years. You need to be ready to serve them. Read more
If you have followed this blog for very long you know that I post pretty regularly (far too regularly, some might say) on the fast-approaching depletion of the remaining pool of public IPv4 addresses.
If you haven’t followed this blog before, I’ll give you the short version: Read more
“High availability” has been a technical and marketing buzzword for a number of years, and lately infrastructure equipment vendors have made “HA” a feature set. In that regard HA has come to mean a combination of hardware and software that reduces device downtime. In this age of “five nines” reliability and stringent Service Level Agreements, pretty much any downtime is unacceptable: If a device is out of service for more than about 315 seconds in a year, it is below the 99.999% threshold. Read more
In the previous post I discussed how the Internet influenced the American presidential election. (Okay, okay, how in my opinion it influenced the election.) In this post, I'd like to flip the discussion to how the Internet might be influenced by the newly elected administration.
Network World is already carrying several good articles along these lines. Scott Bradner's is particularly good. Read more
I debated whether to write this post at all. Doing so means letting some of my political views show, and I wasn’t sure whether that would be appropriate for this blog. But in the long run it’s really about the industry we all work in to one degree or another, so here goes… Read more
I wrote in the previous post that many network executives resist IPv6 deployment because they cannot find a means to make it profitable. This is a misguided viewpoint, because IPv6 is an infrastructure issue, not an applications issue. Read more
In the years of trying to convince network operators and executives of the urgency behind getting started on an IPv6 implementation plan, those resistant to the idea usually give me one or more of the following: Read more
My father died a couple of weeks ago. Although he was not suffering from a serious illness, it was not unexpected. He was 83, and for the past two years we had watched his body slowly running down. He knew this was coming.
On his last day, he felt fine. That evening he had a good dinner, listened to one of his books on tape (his eyes were among the things that had failed him recently), went to bed and went to sleep. And just… stopped.
No one could hope for an easier exit. Read more
The posts I’ve done about JUNOS so far all have to do with a single theme: Reducing operational risk. The features I like about JUNOS are the features that help me avoid screwing up a configuration. As I’ve said in past posts and undoubtedly will say many times again, the biggest cause of network outages is not hardware or software failures, it’s folks making configuration changes.
As a general practice, insuring that every configuration on every router in your network follows a standard configuration policy will reduce errors. What that policy is can vary from one network to another, but a consistent and enforceable policy within the network means that everyone configuring a router knows the rules for creating the configuration. Everyone troubleshooting the network knows what information to expect to find in any configuration.
In the previous post I wrote about how you can create a custom script that runs checks on a JUNOS candidate configuration when the commit command is issued, and prevents the configuration from becoming active if the script finds something out of spec. It’s a great tool for insuring that every configuration is in compliance with the standards you define for your network.
Another potential source of variation and mistakes happens when a relatively long set of configuration statements must be created for a single function. Setting up a single MPLS VPN instance, for example, or a single BGP peer group, can involve quite a few statements. This is where JUNOS macros can help. Read more
A macro is a script, but it does more than error checking. It can take relatively simple input and write a complete configuration for you.
Previous posts have shown you how to maneuver around within the JUNOS configuration hierarchy, and how it checks for correct syntax every time you hit the space bar as you're entering a configuration line.
But there are times when you can enter all the individual lines of a configuration correctly, and the configuration can still be wrong. That is, the combination of commands do not work correctly together or there's something missing among the lines. Read more
I discussed in the previous post how candidate configurations, explicit commits, and rollbacks greatly increase the reliability of configuration changes in JUNOS and reduce the risk of configuration mistakes. Heaven knows if there is a mistake to be made, I'm likely to make it.
Another nice feature for klutzy typists such as myself is that rather than waiting until you hit return at the end of a configuration statement to check for syntax errors, JUNOS checks syntax word-by-word – that is, every time you enter a word into a line and hit the space bar, it checks the syntax. Read more
One of my longtime gripes about IOS is that when you type a new statement to the CLI and hit return, the statement immediately becomes active on the router. For someone as mistake-prone as me, this is a big risk. And given that the majority of network problems are due to human error rather than hardware and software failures, it is a risk for everyone.
This can also be a problem when you’re making extensive configuration changes. Having those changes take effect one statement at a time can introduce all sorts of transient conditions.
The Candidate Configuration and Explicit Commits Read more
In the previous post on JUNOS I gave you a brief overview of the software architecture, with a particular emphasis on modularity. In this post, we'll have a first look at maneuvering around within a JUNOS configuration file.
The JUNOS configuration file is well organized in a hierarchical structure; once you understand that structure and its various levels, it's easy to navigate the file and find exactly the parts you want to examine or change without being distracted by parts you are not interested in at the moment.
To begin, I log into the router: Read more
Most anyone that considers IPv6 implementation and proposes implementation solutions looks at it in terms of IPv4/IPv6 coexistence. When the IPv6-capable devices in a network are dual stacked, coexistence is relatively simple: The dual stack devices can speak to both IPv4-only and IPv6-only devices. The problem with dual stacks is that they require both an IPv4 and an IPv6 address, and that misses the fundamental point that we’re deploying IPv6 because we are quickly approaching a time when IPv4 addresses are no longer available. Dual stacking would have been the right approach to transition five years ago, but it is less and less viable as new IPv4 addresses become unavailable. Read more
In the previous post I gave you the briefest insight into the JUNOS software architecture by telling you that its kernel is based on FreeBSD. Juniper developers start turning a FreeBSD kernel into a JUNOS kernel by reviewing the FreeBSD code line-by-line, removing all unwanted components and drivers. Some of the code is rewritten to match internal Juniper style guidelines, and the code is commented as needed. Juniper-specific “hooks” are then added. Read more
I suppose it seems odd to start a few posts about Juniper Networks’ JUNOS on a blog that’s part of what Network World very prominently labels “Cisco Subnet.” But most of the bloggers here attend at least in part to helping their readers work toward industry certifications, advance their technical knowledge, and become more aware of industry issues.
Here’s why I think it’s important for you to have at least a passing familiarity with JUNOS: Read more
Jeff Doyle is president of Jeff Doyle and Associates, an IP network consultancy. Jeff is the author of Routing TCP/IP, Volumes I (read an excerpt) and II and of OSPF and IS-IS: Choosing an IGP for Large-Scale Networks. He is a frequent speaker on IPv6, MPLS, and large-scale routing.
The opinions expressed in this Weblog are those of the writer and may not represent the opinions of Network World.
|
|
