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@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
