On 06/21/07 12:37, Peter Rabbitson wrote:
*nod* I had several cases when my ISP had problems like the one you
describe below, so the first 2 hops were pingable but nothing outside.
This is why I suggested the entire ISP subnet exclusion, just to be on
the safe side.
*nod*
I got to give you this one. Murphy at work.
Ya, Murphy and I go back a long way. I can usually tell when I'm on the
right track to solving a problem. If I'm about to beat something, I
start having other little problems, i.e. batteries in equipment going
out, not having the proper patch cord (strait through verses cross
over), not having proper user name and / or password for equipment, etc.
I've gotten to the point that I rather like seeing such speed bumps
because I have noticed that they are usually an indication that I'm at
least going the right direction.
No contest here either. It's just rather rare for a small scale end-user
to be able to get access to IGPs.
Well, just because OSPF is what is used does not mean that I have access
to the IGP. To make things work, I'm having to have my ISP co-locate a
piece of their equipment at my facility so they are using the IGP with
in their administrative domain. I pick up from the single ethernet
interface out of said equipment. It's just a political / administrative
paradigm shift, but it does allow the circuits to do what I want them to
do and rather nicely at that I might add.
I misread the part about the stuff behind the router being routable.
There is nothing wrong with asymmetric routing in this case. However you
bring up an interesting point about MTU, only to dismiss it right there.
I think you will have a problem with the default MTU of 1500 being
combined with the effective MTU of PPPoE links being 1492. Too many
systems in this day and age have PMTU discovery enabled, and you know
what is the current state of ICMP messaging on the net.
*nod* I figured that the globally routable DMZ IPs was not sinking in
so I tried re-stating it differently to see if it would make it. ;)
Both of my links use statically assigned IP addresses on the raw
ethernet interfaces. Thus there is no encapsulation (MTU) overhead to
worry about, i.e. no PPPoE. Seeing as how I'm running MTUs of 1500 out
my interfaces to the world and at least that or larger in to the ISP
(ATM links have 4470 (set for something else some time previous) I don't
think MTU issues will be on my end.
Incidentally, this is one of the reasons that I try to avoid PPPoE if I
can. Well MTU and the fact that our local incumbent phone company as an
ISP likes to tare down the PPPoE connections after less than 60 seconds
of inactivity *WITH OUT* notifying the client end. Thus our only
reliable recourse is to tare down the connection on the client end
before the ILEC does so that we know the state and can re-establish it
on demand when needed.
Grant. . . .
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
|