Showing posts with label Cisco. Show all posts
Showing posts with label Cisco. Show all posts

Thursday, June 5, 2008

IPv6 Hyperbole & Opportunities

A oft touted phrase for IPv6 is something to the effect of "an address for every grain of sand"[1]. I have a problem with this statement. It's one of those statements that is technically true but, in fact, untrue -- when used as the answer to the question which it is implied to be answering.

If IP addresses were simply assigned to devices and backbone routers were made aware of every single one it might be true. It's not. It's important to view IPv6 address space size in the right light because otherwise we can end up in some of the same troubles as the current IPv4 Internet. These troubles include not only overall available IP addresses but also routing of these IP addresses across network operator boundaries. After all, what's an IP address without global reach ability? :-)

The way that IP addressing works, there is a hierarchy. This hierarchy is used to group individual IP addresses into larger IP address blocks (known as "prefixes" and sometimes "subnets"). In the early days of IPv4 that was the Class A, B, and C system. While it was replaced with CIDR, the new system still maintained a hierarchy based on network size -- it was simply less rigid. This is still necessary in an IPv6 world.

The size of the protocol's address space -- and how it is broken up -- is of the utmost importance to routing. One of the greatest ironies of IPv4 address consumption is that multi-homing -- the connection to more than one upstream Internet provider for performance, cost, and reliability reasons -- requires an IP block of a particular size. Anything smaller than that accepted by the community (through rough consensus and subject to stragglers, mavericks, and router capacity improvements) and you can't multi-home.

In the IPv4 world this has resulted in waste of IP addresses -- which are never actually assigned to end-user devices -- so that someone can multi-home. It's also made it more difficult for smaller networks that want redundancy. Even if they end up with sufficient IP space, it is likely from one of their ISPs and not portable. If they were truly bigger (as in, if they actually were going to use all of those IP addresses) they'd be able to bypass their ISPs, getting IP space from one of the geographically appropriate pseudo-NGOs that allocate IP address space to larger IP address consumers.

Why all the fuss? Why not just allow anyone and everyone to inject any size block into the Internet routing tables? Because routers have finite resources. The larger the routing tables the more memory and CPU used for every packet pushed through the router. At some point a line is drawn where it is no longer generally accepted to be economically viable. This is where the generally accepted "smallest prefix we'll accept into our routing tables" policies come from. (generally the smallest acceptable block is an /24 in the present IPv4 world, approximately 254 assignable IP addresses for end-user devices).

One of the still active debates in IPv6 is how multi-homing will be performed in the long run. Will the current IPv4 model work? Or does the current model artificially restrict how many folks would actually multi-home if they could? Does the current system encourage too much address waste -- and is that even still a concern? How rapidly would the routing tables grow if a different approach were taken? How will we handle the additional resource burden of the continued co-existence of both IPv4 _and_ IPv6 routing tables for quite some time? etc

IP address portability is (indirectly) addressed in IPv6. That remains to be seen though. Under this model, smaller sites still won't necessarily have their own permanent globally routable IP address blocks. They'll have plenty of real global IP addresses assigned by their ISP now -- without any fuss -- but those IPs will still be controlled by their ISP (i.e. if they opt to change ISPs they will have to return 'em and get new ones from their new ISP). Switching IP address blocks is made (supposedly) easier though. The idea is that deeper auto-configuration is adopted with something akin to current DHCP on steroids used pretty much across the board along with very tight integration with DNS -- and somehow overcoming DNS caching.

I am not advocating against IPv6. On the contrary, for its successful widespread adoption I think that expectations must be set appropriately. And, any open for debate areas -- which don't have to hold back its adoption necessarily -- need to continue to be widely discussed. The more awareness the less that a new adopter is blindsided -- and thus the happier they'll be with the outcome after they proceed with their adoption efforts. And, more importantly, the faster that some more definite solutions / best practices can be better understood and disseminated.

As always, I welcome comments, including contesting any of my conclusions and assumptions above. Discussion and debate is how nearly all progress is made, whether it is with ones self or with others. :-)

[1] “One of the major advantages of the new Internet protocol (IPv6) is that it overcomes the growth problems of the Internet caused by the current limitations in the number of IP addresses needed for every computer or other device in order to access the Internet. The new protocol allows for a virtually unlimited number of (2^128) addresses – enough to assign an address to every grain of sand on all the world’s beaches.”

--“European Commission hosts inaugural event to celebrate the launch of the world's first all IPv6 research network,” Brussels, 14th January 2004

Wednesday, February 20, 2008

Understanding MPLS VPNs

If you are an enterprise user of carrier WAN offerings, it is likely you've been offered MPLS as a solution. Most carriers are encouraging customers to consider MPLS based services over traditional Frame Relay, ATM and even Point-to-Point transport.

One misconception is that consumers of MPLS carrier services must "run MPLS" within their own networks or at least on the edge device(s) connected to the carrier's MPLS service. This is not the case (unless you are doing something pretty unusual). Standard routers -- and even bridges -- are used on the customer-side. The configurations may be a bit different than you're used to but they're still relatively straightforward (and cookie cutter once you do one).

Your layer 1 and layer 2 skills will still come in handy. The underlying transport is still going to be TDM (DS1, OC-3c, etc). You may end up running a dynamic routing protocol (BGP, OSPF) with the carrier's network. If that's new territory, don't worry. This BGP configuration is far less elaborate than that needed to (prudently) bring up BGP for Internet multi-homing.

So even though the MPLS component will be outsourced to your carrier, to be an informed buyer and troubleshooter when shit-hits-the-fan, you'll want to understand the different ways that MPLS can be delivered and used by carriers to provide your service. When the carrier asks you to make some choices or you're evaluating a prospective solution, you're more likely to get what you need (and hopefully less of what you don't).

Jeff Doyle, the author of Routing TCP/IP Volume I and II (both 900+ pages each), has two quick articles about MPLS. In Part I, he covers the basics relevant to any MPLS user as to the different types of MPLS network options and in Part II he covers some of the nitty gritty relevant to service providers and those with an interest in what goes on behind the scenes.

P.S. I have some experience with WANs. Feel free to ask me questions. You can post a comment here or drop me an e-mail.


-jr

Wednesday, October 3, 2007

Digium (Asterisk) Is Sending Busy Signals

Digium, the commercial company behind the open-source Asterisk IP PBX, has been ultra busy of late. They came out with a self-contained hardware based Asterisk appliance targeted at developers, telephony carriers, etc. to build custom IP PBXes for their customer bases. They followed this with a full blown out-of-the-box installable hardware IP PBX appliance (the AA50) intended for the mass market. They bought SwitchVox, a leading IP PBX appliance vendor with some nice innovative user interface and functionality features, then announced a deal with 3Com who will be OEM'ing their appliance as the foundation of their IP PBX offering.

Digium, has been selling components, such as as cards to interface between the traditional phone network, development and support services for Asterisk, and commercial licenses for vendors OEM'ing Asterisk code into their own PBXes and other telephony applications for several years now. Now, it's time to get serious I guess.

Further Notable Links:

Friday, August 24, 2007

Getting a Network Lab on the Cheap

A network lab is useful for all sorts of things. Unfortunately really good labs can be expensive to put together. Over the years I've developed some alternatives that have worked well for many situations. This is still in informal draft format but I don't know when I'll next get a chance to clean it up. I think some folks may find it useful as is so I'm going ahead and posting it now.

Here are my strategies:

  • Emulators
    • There are Cisco hardware emulators that allow you to run IOS and PIX/ASA images. This has also been known to be possible with other vendors from time to time, sometimes officially offered by the vendor and sometimes not. I suggest a Google search for something like "vendor emulator".
      • Dynamips (Cisco hardware emulator that runs your provided IOS images for the 3800, 7200 and other platforms).
      • PEMU (Cisco 525 PIX hardware emulator that runs your provided PIX OS image)
      • Versions for Linux and Windows of the above
    • These emulators often run in their own VMs so, for example, it's possible to set up an entire lab of Cisco devices on a single laptop or desktop and have the emulated devices all "connected" to each other purely in software. e.g.
      • 2 x Cisco PIX 525 + 2 x 7200 NPE-400
      • ....on a 1.4Ghz Celeron laptop
    • Don't expect to do performance testing with emulators but they are often fully functional (the Cisco emulators run actual IOS and PIX images, whatever ones you provide) since you can build testbeds that closely resemble your actual network, including testing actual config changes, etc.
  • Vendor and reseller online accessible demo environments
    • These are nice for poking around and following along as you read through their manuals. Sometimes you can't change things but you can usually get as far as saving your changes -- which is good enough for many situations.
    • Can also be useful to see what newer versions of firmware look like, before you upgrade, since vendors usually keep their demo units up to date
    • Do Google searches for "myvendor demo", "myvendor demonstration", etc. e.g.
  • Quasi-Public looking glasses
    • Telnet reachable looking glasses / route servers / traceroute servers
    • Web-based
    • usually Cisco, Juniper, and some Zebra-based Linux/BSD boxes
    • Not as useful as other methods but sometimes can view live info you might not be able to simulate elsewhere such as large BGP tables
  • Rack rentals -- rented remote network lab racks (most often rented in 4-6 hour chunks, designed for folks studying for certifications such as CCIE)
    • as cheap as $10 for a 4 hour block (!!!)
    • check eBay for low cost rentals
    • check Google for others -- there are many so prices are pretty competitive
    • search for "CCIE rental" for Cisco rentals. Similar ones exist for Juniper and other vendors with certification programs.
    • since folks studying for higher end certifications, such as the CCIE, require pretty elaborate labs these "rack rentals" give you access to some incredibly large and higher-end equipment
  • Quasi-public environments (left open by accident? Sometimes folks leave their mgmt interfaces open intentionally, accidentally, or, hopefully, just the read-only modes)
    • When evaluating Axis cameras a while back, I did some Google searches and turned up a bunch of cameras left open to the public.
    • Hint: For web-based GUIs, figure out a unique portion of the text string that is usually in the HTML title and search for it using Google's "intitle:" command.
  • Try and Buy promotions
    • Many vendors, especially the smaller and more aggressive ones, are pretty open about letting folks try their products out for a month or so. Many times you can even talk 'em into holding onto them a little longer if you keep in touch with them, let them know you are evaluating for future purchase, etc.
    • Helps to have a business entity, be a "consultant" (state outright that you regularly recommend equipment to clients, if that's the case, since that peaks the interest of most sales folks). Even better is a tax reseller ID I suppose (I don't resell hardware so haven't taken advantage of this last bit before but I've been asked by sales folks when evaluating hardware who I imagine like to encourage new potential sales channels).
  • Purchasing standby spares
    • Spares bought to have for on-site swap-ins in the event of hardware failures can be used (carefully!) for lab work. Just be careful not to break, lose, or otherwise leave your spares in a state that hurts their real function.
  • Purchasing, borrowing, decommissioning lower-end but current enough models
    • Older models, that may or may not be end of sales status by the vendor, may be available cheaply. It's all about eBay.
    • Upgrading production devices and retaining the older models that get pulled for the lab (previously sunk cost, easier to justify over spending more $$$ on lab equipment)
    • A maintenance window for a non-critical office/PoP or during a time window (e.g., after 5pm, or 2am-6am or whatever) that is acceptable in your environment. Then temporarily doing the testing/evaluation/learning with this equipment before returning it back to production state. This isn't ideal but works better than "learning" on a more important part of your network at the same time you are intending to go live with the changes.
  • Out of date models that people are giving away
    • for some needs, "free" equipment can meet certain needs, especially when first learning about a new device when just getting the basic look and feel of the command line or GUI is the focus. Spend money only when you get a bit farther along -- after all many times projects get delayed mid-stream anyhow so why buy new lab equipment only to have it sit and collect dust for the next few months until you get around to working with it (and probably frustrating your boss who you convinced to spend money on it now rather than later).
  • Borrow from a colleague
    • Call your colleagues at other organizations. Often they've got some extra hardware sitting around that they are willing to lend.
    • If you break anything make sure you tell them upfront and replace it (been there done that, with an awful hardware problem in a modular router that, best as we could tell, took out one of the test chassis in addition to the problematic one due to some weird short on a removable module we pulled from the busted chassis to test in the known good chassis).
  • Borrowing under vendor hardware replacement and support contracts
    • If you have a current hardware replacement or support contract with your vendor, you can explain your particular situation and sometimes have them do you the favor of lending you equipment temporarily.
    • In a near-emergency, if you have an advanced hardware replacement contract, you can consider having a "failure" then sending the advanced sent hardware back when you're done with it. Don't abuse too much Might be acceptable under some circumstances. Make your own judgment.
  • Hosted x86 Virtual Machines
    • usually VMWare or Xen based (not that it matters much to the end-user)
    • can boot up various OSes on-demand, cheaply
    • some hosting companies will let you rent on short-term basis (e.g. Amazon EC2 Xen-based VMs charge by the hour and don't charge you while your VM is "shutdown/turned off")
    • Good for adding hosts to your test lab (nobody ever said a useful lab had to be physical)
    • Combined with network device emulators, discussed previously, makes it possible to do some crazy stuff
      • Want to simulate a 50 router nationwide network of Cisco 7200 class routers? Get a usage-based VM hosting account and install Dynamips.... It'll cost you something like $20 to get access to 50 VMs for four running hours via Amazon EC2
    • If you've got some real equipment you want combined with your virtualized equipment, remotely hosted x86 VMs, etc than build a VPN overlay to connect things up the way you want. The VPN can be an invisible transport layer for your lab network if you want or it can be part of the lab network itself.