Feed aggregator

Cisco Futurist Dave Evans shares his predictions for the future, discusses the explosion of data and explores the coming Internet of Things – in which everyday objects such as thermometers, cars, light switches and more will have IP addresses and be connected to the Internet.

We were taping two TechWiseTV episodes at Cisco Live this year. To get ready for a show, it takes a ton of set up and config time for all of us. Because of that we are on the show floor before it opens and stay until long after it closes. One day we were setting up our gear and someone told us to be quiet because John Chambers was on and they wanted to hear it. Read more

Bowling shirts...check, obscure reference T-shirts...check, all 16 episodes of Firefly on Blue Ray...check! All right who is heading out to Cisco Live this year in Vegas? This is Cisco's premier geek event for folks like us. Great training, cool announcements and normally some good music in the evening. Robb and I are packing up our stuff (separately...but we do share the same calf-high sports striped...

Robert Pepper, Vice President of Global Technology Policy, takes your questions about the global demand for broadband. He discusses how it is growing everywhere and how it is driven by video.

David Holland, SVP and GM of Cisco's Sports and Entertainment Group, talks about leadership in sports technology and how business models are changing the way teams share the game and fans experience it. Read More.

I received an interesting e-mail the other day to speak to a group of folks getting ready to graduate from a Cisco Academy in Michigan. (Baker College you are awesome!!!) The instructions were simple; speak about anything you want and we'll buy you lunch! Color me there baby! Plus, I get to take the Lake Express high-speed ferry across Lake Michigan! Oh mercy! I kinda felt a little like being in my...

Murali Sitaram talks about enterprise social software and collaboration in the enterprise. He'll discuss the future of social networking, enterprise 2.0 and new ways to work.

Whenever I see a new product come on the market, I always wonder; "Who comes up with these names?" I would have LOVED to have been in the meeting when the names; 666 Cold and Flu Medication, Jos. A. Bank (who abbreviates a first name?). Although I like the name Microsoft Kin...reminds me of down home! I hope it comes with cornbread and fried tators! So when we were approached to do a TechWiseTV show...

Cisco, the worldwide leader in networking that transforms how people connect, communicate and collaborate, reported its third quarter fiscal year 2010 financial results for the period ending Saturday, May 1.

Back when I was younger and my waist size wasn't bigger then my leg length, we used to have a Dude's code. With stuff like Lt. Uhura being the hottest possible woman alive, Wingman etiquette and girls dated by your close friends are off limits even after they have broken up. Anybody But them. As I traveled along in life, I noticed that same theory of; "Anybody But..." in many things. In circuit design...

Ray Smets, Vice President and General Manager of Cisco Wireless Networking Business Unit talks about the borderless mobility experience. Watch, Listen, Engage.

Hard to believe that I ever thought I would be sitting here wondering about the state of security as a viable career path. I have built my career up as a security dude/hacker for years, but lately I have been noticing a few things. - Vendors are getting really good at detecting network anomalies and the interfaces are getting easier and easier to program. - Threat vectors have become so large that...

I love prototyping gear. That initial start up to check if what I designed works like I planned it to. The answer most of the time is NO, but that is a good thing. Many of the things I have developed have came about by trying to design something else. I credit a Technical Writing Prof I had in college (OK OK, insert joke here...) that said he does not believe in writers block. You are either burnt...

The linked video demonstrates RIPng, our first dynamic routing protocol for IPv6. This is a simple but inefficient routing protocol. The metric is based on number of router hops, with no provision for differentiating between links with drastically different bandwidth (a frame-relay hop has the same cost as a 10-gig-ethernet in RIPng). Each router multicasts its entire routing protocol out each interface every 30 seconds, which wastes router CPU. RIPng routinely takes minutes to reroute around network failures.RIPng does have the refinements added in RIPv2. For example, it multicasts its route updates. It is also capable of including tags in the route updates.
The big advantage of RIPng is that it is simple to understand. But in production that is not good enough. RIPng is a perfect protocol for a computer science student to implement as a class project due to its simplicity, but having the PBX unreachable for 3-5 minutes while routing reconverges is unacceptable in a business environment.

In this hands-on exercise, we configure IPv6 addresses on 3 routers in a triangle. Then we configure IPv6 static routes to allow the 6 IPv6 subnets (3 loopback, 3 P2P links) to be accessible on all 3 routers.Static routes are easy to understand. At first glance they appear simple. You just manually configure which next-hop to go to for each subnet destination. But in actual use they are very complex. In our example with 3 routers and 6 subnets, we end up using 12 static route commands to implement our routing. Even then we do not achieve full redundancy, because static routes do not reroute around network failures. Even a small production network with approximately 20 routers would have too many static route commands necessary to make a static-route implementation feasible. In the real world, using dynamic routing protocols to minimize manual configurations (minimizing both effort and errors) is necessary to achieve a robust environment.That said, static routes are sometimes useful at the edge of your network. You redistribute static routes into your routing protocol at the edge of your network where you don't want to dynamically route with routers outside your administrative control. The goal there is just to use the static route to inject a route into your routing protocol. Not to use the static route as your primary routing mechanism.

In 2003, I made a VOIP call from home while downloading a large email attachment. The DSL line saturated and my audio quality became horrible while VOIP packets (and email packets) were being dropped. Doubling the bandwidth to my home would not have solved this problem. The email download would simply have been faster, but the VOIP call would still have suffered packet loss.The solution to this problem is 'quality of service' (QOS). Some applications, particularly realtime interactive applications, are sensitive to packet loss. Other applications, particularly bulk data traffic (including email, ftp, backups, software update downloads) are not time sensitive and can have their traffic delayed in favor of the realtime traffic. QOS is the network function where certain applications and traffic are prioritized over others that are deemed less urgent.The creators of the Internet Protocol version 4 understood that quality of service was a requirement. They included the 'type of service' field in the IPv4 header when it was specified in 1981. When developing IPv6, they cleaned up unnecessary header fields, but still they kept the 'class of service' field in the base IPv6 header. Every Internet Protocol packet sent on the Internet since 1983 (when IPv4 went live) included this service field in the header to enable QOS functionality.In September 2009, Julius Genachowski, chairman of the FCC commissioners, proposed two new 'network neutrality' principles. Among them was the "principle of nondiscrimination." This proposed principle states 'broadband providers cannot discriminate against particular Internet content or applications.' While there is a valid concern that ISP's may choose to impede applications or content from competitors, the current proposal as stated seems to restrict ISP's from using QOS to prioritize traffic for realtime applications, and deprioritize traffic for bulk data applications.Due to the apparent attempt to ignore a fundamental building block of the Internet, I oppose the proposed 'principle of nondiscrimination' as written. ISP's need to prioritize realtime applications, while deprioritizing non-realtime bulk-data-transfer applications. In addition, ISP's need the freedom to block applications which do not 'play nicely' in a bandwidth constrained environment. Network engineers know that sometimes particular applications need to be blocked to allow the majority of the network (and the majority of customers) to enjoy adequate performance.