From: Dillon Yang (gzdillon@hotmail.com)
Date: Thu Mar 10 2005 - 01:12:34 GMT-3
Hi, Kirk:
Thanks for reply!
Another problem is why the same address repeated twice on FR links.
TIA
dillon
----- Original Message -----
From: "Kirk Graham" <kgraham@instructors.net>
To: <ccielab@groupstudy.com>
Sent: Saturday, March 05, 2005 10:47 AM
Subject: Re: Re: result of traceroute
> Thanks for the updated info John. All of those Operating Systems are ones
> that I'd never tested. But it seems I'd done that on a Linux box of some
> type before and it responded to every probe. Oh well. Maybe an update or
> change in the code.
>
> I did find the traceroute.c source code and see where it says Cisco does
> that. My copy of the source code is probably pretty dated.
>
> The reference for ICMP Unreachable rate limiting is in RFC 1812 section
> 4.3.2.8 if anyone is interested. Its vague and likely to give you a
> headache. <g>
>
> A friend of mine believes its a Cisco conspiracy since RFC 1812 was written
> by Fred Baker of Cisco systems in order to make their code RFC-compliant.
> HAHAHA!
>
> I wonder if my friend believes in black helicopters? <G>
>
> Enjoy,
> Kirk!
>
>
> > Actually... NetBSD supports icmp unreachable rate limiting, as does
> > FreeBSD, and Foundry and Juniper and Extreme, Sun and HP use the 'source
> > quench' response when they rate limit and, quoting from 'man 7 icmp' on
> > a Linux boxen..."
> >
> > Linux limits the rate of ICMP error packets to each destination.
> *ICMP_REDIRECT* and *
> > ICMP_DEST_UNREACH* are also limited by the destination route of the
> incoming packets."
> >
> > .... not nearly an all-incluseive list, but I think adequate to
> > determine your fingerprinting method might not be quite so accurate. ;)
> >
> > Also if you take a look at RFC2463 you'll see that when the world goes
> > to IPv6, nodes are *required* limit ICMP error messages, including
> > unreachables.
> >
> > Best Regards,
> >
> > john
> >
> > Kirk Graham wrote:
> >
> > >It means that the destination device is a Cisco. Pretty much.
> > >
> > >I've never found another device that does the same behaviour. Microsoft
> > >doesn't. Bay/Nortel doesn't. Cabletron/whatever. None of the *nix
> varieties
> > >I've tested.
> > >
> > >I can't remember *which* RFC, but there's one that says something like if
> > >you receive two successive UDP packets from the same source IP within
> some
> > >timeframe, that you do not have to reply to the second packet.
> > >
> > >If you get no response to a traceroute packet, the IOS displays an '*' to
> > >indicate a timeout.
> > >
> > >So Cisco is following the RFC standards. ITs probably an option thing, so
> > >everyone else is as well.
> > >
> > >Someone else may be able to find the specific RFC reference. Or maybe it
> > >was in the traceroute spec. I really can't remember.
> > >
> > >But its a nice fingerprinting technique! <g>
> > >
> > >--kg
> > >
> > >
> > >
> > >
> > >>Hi, dear all:
> > >>
> > >>I found that there are some "*" in the last line of traceroute result,
> > >>
> > >>
> > >can somebody explain it?
> > >
> > >
> > >>Thanks in advance.
> > >>dillon
> > >>
> > >>
> > >>r1#traceroute ip
> > >>
> > >>Target IP address: 197.68.1.1
> > >>Source address: 200.200.200.3
> > >>Numeric display [n]:
> > >>Timeout in seconds [3]:
> > >>Probe count [3]: 6
> > >>Minimum Time to Live [1]:
> > >>Maximum Time to Live [30]:
> > >>Port Number [33434]:
> > >>Loose, Strict, Record, Timestamp, Verbose[none]:
> > >>Type escape sequence to abort.
> > >>Tracing the route to 197.68.1.1
> > >>
> > >> 1 3.3.13.3 20 msec 24 msec 20 msec 20 msec 24 msec 20 msec
> > >> 2 3.3.13.3 20 msec 24 msec 20 msec 20 msec 20 msec 20 msec
> > >> 3 3.3.36.6 28 msec 36 msec 24 msec 28 msec 32 msec 24 msec
> > >> 4 3.3.36.6 24 msec 32 msec 24 msec 24 msec 32 msec 28 msec
> > >> 5 3.3.46.4 44 msec 40 msec 40 msec 40 msec 40 msec 40 msec
> > >> 6 3.3.46.4 40 msec 40 msec 40 msec 40 msec 40 msec 40 msec
> > >> 7 150.100.2.254 40 msec * 40 msec * 40 msec *
> > >>r1#
> > >>
> > >>_______________________________________________________________________
> > >>Subscription information may be found at:
> > >>http://www.groupstudy.com/list/CCIELab.html
> > >>
> > >>
> > >
> > >_______________________________________________________________________
> > >Subscription information may be found at:
> > >http://www.groupstudy.com/list/CCIELab.html
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Apr 03 2005 - 17:56:44 GMT-3