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.