When I left Solaris after the Sun/Oracle marger, it was because I wanted to try some new things in life possibly based on OpenSolaris. I had led Solaris in networking and network virtualization space for a long time and wanted to make a bigger mark in that space compared to what Oracle might have wanted. But my hope was that Solaris as a Open Source Operating System would continue to prosper and I could possibly use OpenSolaris as a base for whatever I decided to do next. Well, the exodus from Solaris has continued over the past few months and now Mike has also decided to call it quits. Mike was one of my counterparts, running the storage side of the house (other leaders in storage and filesystem space, like Jeff and Bryan had already bailed out of Solaris few months after I left).
So at this point, I am forced to consider the fact that Solaris and OpenSolaris are on the brink of death unless something serious is done about it. Having spent so much time and energy in last 15 years on Solaris (including bringing it back from life after the last tech bust when Solaris had been Continue reading
Very many large scale transit providers, if not most of them support eBGP remote triggered blackhole via separate multihop eBGP session. I suspect this is, because they've used for very long time single shared route-map for transit customers, and it is not immediately obvious how you can support blackholing without customer specific route-map. Requiring customer specific route-map would probably be less than minor change in their provisioning systems. However, it is perfectly doable and same idea works just the same in JunOS and IOS, here is pseudoIOShy example how to do it:
This is a response to Petr's well articulated discussion of LISP: "A High-Level overview of LISP"
He captured some of the key points that make LISP compelling, including the discussions about hierarchical routing (and associated problems with address allocations and multi-homing), the "level of indirection" enabled by LISP - due to the separation of host addresses (EIDs) and routing locators (RLOCs) - and the "push" vs. "pull" aspects of various mapping and routing systems.
There are a several areas that I think deserve greater explanation, however. The most important is regarding the LISP mapping system. "Core routing table size reduction" was the initial focus (and instigation) of LISP. But core routers are not the only ones taking full routes, some people might want the full routing table to be available on more places to have more granular control over egress traffic. Because BGP is a "push" technology, the FIB must be populated with full routes and be available in the "forwarding path" (data plane) of packets. This leads to the need for expensive silicon and memory on each line card. Where LISP helps is in two main areas. First, the LISP ALT routing table is decoupled from expensive Continue reading
One of the great promises of IPv6 has been to get rid of NAT, no more will IT do RFC1918 and NAPT to single public IP. But how is IPv6 going to accomplish this, what is the magical toggle for it? Let's get disappointed.
Some devices, like Cisco IOS allow you to configure IPv6 prefix as 'macro', so you could tell that macro 'ME' is 2001:db8::/32 and everywhere where you write IPv6 address, you use macro 'ME'instead. So in theory, when your prefix changes, you simply change the macro. So the great renumbering benefit is ability to always get same size network. But of course this was true for IPv4 too, you got the network size you needed. Why isn't this utilized? Because enterprises don't have one Cisco IOS devices, they have plethora of devices from different vendors, firewalls, slb, ips, ids, servers, OSS systems and so forth, you'd still need to go in all of these to change the 'macro', not all devices even have the concept and quite frankly no enterprise of non-trivial size will even know without months of work _where_ and _what_ will need to be changed for renumbering to be successful. I know industry professionals Continue reading