Sorry, I don't mean to be rude but none of that made any sense, especially from an ISP perspective.
You will never have a switch per area; it doesn't work like that, you'll have a series of distribution routers for routing to customers. Mail, www, shell, SIP, whatever will be other services which of course are on one to a milloin switches. Really doesn't matter as this has nothing to do with anything. The routers of an ISP are sorta DHCP in the sense that the IPs are dynamic- DHCP really works as one network whereas an ISP switch will have a series of /30 vlans for obvious reasons. Getting an IP and connection is more complex than that but already we're down to a series of routers. Somewhere in a datacenter (Lets keep it simple for now) is a cabinet with a bunch of servers in; one will do customer web space and so on. This cabinet will have a switch in and either this went or the router it is connected to. They're not using teaming. They're not using loadbalancers. 17^39 is a bit of a weird one to even have to type out. Somewhere someone pulled the wrong cable or someone broke a route. These are the two things which cause (In my experience) almost all of ISP issues. That or a switch died. And whether they meant switch or not they said switch. Chances are they lost a blade or an SFP or whatever. On 18 Mar 2012, at 15:47, [email protected] wrote: > On Sun, 18 Mar 2012 12:49:49 -0000, Peter Maxwell said: >> On 16 March 2012 19:11, Dave <[email protected]> wrote: >>> Your ISP probably has their users are on different networks than their >>> servers. Sounds like maybe they meant the switch you are on, not the >>> servers switch. Need to troubleshoot, use a smart phone or some other OOB >>> capable device to test access to the ISP servers. If you can access OOB, >>> then maybe they aren't lying. Just a guess, you didnt provide much detail. > >> Unlikely, usually these switches are quite large and when a user has OOB it >> usually means console access to the server, i.e. nothing to do with network >> topology. > > I strongly suspect that what Dave meant was: > > 1) There's a switch at the ISP's central site that the services live on. > 2) There's *another* switch that you and the other subscribers in your > area are connected to. > 3) If you can reach the mail server via other means (IP-capable cellphone, > wireless from the local McDonalds, etc), it's more likely switch (2) than (1). > > The real troubleshooting fun starts when you throw things like load balancers > and ethernet bonding into the the config. Nice things if they work, but can > be > a bear to diagnose. If they're doing round-robin, they can end up hosing > every > N'th connection (which is loads of fun when N is in the hundreds). The other > common failure mode is hashing each inbound's address to determine which back > end to go to and certain hash values end up in the bit bucket - so it all > works > great unless your DHCP-supplied IP address is (when treated as a 32-bit > number) > equal to 17 mod 39 or some siimilarl wierdness. The troubleshooting fun gets > even worse if the hash contains both the IP and the ephemeral port number - > this > can result in intermittent issues that will take *month* to find and > diagnose, because > most users will just hit reload, and since the ephemeral port on their end > changed, > it works for them and they never report it... > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
