IPv6: Will matter to the enterprise in five years

Routing guru Jeff Doyle says there's no need to move to IPv6 now, offers design tips for OSPF nets, discusses Layer 2 vs. Layer 3 routing and shares more advice with attendees of his live Network World chat.

1 2 Page 2
Page 2 of 2

Dsingh: With voice being taken for granted as a key app over the network, the heat is on to make sure that packets get through with low latency. I've heard SP say and some vendors push for the fact that QoS is only a stop gap and the key is to add enough bandwidth in the core. Isn't that really pushing the problem to someone else's domain? I would have thought that queuing to smooth out peaks would be the solution, but then I keep hearing about queues getting synched and Armageddon. What are your thoughts about the QoS vs. Bandwidth debate?

Jeff_Doyle: I absolutely agree that queuing is not a long-term solution. Queuing is simply a means of, when a link is congested and "something" must be dropped, giving you control over "what" gets dropped. It's no substitute for sufficient bandwidth. However, good traffic engineering practices are an intermediate solution that ensures you are efficiently using all of your available bandwidth before going to the expense of adding more.

Robert: I believe VoIP will push the demand to have highly available enterprise networks. What architecture directions do you recommend to build a large, reliable enterprise network?

Jeff_Doyle: Architecturally, there's not much new. More importantly, and newer, is how you manage the network for availability. Being able to dynamically reroute traffic, change queuing, and understand what the loads and flows in your network are doing in real time. That's a huge challenge.

Dsingh: Jeff, with all the hoopla regarding L2 VPNs and pseudowire. Are there actual successful implementations that allow applications that make assumptions about LAN-like access to work across the underlying WAN?

Jeff_Doyle: Sure, L2 point-to-point service has been the quite successful for many providers. And gaining strength quickly is VPLS, which is really just point-to-multipoint L2 VPNs in a fancy dress.

Router-gal: I have heard flowspec mentioned lately. Can you talk a little about that?

Jeff_Doyle: FlowSpec is a means of quickly pushing BGP policies out to the edge of your network to reactively block DDoS traffic. It's becoming more and more in use by service providers and large enterprises using BGP. While we don't have the room or time to go into the details of how it works here, that's a great idea for a blog post! I'll try to write something on it in the next month or so.

Moderator-Keith: PRE-SUBMITTED QUESTION: You say that attackers are most likely to go after EBGP. What needs to be done to ensure that they won't succeed?

Jeff_Doyle: Authentication with separate passwords for each external neighbor is absolutely critical. The Cisco TTL hack is useful, too. But the reality is that these things can themselves be attacked. A few proposals are out there for secure BGP peering; running the peering sessions over encrypted tunnels would be tremendously useful. I plan to do a column or two on the proposals sometime in the near future, so stay tuned...

Karthik: Why do we have two addresses to identify a host-MAC address and IP address? Can we do away with one of them? Is it an OSI design flaw to have two different addresses to identify any host anywhere on the network?

Jeff_Doyle: First the reality: MAC identifies hosts on local links, whereas IP identifies hosts globally (across routers). Having said that, there is a strange dual function in IP addresses, both locator and identifier. The identifier should probably be something different, like a MAC address. Note that in IPv6, the addresses are more like that; the MAC address can be incorporated into the identifier (Interface-ID) part. That should make Bob Metcalfe happy.

Books, troubleshooting and other recommendations

JFDallaire: Alright, I don't know if it's appropriate, but here it comes. I would like to know how to pinpoint a high CPU usage by the IP Input process that occurs daily around the same time. I read the "Troubleshooting High CPU Utilization in IP Input Process" on the Cisco website about that, but it didn't really help.

Jeff_Doyle: Certainly an appropriate question, but in reality if you've read the Cisco note you probably know more than me at the moment. I pretty much just work through the sch proc CPU outputs.

Ram: Like many other organizations we have a very large number of routers, switches and other equipment which is managed and maintained by different groups. We also supply very different services to different users accessing multiple types of mainframes and servers. We have gotten to the point where no one can figure out where one VPN starts and another ends, or what path a particular connection is taking, making troubleshooting a nightmare. Is there any particular product you could recommend that would allow us to manage or at least trace all the different connections?

Jeff_Doyle: There are several products I can recommend, although I don't know if it's appropriate in this venue; I would likely leave out some good ones. The bigger issue is exactly what you cite; as any network grows in complexity, you need tools that provide insight into what it's really doing. That often (usually) involves more than just a single product.

Router-gal: So, you said you didn't want to recommend specific products for tracing connections in large, complex networks. What kinds of product features are out there that does that – any standards?

Jeff_Doyle: Graphical depictions of the network are important. Anything that allows you to visualize link loads and application flows. You also want to ensure that the monitoring doesn't itself affect the network (loading down CPUs with queries and the such). Netflow is an example of something that gives you good visibility piping into a monitoring product, but can negatively impact your network if you use it too aggressively.

Niharika: If I had to focus on one main routing protocols to study, what should it be?Jeff_Doyle: Definitely OSFP. RIP these days stands for "Rest in Peace." EIGRP is the second protocol to study. If you are going into an service provider environment, however, BGP and MPLS are the protocols to learn. In fact, good MPLS knowledge is quite marketable right now.

Adamf533: Jeff, what would you recommend to someone who has been R&S focused for 10-plus years to move towards (specializations)? Storage, voice, etc.?

Jeff_Doyle: Voice is in big demand right now, as is security. And both, I think, are going to grow much more; so lots of opportunities in that area.

CarlC: Along the same lines, as someone who has been in the business a long time, but never specialized: Recommendations on good books or techniques to "fill in the gaps" and "smooth the rough spots"? Voice and security are definitely the way I am pointing.

Jeff_Doyle: Well, I can plug the "books" page on my Web site (www.doyleassociates.net), which below the self-promoting part is a list of my own favorites. Almost all the books on the list are written by people I know and respect, so I'm comfortable recommending them. 

BillB28: Any plans for a Routing TCP/IP Volume 3?

Jeff_Doyle: That's a timely question. I would like to do that, and proposed a Volume III to Cisco Press about a year ago. I wanted the volume to focus on MPLS. Unfortunately my editors at Cisco Press tell me the market is flooded with MPLS books and they didn't feel it would sell. I was (and am) thinking of writing a post opening the question to my readers, as to what they would like to see in a Volume III. So let me do a preliminary question just on this chat: What topics would you like to see in a potential "Routing TCP/IP Volume III"?

Moderator_Julie: You can send Jeff ideas for Volume III by posting a comment to his blog.

Raul: Jeff, I came from the server management end of IT and was "forced" to take over the network infrastructure of the business. We are a Nortel shop internally and Cisco externally. Could you recommend one or two good books on corporate routing protocols, i.e., VLANs, Trunking, RIP, OSPF, Spanning Tree, LACP, VRRP, BGP, EAPOL & SNMP/MIBs & RMON, for a quick learner who can digest "logical" concepts readily?

Jeff_Doyle: There's a good Cisco Press book on VLANs and related topics, although I hate to say I can't remember the title at the moment. E-mail me offline and I'll look it up. For routing, I have to recommend my own books.

Niharika: How can I learn more about IPv6? Which books and protocols do you recommend?

Jeff_Doyle: I highly recommend either Merike Kaeo's book Designing Network Security, Second Edition, or Marc Blanchet's book, Migrating to IPv6: A Practical Guide to Implementing IPv6 in Mobile and Fixed Networks. Both are excellent introductions.

Raul: What is the current state of NAC and who are the "real" players? There are so many variants it's hard to get the "big picture."

Moderator-Julie: Good question. We had a chat on this topic a short time ago by security expert Joel Snyder. So I'm going to refer you to that chat transcript. Here's also a link to a product test that Network World did on NAC. Hope that helps.

BillB28: How long will Cisco remain as the dominating force in routing?

Jeff_Doyle: Oooh, provocative. I'm not selling my Cisco stock anytime soon.

Moderator-Julie: So thanks for coming today! Remember to keep reading Jeff's blog on the Cisco Subnet site. Mark your calendars for Nov. 13, 2 p.m. EST, for LAN switch security: What hackers know about your switches with Christopher Paggen, from Cisco. Then join us on Wednesday, Nov. 28, 2 p.m. EST, for Greatest Techno-Gifts of the Season, with Cool Tools columnist Keith Shaw.

Jeff_Doyle: Thanks everyone for attending! And certainly submit any more questions you have to me at my blog; always looking for good topics!

Learn more about this topic

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2007 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2