Last week I described the problems high-end service provider routers (or layer-3 switches if you prefer that terminology) face when they have to update large number of entries in the forwarding tables (FIBs). Will these problems go away when we introduce OpenFlow into our networks? Absolutely not, OpenFlow is just another mechanism to download forwarding entries (this time from an external controller) not a laws-of-physics-changing miracle.
One of my Twitter friends sent me this question: “Would you honestly recommend your webinar subscription for a young CCIE that knows how routing works but have no real world experience and is a noob in DC/VM/NXOS?” That sounds like a perfect audience to me – I usually assume the attendees have mastered the fundamentals of networking/routing but don’t know much about the topics of the webinar (the whole idea of my webinars is to help you get started in new technology areas).
Most interesting article in this batch: Ethernet Taps - Don't Get Me Started by Chris Marget, focusing on Ethernet taps: passive, active, aggregators, L1 switches ...
And here are the other interesting links I found in somewhat random order:
Did you rush to try OSPF Loop Free Alternate on a Cisco 7200 after reading my LFA blog post ... and disappointedly discovered that it only works on Cisco 7600? The reason is simple: while LFA does add feasible-successor-like behavior to OSPF, its primary mission is to improve RIB-to-FIB convergence time.
Assume we have a simple triangular network:
Now imagine the A-to-C link fails. How will OSPF react to the link failure as compared to EIGRP? Which one will converge faster? Try to answer the questions before pressing the Read more link ;)
Scott Lowe asked a very good question in his Technology Short Take #20:
VXLAN uses UDP for its encapsulation. What about dropped packets, lack of sequencing, etc., that is possible with UDP? What impact is that going to have on the “inner protocol” that’s wrapped inside the VXLAN UDP packets? Or is this not an issue in modern networks any longer?
Short answer: No problem.
In the Redundant DMVPN Design, Part 1 I described the options you have when you want to connect non-redundant spokes to more than one hub. In this article, we’ll go a step further and design hub and spoke sites with multiple uplinks.
Public IP addressing
Fact: DMVPN tunnel endpoints have to use public IP addresses or the hub/spoke routers wouldn’t be able to send GRE/IPsec packets across the public backbone.
One of my readers couldn’t figure out which IPv6 webinar to buy. He wrote:
I bought your Service Provider IPv6 Introduction webinar. I’m also interested in Building IPv6 Service Provider Core and Building Large IPv6 Access Networks. I realized that the second training is not released yet and it says that it's an update session for the first training, so do I need to buy both? I would like to download all the material related to the trainings so I would watch them whenever I need.
It seems I did overcomplicate a few things, so I’ll try to clear up the confusion I created.
According to Google Analytics these were the most popular posts I wrote in December 2011:
- Is NAT a security feature?
- Decouple virtual networking from the physical world
- Large-scale L2 DCI: a true story
- We just might need NAT66
- VMware vSwitch – the baseline of simplicity
- Junos Day One: MPLS Behind The Scenes
- VXLAN, IP multicast, OpenFlow and control planes
- Which virtual networking technology should I use?
- Nexus 1000V and vMotion
- IPv6 multihoming without NAT: the problem
- VM-aware Networking Improves IaaS Cloud Scalability
It’s hard for me to admit, but there just might be a corner use case for split subnets and inter-DC bridging: even if you move a cold VM between data centers in a controlled disaster avoidance process (moving live VMs rarely makes sense), you might not be able to change its IP address due to hard-coded IP addresses, be it in application code or configuration files.
Disaster recovery is a different beast: if you’ve lost the primary DC, it doesn’t hurt if you instantiate the same subnet in the backup DC.
A while ago I described the pre-standard way Cisco IOS used to get delegated IPv6 prefixes from a RADIUS server. Cisco’s documentation always claimed that Cisco IOS implements RFC 4818, but you simply couldn’t get it to work in IOS releases 12.4T or 15.0M. In December I wrote about the progress Cisco is making on the DHCPv6 front and email@example.com commented that IOS 15.1S does support RFC 4818. You know I absolutely had to test that claim ... and it’s true!
2012-01-19: The initial version of this post contained a serious error: Cisco IOS DHCPv6 server does not create host routes; without on-link prefix, the router cannot forward the packets to the attached end-hosts.
IPv6 hosts can use stateless or stateful autoconfiguration. Stateless address autoconfiguration (SLAAC) uses IPv6 prefixes from Router Advertisement (RA) messages; stateful autoconfiguration uses DHCPv6. The routers can use two flags in RA messages to tell the attached end hosts which method to use:
Most of the DMVPN-related questions I get are a variant of the “how many tunnels/hubs/interfaces/areas do I need for a redundant DMVPN design?” As always, the right answer is “it depends” (and I can always help you with your design if you’d like to get a second opinion), but here’s what I’ve learned so far.
I got plenty of responses to the How could we filter extraneous BGP prefixes post, some of them referring to emerging technologies and clean-slate ideas, others describing down-to-earth approaches. Thank you all, you’re fantastic!
Lots of interesting links accumulated in my Evernote notebook during the last two weeks. Let's start with a design masterpiece — Historical Thursday: The Other Manhattan Project: Almost as good as stretched clusters ... and almost as useful ;)
And here are the other links in somewhat random order:
I’ve been blogging regularly for over five years, accumulating almost 1500 posts. It must be quite tasking and time-consuming to leaf through the older posts (not sure anyone ever did that ;), so I decided to use my brand-new Google Analytics add-on to find out which of the old posts are still attracting some attention.
Every so often I get a question along the lines of “could I see a sample of your webinars before I buy them?” To answer the question, I created a new web site that includes the videos I previously published on YouTube, as well as plenty of information on what exactly you get when you buy a recording or the yearly subscription. Your feedback on site outline/design and its contents is highly appreciated!
Did you know that approximately 40% of BGP prefixes polluting your RIB and FIB are not needed, as they could be either aggregated or suppressed (because an aggregate is already announced)? We definitely need “driver’s license for the Internet”, but that’s not likely to happen, and in the meantime everyone has to keep buying larger boxes to cope with people who cannot configure their BGP routing correctly.
I got a follow-up question to the Should I use 6PE or native IPv6 post: “Am I remembering correctly that if you run IPv6 native throughout the network you need to enable BGP on all routers, even P routers? Why is that?” I wrote about BGP-free core before, but evidently wasn’t clear enough, so I’ll try to fix that error.
Brad Hedlund wrote a thought-provoking article a few weeks ago, claiming that the horseshoes (or trombones) and spaghetti created by virtual workloads and appliances deployed anywhere in the network don’t matter much with new data center designs that behave like distributed switches. In theory, he’s right. In practice, less so.
A few weeks ago I asked you to help me plan the new webinars in 2012. More than a 100 readers responded – a huge thank you (there’s a small present waiting in your Inbox if you left your e-mail address)!
I expected some of the results, others totally surprised me. Here are the winners (you can also download the full report).
One of my students was watching the Building IPv6 Service Provider Core webinar and wondered whether he should use 6PE or native IPv6 transport:
Could you explain further why it is better to choose 6PE over running IPv6 in the core? I have to implement IPv6 where I work (a small ISP) and need to fully understand why I should choose a certain implementation.
Here’s a short decision tree that should help you make that decision:
Anton sent me an interesting question:
Most IP phones have a network facing port and a port for user to connect the PC. Today a user plugged in both of these ports into the switch. It looks like phone filters out BPDUs, so the switch did not catch this loop. Do you know of a feature or design that would be able to catch/prevent this type of event?
My answer would be “no, there’s nothing you can do if you have a broken device that acts like a STP-less switch” but you know I’m not a switching or IP telephony guru. Any ideas?
Aleksej sent me an intriguing question: “Can the /48 PI block that a global company is assigned be attached to any region, or it is region-specific?”, or, more specifically:
Imagine a company with major DC with public services in EMEA. Centralized internet break-out in Europe fails and this DC must be reachable from Asia or America - but with the same IPv6 address? That would require Asia or America's ISPs to accept injection of this same subnet in their region. Do they do that?
In theory, the answer is yes. In practice, some global organizations are hedging their bets.
Having nothing better to do in the last few days of 2011, I wrote a simple application that extracts data from Google Analytics. Here are the results for my blog:
Most visited blog posts in 2011
Not surprisingly, the most-popular blog posts were written years ago: