327 Words. Plan about 2 minute(s) to read this.
The following info was gleaned from the GroupStudy.com CCIE-LAB mailing list posts I read on 12/31/2007.
- How to use something other than the hostname to perform PPP CHAP authentication. This got me on IE Mock Lab #2, and cost me 8 points in the end. So it’s a topic I’m keenly interested in. :)
- Victor Cappuccio’s blog entry on multicast, including the mechanics of Auto-RP when sparse-dense mode is not allowed.
- If a multicast task requires you to configure a rendezvous point using PIMv2 only, then BSR is the probable solution. Auto-RP was introduced in PIMv1, while BSR was introduced in PIMv2.
- I always thought of traceroute as an ICMP-based tool, but there are also TCP and UDP-based traceroutes. Check out this jewel from Brian Dennis of InternetworkExpert.com regarding different kinds of traceroute traffic:
Note that traceroute is a technique to have the routers between the source and destination reveal themselves and finally have the destination reveal itself by replying to a “packet”. Traceroute can be implemented using ICMP, UDP, and even TCP so as a CCIE when someone asks you to filter “traceroute” you should get a little background as to the traceroute application/OS’s being used to trigger the reply from the destination. Example: Windows uses ICMP echoes by default, most Linux OS’s use UDP by default but can use ICMP echoes (-I option), and the IOS uses UDP. There are also implementations that use TCP.
The goal of traceroute is to have the routers between the source and destination reveal themselves and finally have the destination reply so that you know you have reached it. The routers reveal themselves by sending Time Exceeded (aka TTL-Exceeded) ICMP packets back to the source when the TTL is decremented to zero. The traceroute implementation can determine its reached the destination by having it reply to an ICMP echo request, send an ICMP port unreachable to a packet sent to an unused UDP port, or completing the TCP three-way handshake.