"Bob Puff@NLE" wrote:
> 
> HI Pierre,
> 
> Thanks for the reply.  Ok, here's a little more detail:
> 
> DSL ISP:
> ========
> Machine IP: 64.65.206.24   Netmask: 255.255.255.0  (I actually have 32 IPs, but 
>that's
>                            the mask they say to use, and it does work properly, even 
>if
>                            I ping machines outside my own network, yet within that 
>netmask.)
> Gateway IP: 64.65.206.1    (which apparently is an alias for 64.65.210.162)

Actually, the gw is a [Cisco] router whose primary address is .162 and you are
connected to the .1 port...
atm1-2-5-1004-roc-ext-cisco.choiceone.net (64.65.210.162)

> T1 ISP:
> Machine IP: 208.178.159.66  Netmask: 255.255.255.224 (I have 16 IPs)
> Gateway IP: 208.178.169.65  (which is my t1 router: 208.49.135.222)
> 
> Topology (you were real close!):
> 
>  64.65.206.24    ---------- DSL ISP------------216.153.135.10 (netmask 255.255.255.0)
>            eth1 /             |                (a remote user on the same ISP)
>        LM7.1                  |
>            eth3 \             |
>  208.178.159.66  ---------- T1 ISP
> 
> In this example, the box at 216.153.135.10 cannot see 64.65.206.24.
> 
> > So... from say 64.65.210.162, "ping 64.65.206.24" is seen by LM7.1 and reply
> > goes out T1; but reply is not seen by 64.65.210.162...  if so, read on...
> 
> Most likely yes.  Also note from my other message that a TCPDUMP shows an error 
>packet returning
> to me from 216.153.135.10, saying "Admin prohibit filter" or something like that.

Yes...  noticed that in your subsequent post.  The IP addresses you have on the
DSL boxes are not subject to the following:

> > Without specific addresses, I can only suspect you are experiencing the rule
> > which states:  "a packet from netX cannot be routed through netY and back to
> > netX" [EXCEPT if the final destination is netZ]*
> >
> > * the exception is not written up anywhere that I know of; but I did discover it
> > circa 1989.
> 
> Really?  If that indeed is the case, then how do people that have multiple providers 
>handle
> this situation?

Between classless routing and proper network design, this is usually not a
problem.  That said, I'd wager that less than 1/10th of 1% of the ISP staffs
remember this assuming they've even heard of it... 

I had to raise the possibility because this is very subtle possibility and
without your other addressses, it was easy to conjure up a scenario where
216.153.135.10 *could* have been in the 64.65... space; but that's not the
problem (WHEW! :^)  

Not too many ISP know how to properly apply traffic and/or route filters; they
often apply what looks fine only to miss some subtle point...  sounds like this
is the case here.  The ISP very likely will not tell you how the filters are
setup, let alone let you pass that info to this list.  Your best option is to
give them the above topology info, "admin" packet contents and ask them politely
to either "fix it or contact Cisco's TAC for help"...

Oh...  and don't keep any odd route entries you might have added during your
debugging; make sure everything is as it should be (minimal route entries and
defaults) so that you avoid complicating the process.

Sounds to me like you have all the skills needed to sort this out; but your ISP
is in need of help... :^)
 
> Bob

HTH,
Pierre

Reply via email to