From: Ed Lui (edwlui@gmail.com)
Date: Tue Oct 18 2005 - 13:59:52 GMT-3
Folks,
HSRP hello packets have TTL(224.0.0.2) of 2 from my sniffer. But PIMv2
packets have TTL(224.0.0.13) of 1.
HTH,
Ed Lui
On 10/17/05, Tim <ccie2be@nyc.rr.com> wrote:
> Hi guys,
>
> Today I had a chance to test passing RIP unicast updates THRU a PIX
> firewall.
>
> It worked - well sort of.
>
> One router, rtr-1, sent unicast rip updates and the other router, rtr-2,
> received them (proving that the TTL is not 1 for unicast rip updates) but it
> didn't work the other way round.
>
> I thought, at first, that maybe the PIX was blocking rip updates from rtr-2
> but I turned on debug ip rip on rtr-2 and discovered that it wasn't sending
> out any updates even though it had virtually the same config as rtr-1 except
> for the network statements.
>
> Both routers were config'd like this:
>
> Router rip
> Ver 2
> No auto
> Net x.x.x.x
> Net y.y.y.y
> Net z.z.z.z
> No validate-update-source
> Neighbor w.x.y.z
> Passive-interface default
>
> When I disabled the passive-int command from rtr-2's connected interface, it
> started sending updates but, of course, used the mcast address, 224.0.0.9
> which didn't get past the pix. It's very strange.
>
>
> A colleague at work suspects that one possible reason is that rtr-2 is
> running a T train of IOS and might be buggy but I'm not so sure. In my
> experience, usually when something didn't work it turned out to be "pilot
> error" and occasionally a router reboot fix the problem when the config was
> actually correct. Of course, in this case, a router reboot did NOT solve
> the problem.
>
> Tomorrow, I'll post the config's and some debugs. Maybe we're just missing
> something very basic.
>
> If anybody has any ideas, please don't by shy, just shout it out.
>
> Thanks,
>
> Tim
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Scott Morris
> Sent: Monday, October 17, 2005 8:36 AM
> To: 'Tim'; 'Jongsoo'
> Cc: 'Chris'; ccielab@groupstudy.com
> Subject: RE: TTL on RIP updates
>
> There is no equivalent to the update-source in EIGRP. You must make your
> subnets match (change the primary address in a secondary environment).
>
> Don't ya hate when your RAM fills up? I've tried compression routines, but
> I still lose stuff.
>
> :)
>
> Scott
>
>
> -----Original Message-----
> From: Tim [mailto:ccie2be@nyc.rr.com]
> Sent: Monday, October 17, 2005 7:45 AM
> To: swm@emanon.com; 'Jongsoo'
> Cc: 'Chris'; ccielab@groupstudy.com
> Subject: RE: TTL on RIP updates
>
> Hey Guys,
>
> I'm fairly sure I did or discussed a practice lab where there was a hub and
> spoke topology over f/r and no sub-interfaces were allowed and disabling
> split-horizon also wasn't allowed. And, of course, the spokes had to pass
> routing updates to each other.
>
> The solution was to use unicast updates (I vaguely recall) which worked only
> because the TTL was 2 in Cisco implementation. The TTL equally 2 was what
> really stuck in my mind because I had never heard of such a thing up until
> that point and was astounded by this revelation.
>
> Here's what I'm still not sure about. Was eigrp or rip or either the
> routing protocol where this TTL = 2 applied?
>
> Since nature only blessed me with 32 mb of ram, I have trouble remembering
> all the details. But later today I'll have a chance to test this out and
> report back.
>
> As for the no validate-source-update command, yes, Scott, that will be
> needed for RIP but I don't recall if there's an equivalent command for
> eigrp. Any thought on that?
>
> Tim
>
> -----Original Message-----
> From: Scott Morris [mailto:swm@emanon.com]
> Sent: Sunday, October 16, 2005 11:04 PM
> To: 'Jongsoo'
> Cc: 'Chris'; 'Tim'; ccielab@groupstudy.com
> Subject: RE: TTL on RIP updates
>
> Broadcasts to 255.255.255.255 inherently have TTL1, as they are local link
> as well...
>
> As for the unicasts, I've never paid attention in a sniffer for it, but I
> would assume that it would follow the same length. Spec says that neighbors
> are supposed to share a common subnet, but I've never tried making a RIP
> neighbor further away without tunnels involved!
>
> Give it a whirl, see what happens! Don't forget to use "no
> validate-update-source" though to avoid confusions.
>
> Scott
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Jongsoo
> Sent: Sunday, October 16, 2005 10:49 PM
> To: Scott Morris
> Cc: Chris; Tim; ccielab@groupstudy.com
> Subject: Re: TTL on RIP updates
>
> That proves the multicast should be 1.
> What about the broadcast/unicast rip packets?
> I think they all should be 1 as well
> Are there any supporting standards? or IOS just does that?
>
> On 10/16/05, Scott Morris <swm@emanon.com> wrote:
> >
> > All packets using 224.0.0.x (link local multicast) are, as defined,
> > link local. Meaning the TTL is 1.
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > Of Chris
> > Sent: Sunday, October 16, 2005 10:13 PM
> > To: 'Tim'; ccielab@groupstudy.com
> > Subject: RE: TTL on RIP updates
> >
> > Looking through the RFC, there does not seem to be anything that
> > specifies that an IP packet containing a RIP update should mark IP
> > header TTL any differently then whatever the default IP stack
> > implementation dictates for a TTL. I would not think there would be
> > any reason to do so since RIP normally sends updates to neighbors by
> > broadcast or multicast which would bound the packet to the closest
> > router where TTL would normally decrement, but that is just me
> > theorizing. As I said the rfc does not say anything about marking the
> > IP header TTL for RIP any differently.
> >
> >
> >
> >
> > Chris
> >
> >
> >
> > --------------------------------------------------
> >
> > Christopher Larson CCIE#12380, PMP
> > Superior Technology Networks Corp
> > www.supertechnetworks.com <http://www.supertechnetworks.com> -
> > Technology Consulting www.ccierackrental.com
> > <http://www.ccierackrental.com> -Cisco Rack Rental
> > tel: 703 577 3303 fax: 703 286 5018
> >
> > --------------------------------------------------
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > Of Tim
> > Sent: Sunday, October 16, 2005 4:24 PM
> > To: ccielab@groupstudy.com
> > Subject: TTL on RIP updates
> >
> > Hi guys,
> >
> >
> >
> > I seem to recall that the TTL for rip updates is 2.
> >
> >
> >
> > Is that true only if the neighbor command is used? Or if the default
> > dest address is 224.0.0.9 <http://224.0.0.9>? Or, never?
> >
> >
> >
> > TIA, Tim
> >
> > ______________________________________________________________________
> > _ 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
>
> _______________________________________________________________________
> 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 Nov 06 2005 - 22:00:51 GMT-3