lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Mar 2012 17:33:37 -0600
From: _ <packetnull@...il.com>
To: Lee <ler762@...il.com>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: is my ISP lying or stupid?

Your ISP is lying thats the answer plain and simple... noc monkey's often conjure up stuff just so you go away typical in the ISP business. just laugh it out.. lol

On Mar 18, 2012, at 12:03 PM, Lee <ler762@...il.com> wrote:

> On 3/18/12, James Condron <james@...o-internet.org.uk> wrote:
>> Sorry, I don't mean to be rude but none of that made any sense, especially
>> from an ISP perspective.
> 
> None of it made any sense wrt the initial question of is my isp lying
> but, allowing for the typical Kletnieks hyperbole, it does make sense
> as a list of weird networking problems I've seen.
> 
> Lee
> 
> 
>> 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, Valdis.Kletnieks@...edu wrote:
>> 
>>> On Sun, 18 Mar 2012 12:49:49 -0000, Peter Maxwell said:
>>>> On 16 March 2012 19:11, Dave <iryshman@...il.com> 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/
>> 
> 
> _______________________________________________
> 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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ