[AusNOG] Strange ADSL problem - troubleshooting / diagnosis advice wanted

[Beeson, Ayden]

Hey everybody,

Firstly let me start by saying - This is a residential ADSL question, but I'm asking on the list as I'm looking for some specific DSL troubleshooting tips I may not be aware of / a better understanding of the network from the DSLAM onwards. I hope this email is not considered inappropriate for the list, I have lodged it with my ISP already (Exetel, via a Telstra wholesale ADSL2+ DSLAM connection) but I have a feeling given the strangeness of this one I'm in for a bit of a tough time to get it fixed. I'm not here to harass my ISP who may or may not have people on this list, nor beg for assistance etc, this is more of a general "here's a weird one, anybody got any thoughts?" kind of deal.

With that said, onto the problem and questions:

The problem:
Most nights (and potentially during the day, I'm not sure as I'm not at home to see it) my internet connection is working fine (I sync at around 16-17 mbit, so pretty decent) when all of a sudden my connection becomes almost unusable. It presents like congestion, but far more severe and almost instantly, with most TCP applications completely failing to work (i.e. can't load even my ISP's homepage due to connection timeouts) and UDP applications working very poorly, often only receiving data in occasional bursts every 10-30 seconds.

Voice communications (TeamSpeak in this case) work poorly but do get consistent data through, though the jitter makes it unusable and it often drops out too.

The connection goes from 100% fine to 1% functional in the space of about 2-5 seconds, but then stays like that for anywhere between 1 - 10 minutes.

So far I have done the basic things, check my modem, attenuation, ping checks, traceroutes etc. I have also confirmed my network is not using the link (both my SNMP and netflow from my modem indicate I'm using very little to 0 data before and during the "event") and the traceroutes look the same both when its fine and when its broken (other than the dropped packets and failed timed out lookups when its broken), the one thing I have noticed consistently is that the latency between my modem and the next L3 hop goes from a normal 29ms to 60ms.

The traceroutes or pings to www.exetel.com.au (figured it was best to check with an ISP internal host) all show this latency increase, but the latency doesn't jump around, which is another reason I don't believe its congestion related. It is always 29ms when working fine, and always 60ms when it's playing up.

Given the next hop is beyond the dslam and who knows where (Sydney I'm guessing, my experience with production DSL networks is purely a customer level view) I have no visibility as to what is occurring there, but from all the things I can see, it's not my network causing it. A modem restart doesn't seem to resolve it, though it's hard to tell seeing as my modem takes a few minutes to boot, it's often "resolved" before my modem comes back. I'm pretty sure a few times it was still broken briefly after my modem came back as well and it does resolve itself without my rebooting my modem too.

On the topic, my modem is a Cisco 887 running an IOS 15 version that was mostly / completely up to date when I last checked, though that was a little while ago. I have checked processor usage, memory, attenuation / noise, audible line quality (via the POTS phone) as well as the basic IP troubleshooting and log checks, nothing is coming up at all that would indicate a problem on my end.

The Questions:
1. Any ideas what might be causing this issue that could still on my end? I have checked all the obvious things, IP wise its rock solid, so it'd have to be on the DSL side, though nothing has changed on my gear for a long long time now.
2. Any ideas what might cause behaviour like this on the provider side? Anything I could suggest they look at in particular?
3. Any additional commands / checks I can do on my equipment to confirm / assist in diagnosing anything from items 1 or 2?

I had not had this problem in the past, my copper line seems to be in very good condition as I very rarely experience any dropouts or disconnections at all, this has just started recently and as of last night seems to possibly be getting worse...

Any advice / general theories are welcome :)

Thanks,
Ayden Beeson B.InfoTech, CCNA
Technology Specialist (Networks)
Division Of Information Technology
Charles Sturt University
P.O. Box 789
Albury NSW 2640
Ph :02 60519788
Fax:[phone]
***@csu.edu.au
www.csu.edu.au

Charles Sturt University

| ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN | MELBOURNE | ONTARIO | ORANGE | PORT MACQUARIE | SYDNEY | WAGGA WAGGA |

LEGAL NOTICE
This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University (CSU) does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with CSU may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at CSU. The views expressed in this email are not necessarily those of CSU.

Charles Sturt University in Australia http://www.csu.edu.au The Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN: 83 878 708 551; CRICOS Provider Numbers: 00005F (NSW), 01947G (VIC), 02960B (ACT)). TEQSA Provider Number: PV12018

Charles Sturt University in Ontario http://www.charlessturt.ca 860 Harrington Court, Burlington Ontario Canada L7N 3N4 Registration: www.peqab.ca

Consider the environment before printing this email.

[Guy Ellis]

Hi Ayden,

You need to get the error stats from the modem, RS uncorrected and RS
corrected in both directions.
Monitor them perioidically (i.e. every hour) when you are using the service.

If you see bursts of errors associated with performance issues then you
have a layer 1 problem.
It the error counts don't move, then its a higher layer issue and
wireshark is your friend.

Cheers,
- Guy.

On 10/09/2014 1:22 PM, Beeson, Ayden wrote:
> Hey everybody,
>
> Firstly let me start by saying - This is a residential ADSL question, but I'm asking on the list as I'm looking for some specific DSL troubleshooting tips I may not be aware of / a better understanding of the network from the DSLAM onwards. I hope this email is not considered inappropriate for the list, I have lodged it with my ISP already (Exetel, via a Telstra wholesale ADSL2+ DSLAM connection) but I have a feeling given the strangeness of this one I'm in for a bit of a tough time to get it fixed. I'm not here to harass my ISP who may or may not have people on this list, nor beg for assistance etc, this is more of a general "here's a weird one, anybody got any thoughts?" kind of deal.
>
> With that said, onto the problem and questions:
>
> The problem:
> Most nights (and potentially during the day, I'm not sure as I'm not at home to see it) my internet connection is working fine (I sync at around 16-17 mbit, so pretty decent) when all of a sudden my connection becomes almost unusable. It presents like congestion, but far more severe and almost instantly, with most TCP applications completely failing to work (i.e. can't load even my ISP's homepage due to connection timeouts) and UDP applications working very poorly, often only receiving data in occasional bursts every 10-30 seconds.
>
> Voice communications (TeamSpeak in this case) work poorly but do get consistent data through, though the jitter makes it unusable and it often drops out too.
>
> The connection goes from 100% fine to 1% functional in the space of about 2-5 seconds, but then stays like that for anywhere between 1 - 10 minutes.
>
> So far I have done the basic things, check my modem, attenuation, ping checks, traceroutes etc. I have also confirmed my network is not using the link (both my SNMP and netflow from my modem indicate I'm using very little to 0 data before and during the "event") and the traceroutes look the same both when its fine and when its broken (other than the dropped packets and failed timed out lookups when its broken), the one thing I have noticed consistently is that the latency between my modem and the next L3 hop goes from a normal 29ms to 60ms.
>
> The traceroutes or pings to www.exetel.com.au (figured it was best to check with an ISP internal host) all show this latency increase, but the latency doesn't jump around, which is another reason I don't believe its congestion related. It is always 29ms when working fine, and always 60ms when it's playing up.
>
> Given the next hop is beyond the dslam and who knows where (Sydney I'm guessing, my experience with production DSL networks is purely a customer level view) I have no visibility as to what is occurring there, but from all the things I can see, it's not my network causing it. A modem restart doesn't seem to resolve it, though it's hard to tell seeing as my modem takes a few minutes to boot, it's often "resolved" before my modem comes back. I'm pretty sure a few times it was still broken briefly after my modem came back as well and it does resolve itself without my rebooting my modem too.
>
> On the topic, my modem is a Cisco 887 running an IOS 15 version that was mostly / completely up to date when I last checked, though that was a little while ago. I have checked processor usage, memory, attenuation / noise, audible line quality (via the POTS phone) as well as the basic IP troubleshooting and log checks, nothing is coming up at all that would indicate a problem on my end.
>
> The Questions:
> 1. Any ideas what might be causing this issue that could still on my end? I have checked all the obvious things, IP wise its rock solid, so it'd have to be on the DSL side, though nothing has changed on my gear for a long long time now.
> 2. Any ideas what might cause behaviour like this on the provider side? Anything I could suggest they look at in particular?
> 3. Any additional commands / checks I can do on my equipment to confirm / assist in diagnosing anything from items 1 or 2?
>
> I had not had this problem in the past, my copper line seems to be in very good condition as I very rarely experience any dropouts or disconnections at all, this has just started recently and as of last night seems to possibly be getting worse...
>
> Any advice / general theories are welcome :)
>
> Thanks,
> Ayden Beeson B.InfoTech, CCNA
> Technology Specialist (Networks)
> Division Of Information Technology
> Charles Sturt University
> P.O. Box 789
> Albury NSW 2640
> Ph :02 60519788
> Fax:[phone]
> ***@csu.edu.au
> www.csu.edu.au
>
> Charles Sturt University
>
> | ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN | MELBOURNE | ONTARIO | ORANGE | PORT MACQUARIE | SYDNEY | WAGGA WAGGA |
>
> LEGAL NOTICE
> This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University (CSU) does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with CSU may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at CSU. The views expressed in this email are not necessarily those of CSU.
>
> Charles Sturt University in Australia http://www.csu.edu.au The Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN: 83 878 708 551; CRICOS Provider Numbers: 00005F (NSW), 01947G (VIC), 02960B (ACT)). TEQSA Provider Number: PV12018
>
> Charles Sturt University in Ontario http://www.charlessturt.ca 860 Harrington Court, Burlington Ontario Canada L7N 3N4 Registration: www.peqab.ca
>
> Consider the environment before printing this email.
> _______________________________________________
> AusNOG mailing list
> ***@lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>


--
Guy Ellis
***@traverse.com.au
www.traverse.com.au
T: [phone] M: [phone]

[Beeson, Ayden]

Cheers Guy,

I'll look into pulling those regularly, I'll watch them next time I get a situation where it is having a problem as well.

I can see a Reed-Solomon EC counter on the show dsl int atm 0 so I'm guessing that's the corrected ones, I'll do some looking and ensure I'm collecting the right stats.

Thanks,
Ayden Beeson

-----Original Message-----
From: AusNOG [mailto:ausnog-***@lists.ausnog.net] On Behalf Of Guy Ellis
Sent: Wednesday, 10 September 2014 1:42 PM
To: ***@lists.ausnog.net
Subject: Re: [AusNOG] Strange ADSL problem - troubleshooting / diagnosis advice wanted

Hi Ayden,

You need to get the error stats from the modem, RS uncorrected and RS corrected in both directions.
Monitor them perioidically (i.e. every hour) when you are using the service.

If you see bursts of errors associated with performance issues then you have a layer 1 problem.
It the error counts don't move, then its a higher layer issue and wireshark is your friend.

Cheers,
- Guy.

On 10/09/2014 1:22 PM, Beeson, Ayden wrote:
> Hey everybody,
>
> Firstly let me start by saying - This is a residential ADSL question, but I'm asking on the list as I'm looking for some specific DSL troubleshooting tips I may not be aware of / a better understanding of the network from the DSLAM onwards. I hope this email is not considered inappropriate for the list, I have lodged it with my ISP already (Exetel, via a Telstra wholesale ADSL2+ DSLAM connection) but I have a feeling given the strangeness of this one I'm in for a bit of a tough time to get it fixed. I'm not here to harass my ISP who may or may not have people on this list, nor beg for assistance etc, this is more of a general "here's a weird one, anybody got any thoughts?" kind of deal.
>
> With that said, onto the problem and questions:
>
> The problem:
> Most nights (and potentially during the day, I'm not sure as I'm not at home to see it) my internet connection is working fine (I sync at around 16-17 mbit, so pretty decent) when all of a sudden my connection becomes almost unusable. It presents like congestion, but far more severe and almost instantly, with most TCP applications completely failing to work (i.e. can't load even my ISP's homepage due to connection timeouts) and UDP applications working very poorly, often only receiving data in occasional bursts every 10-30 seconds.
>
> Voice communications (TeamSpeak in this case) work poorly but do get consistent data through, though the jitter makes it unusable and it often drops out too.
>
> The connection goes from 100% fine to 1% functional in the space of about 2-5 seconds, but then stays like that for anywhere between 1 - 10 minutes.
>
> So far I have done the basic things, check my modem, attenuation, ping checks, traceroutes etc. I have also confirmed my network is not using the link (both my SNMP and netflow from my modem indicate I'm using very little to 0 data before and during the "event") and the traceroutes look the same both when its fine and when its broken (other than the dropped packets and failed timed out lookups when its broken), the one thing I have noticed consistently is that the latency between my modem and the next L3 hop goes from a normal 29ms to 60ms.
>
> The traceroutes or pings to www.exetel.com.au (figured it was best to check with an ISP internal host) all show this latency increase, but the latency doesn't jump around, which is another reason I don't believe its congestion related. It is always 29ms when working fine, and always 60ms when it's playing up.
>
> Given the next hop is beyond the dslam and who knows where (Sydney I'm guessing, my experience with production DSL networks is purely a customer level view) I have no visibility as to what is occurring there, but from all the things I can see, it's not my network causing it. A modem restart doesn't seem to resolve it, though it's hard to tell seeing as my modem takes a few minutes to boot, it's often "resolved" before my modem comes back. I'm pretty sure a few times it was still broken briefly after my modem came back as well and it does resolve itself without my rebooting my modem too.
>
> On the topic, my modem is a Cisco 887 running an IOS 15 version that was mostly / completely up to date when I last checked, though that was a little while ago. I have checked processor usage, memory, attenuation / noise, audible line quality (via the POTS phone) as well as the basic IP troubleshooting and log checks, nothing is coming up at all that would indicate a problem on my end.
>
> The Questions:
> 1. Any ideas what might be causing this issue that could still on my end? I have checked all the obvious things, IP wise its rock solid, so it'd have to be on the DSL side, though nothing has changed on my gear for a long long time now.
> 2. Any ideas what might cause behaviour like this on the provider side? Anything I could suggest they look at in particular?
> 3. Any additional commands / checks I can do on my equipment to confirm / assist in diagnosing anything from items 1 or 2?
>
> I had not had this problem in the past, my copper line seems to be in very good condition as I very rarely experience any dropouts or disconnections at all, this has just started recently and as of last night seems to possibly be getting worse...
>
> Any advice / general theories are welcome :)
>
> Thanks,
> Ayden Beeson B.InfoTech, CCNA
> Technology Specialist (Networks)
> Division Of Information Technology
> Charles Sturt University
> P.O. Box 789
> Albury NSW 2640
> Ph :02 60519788
> Fax:[phone]
> ***@csu.edu.au
> www.csu.edu.au
>
> Charles Sturt University
>
> | ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN | MELBOURNE
> | | ONTARIO | ORANGE | PORT MACQUARIE | SYDNEY | WAGGA WAGGA |
>
> LEGAL NOTICE
> This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University (CSU) does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with CSU may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at CSU. The views expressed in this email are not necessarily those of CSU.
>
> Charles Sturt University in Australia http://www.csu.edu.au The
> Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795
> (ABN: 83 878 708 551; CRICOS Provider Numbers: 00005F (NSW), 01947G
> (VIC), 02960B (ACT)). TEQSA Provider Number: PV12018
>
> Charles Sturt University in Ontario http://www.charlessturt.ca 860
> Harrington Court, Burlington Ontario Canada L7N 3N4 Registration:
> www.peqab.ca
>
> Consider the environment before printing this email.
> _______________________________________________
> AusNOG mailing list
> ***@lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>


--
Guy Ellis
***@traverse.com.au
www.traverse.com.au
T: [phone] M: [phone]

_______________________________________________
AusNOG mailing list
***@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog
Charles Sturt University

| ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN | MELBOURNE | ONTARIO | ORANGE | PORT MACQUARIE | SYDNEY | WAGGA WAGGA |

LEGAL NOTICE
This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University (CSU) does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with CSU may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at CSU. The views expressed in this email are not necessarily those of CSU.

Charles Sturt University in Australia http://www.csu.edu.au The Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN: 83 878 708 551; CRICOS Provider Numbers: 00005F (NSW), 01947G (VIC), 02960B (ACT)). TEQSA Provider Number: PV12018

Charles Sturt University in Ontario http://www.charlessturt.ca 860 Harrington Court, Burlington Ontario Canada L7N 3N4 Registration: www.peqab.ca

Consider the environment before printing this email.

[Nathan Brookfield]

Have you requested an IP Address change (If Static), it sounds like someone is pushing some traffic towards your WAN and flooding the connection.

Alternatively you have an impacted machine being used as part of a botnet and it is smashing your upstream pipe.

Kindest Regards,
Nathan Brookfield

Chief Executive Officer
Simtronic Technologies Pty Ltd

Web: http://simtronic.com.au
Phone: [phone]
Fax: [phone]

On 10 Sep 2014, at 13:24, "Beeson, Ayden" <***@csu.edu.au<mailto:***@csu.edu.au>> wrote:

Hey everybody,

Firstly let me start by saying - This is a residential ADSL question, but I'm asking on the list as I'm looking for some specific DSL troubleshooting tips I may not be aware of / a better understanding of the network from the DSLAM onwards. I hope this email is not considered inappropriate for the list, I have lodged it with my ISP already (Exetel, via a Telstra wholesale ADSL2+ DSLAM connection) but I have a feeling given the strangeness of this one I'm in for a bit of a tough time to get it fixed. I'm not here to harass my ISP who may or may not have people on this list, nor beg for assistance etc, this is more of a general "here's a weird one, anybody got any thoughts?" kind of deal.

With that said, onto the problem and questions:

The problem:
Most nights (and potentially during the day, I'm not sure as I'm not at home to see it) my internet connection is working fine (I sync at around 16-17 mbit, so pretty decent) when all of a sudden my connection becomes almost unusable. It presents like congestion, but far more severe and almost instantly, with most TCP applications completely failing to work (i.e. can't load even my ISP's homepage due to connection timeouts) and UDP applications working very poorly, often only receiving data in occasional bursts every 10-30 seconds.

Voice communications (TeamSpeak in this case) work poorly but do get consistent data through, though the jitter makes it unusable and it often drops out too.

The connection goes from 100% fine to 1% functional in the space of about 2-5 seconds, but then stays like that for anywhere between 1 - 10 minutes.

So far I have done the basic things, check my modem, attenuation, ping checks, traceroutes etc. I have also confirmed my network is not using the link (both my SNMP and netflow from my modem indicate I'm using very little to 0 data before and during the "event") and the traceroutes look the same both when its fine and when its broken (other than the dropped packets and failed timed out lookups when its broken), the one thing I have noticed consistently is that the latency between my modem and the next L3 hop goes from a normal 29ms to 60ms.

The traceroutes or pings to www.exetel.com.au<http://www.exetel.com.au> (figured it was best to check with an ISP internal host) all show this latency increase, but the latency doesn't jump around, which is another reason I don't believe its congestion related. It is always 29ms when working fine, and always 60ms when it's playing up.

Given the next hop is beyond the dslam and who knows where (Sydney I'm guessing, my experience with production DSL networks is purely a customer level view) I have no visibility as to what is occurring there, but from all the things I can see, it's not my network causing it. A modem restart doesn't seem to resolve it, though it's hard to tell seeing as my modem takes a few minutes to boot, it's often "resolved" before my modem comes back. I'm pretty sure a few times it was still broken briefly after my modem came back as well and it does resolve itself without my rebooting my modem too.

On the topic, my modem is a Cisco 887 running an IOS 15 version that was mostly / completely up to date when I last checked, though that was a little while ago. I have checked processor usage, memory, attenuation / noise, audible line quality (via the POTS phone) as well as the basic IP troubleshooting and log checks, nothing is coming up at all that would indicate a problem on my end.

The Questions:
1. Any ideas what might be causing this issue that could still on my end? I have checked all the obvious things, IP wise its rock solid, so it'd have to be on the DSL side, though nothing has changed on my gear for a long long time now.
2. Any ideas what might cause behaviour like this on the provider side? Anything I could suggest they look at in particular?
3. Any additional commands / checks I can do on my equipment to confirm / assist in diagnosing anything from items 1 or 2?

I had not had this problem in the past, my copper line seems to be in very good condition as I very rarely experience any dropouts or disconnections at all, this has just started recently and as of last night seems to possibly be getting worse...

Any advice / general theories are welcome :)

Thanks,
Ayden Beeson B.InfoTech, CCNA
Technology Specialist (Networks)
Division Of Information Technology
Charles Sturt University
P.O. Box 789
Albury NSW 2640
Ph :02 60519788
Fax:[phone]
***@csu.edu.au<mailto:***@csu.edu.au>
www.csu.edu.au<http://www.csu.edu.au>

Charles Sturt University

| ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN | MELBOURNE | ONTARIO | ORANGE | PORT MACQUARIE | SYDNEY | WAGGA WAGGA |

LEGAL NOTICE
This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University (CSU) does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with CSU may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at CSU. The views expressed in this email are not necessarily those of CSU.

Charles Sturt University in Australia http://www.csu.edu.au The Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN: 83 878 708 551; CRICOS Provider Numbers: 00005F (NSW), 01947G (VIC), 02960B (ACT)). TEQSA Provider Number: PV12018

Charles Sturt University in Ontario http://www.charlessturt.ca 860 Harrington Court, Burlington Ontario Canada L7N 3N4 Registration: www.peqab.ca<http://www.peqab.ca>

Consider the environment before printing this email.

[Beeson, Ayden]

I'll have another look at actual router level access from the WAN but I'd still see it in my netflow collection from that interface.

I'm 99.99% percent it isn't coming from me or even to me directly, I thought the same as you and did a lot of digging to double check.

I have both SNMP and Netflow monitoring and logging configured on the modem and neither show any significant activity during these time periods on either the up or the downstream.

Thanks,
Ayden Beeson

From: Nathan Brookfield [mailto:***@simtronic.com.au]
Sent: Wednesday, 10 September 2014 1:46 PM
To: Beeson, Ayden
Cc: ***@lists.ausnog.net
Subject: Re: [AusNOG] Strange ADSL problem - troubleshooting / diagnosis advice wanted

Have you requested an IP Address change (If Static), it sounds like someone is pushing some traffic towards your WAN and flooding the connection.

Alternatively you have an impacted machine being used as part of a botnet and it is smashing your upstream pipe.
Kindest Regards,
Nathan Brookfield

Chief Executive Officer
Simtronic Technologies Pty Ltd

Web: http://simtronic.com.au
Phone: [phone]
Fax: [phone]

On 10 Sep 2014, at 13:24, "Beeson, Ayden" <***@csu.edu.au<mailto:***@csu.edu.au>> wrote:
Hey everybody,

Firstly let me start by saying - This is a residential ADSL question, but I'm asking on the list as I'm looking for some specific DSL troubleshooting tips I may not be aware of / a better understanding of the network from the DSLAM onwards. I hope this email is not considered inappropriate for the list, I have lodged it with my ISP already (Exetel, via a Telstra wholesale ADSL2+ DSLAM connection) but I have a feeling given the strangeness of this one I'm in for a bit of a tough time to get it fixed. I'm not here to harass my ISP who may or may not have people on this list, nor beg for assistance etc, this is more of a general "here's a weird one, anybody got any thoughts?" kind of deal.

With that said, onto the problem and questions:

The problem:
Most nights (and potentially during the day, I'm not sure as I'm not at home to see it) my internet connection is working fine (I sync at around 16-17 mbit, so pretty decent) when all of a sudden my connection becomes almost unusable. It presents like congestion, but far more severe and almost instantly, with most TCP applications completely failing to work (i.e. can't load even my ISP's homepage due to connection timeouts) and UDP applications working very poorly, often only receiving data in occasional bursts every 10-30 seconds.

Voice communications (TeamSpeak in this case) work poorly but do get consistent data through, though the jitter makes it unusable and it often drops out too.

The connection goes from 100% fine to 1% functional in the space of about 2-5 seconds, but then stays like that for anywhere between 1 - 10 minutes.

So far I have done the basic things, check my modem, attenuation, ping checks, traceroutes etc. I have also confirmed my network is not using the link (both my SNMP and netflow from my modem indicate I'm using very little to 0 data before and during the "event") and the traceroutes look the same both when its fine and when its broken (other than the dropped packets and failed timed out lookups when its broken), the one thing I have noticed consistently is that the latency between my modem and the next L3 hop goes from a normal 29ms to 60ms.

The traceroutes or pings to www.exetel.com.au<http://www.exetel.com.au> (figured it was best to check with an ISP internal host) all show this latency increase, but the latency doesn't jump around, which is another reason I don't believe its congestion related. It is always 29ms when working fine, and always 60ms when it's playing up.

Given the next hop is beyond the dslam and who knows where (Sydney I'm guessing, my experience with production DSL networks is purely a customer level view) I have no visibility as to what is occurring there, but from all the things I can see, it's not my network causing it. A modem restart doesn't seem to resolve it, though it's hard to tell seeing as my modem takes a few minutes to boot, it's often "resolved" before my modem comes back. I'm pretty sure a few times it was still broken briefly after my modem came back as well and it does resolve itself without my rebooting my modem too.

On the topic, my modem is a Cisco 887 running an IOS 15 version that was mostly / completely up to date when I last checked, though that was a little while ago. I have checked processor usage, memory, attenuation / noise, audible line quality (via the POTS phone) as well as the basic IP troubleshooting and log checks, nothing is coming up at all that would indicate a problem on my end.

The Questions:
1. Any ideas what might be causing this issue that could still on my end? I have checked all the obvious things, IP wise its rock solid, so it'd have to be on the DSL side, though nothing has changed on my gear for a long long time now.
2. Any ideas what might cause behaviour like this on the provider side? Anything I could suggest they look at in particular?
3. Any additional commands / checks I can do on my equipment to confirm / assist in diagnosing anything from items 1 or 2?

I had not had this problem in the past, my copper line seems to be in very good condition as I very rarely experience any dropouts or disconnections at all, this has just started recently and as of last night seems to possibly be getting worse...

Any advice / general theories are welcome :)

Thanks,
Ayden Beeson B.InfoTech, CCNA
Technology Specialist (Networks)
Division Of Information Technology
Charles Sturt University
P.O. Box 789
Albury NSW 2640
Ph :02 60519788
Fax:[phone]
***@csu.edu.au<mailto:***@csu.edu.au>
www.csu.edu.au<http://www.csu.edu.au>

Charles Sturt University

| ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN | MELBOURNE | ONTARIO | ORANGE | PORT MACQUARIE | SYDNEY | WAGGA WAGGA |

LEGAL NOTICE
This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University (CSU) does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with CSU may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at CSU. The views expressed in this email are not necessarily those of CSU.

Charles Sturt University in Australia http://www.csu.edu.au The Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN: 83 878 708 551; CRICOS Provider Numbers: 00005F (NSW), 01947G (VIC), 02960B (ACT)). TEQSA Provider Number: PV12018

Charles Sturt University in Ontario http://www.charlessturt.ca 860 Harrington Court, Burlington Ontario Canada L7N 3N4 Registration: www.peqab.ca<http://www.peqab.ca>

Consider the environment before printing this email.
_______________________________________________
AusNOG mailing list
***@lists.ausnog.net<mailto:***@lists.ausnog.net>
http://lists.ausnog.net/mailman/listinfo/ausnog

[cid:csu-logo6cf4.bmp]<http://www.csu.edu.au/>

| ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN | MELBOURNE | ONTARIO | ORANGE | PORT MACQUARIE | SYDNEY | WAGGA WAGGA |

________________________________
LEGAL NOTICE
This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University (CSU) does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with CSU may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at CSU. The views expressed in this email are not necessarily those of CSU.

Charles Sturt University in Australia<http://www.csu.edu.au> The Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN: 83 878 708 551; CRICOS Provider Number: 00005F (National)). TEQSA Provider Number: PV12018
Charles Sturt University in Ontario<http://www.charlessturt.ca/> 860 Harrington Court, Burlington Ontario Canada L7N 3N4 Registration: www.peqab.ca<http://www.peqab.ca>

[cid:anniversay5f45.bmp]

Consider the environment before printing this email.

[Ross Wheeler]

> I'm 99.99% percent it isn't coming from me or even to me directly, I
> thought the same as you and did a lot of digging to double check.
>
> I have both SNMP and Netflow monitoring and logging configured on the
> modem and neither show any significant activity during these time
> periods on either the up or the downstream.

Recently encountered a problem for an associate, not entirely unlike your
symptoms. When it was finally identified, his colo provider had a
compromised host in an adjacent rack, but which was connected to the same
switch as him. The compromised host was generating so much traffic the
switch was being saturated, he was seeing higher response times, packet
loss, at times loss of routes and all manner of perculiar things.

The traffic wasn't visible to his host(s) or on his network.

(I know that doesn't involve DSL!)

R.

[Paul Brooks]

On 10/09/2014 1:55 PM, Beeson, Ayden wrote:
>
> I'll have another look at actual router level access from the WAN but I'd still see
> it in my netflow collection from that interface.
>
>
>
> I'm 99.99% percent it isn't coming from me or even to me directly, I thought the
> same as you and did a lot of digging to double check.
>
>
>
> I have both SNMP and Netflow monitoring and logging configured on the modem and
> neither show any significant activity during these time periods on either the up or
> the downstream.
>
It may be a re-training bug between your modem and the DSLAM. ADSL2+ is supposed to
re-train to a new sync rate seamlessly without packet drops, whereas the older ADSL1
had to effectively drop the line, re-sync, generate a new bitfield table per tone to
cope with changes to background noise and cross-talk that caused a need for a re-sync.
Perhaps there is a bug causing the DSLAM and the modem to become confused about the
number of bits per tone, and which bits go in which DSL tone, on the transmission
path. That would cause a very high bit-error-rate, causing packets to be dropped when
checksums and fields come through corrupted.

Have you tried a different make/model DSL modem?

P.

[Beeson, Ayden]

I haven't yet, I don't have another handy but it'd be odd that it would start now, though maybe I have a line problem paired with a bug.

I have a bunch of really good test items to check, I'll monitor for a layer 1 problem for now and go from there while I wait for the ISP to do their thing.

Thanks to everybody for the awesome advice, I'll keep you posted :)

Thanks,
Ayden Beeson

From: AusNOG [mailto:ausnog-***@lists.ausnog.net] On Behalf Of Paul Brooks
Sent: Wednesday, 10 September 2014 2:40 PM
To: ***@lists.ausnog.net
Subject: Re: [AusNOG] Strange ADSL problem - troubleshooting / diagnosis advice wanted

On 10/09/2014 1:55 PM, Beeson, Ayden wrote:
I'll have another look at actual router level access from the WAN but I'd still see it in my netflow collection from that interface.

I'm 99.99% percent it isn't coming from me or even to me directly, I thought the same as you and did a lot of digging to double check.

I have both SNMP and Netflow monitoring and logging configured on the modem and neither show any significant activity during these time periods on either the up or the downstream.
It may be a re-training bug between your modem and the DSLAM. ADSL2+ is supposed to re-train to a new sync rate seamlessly without packet drops, whereas the older ADSL1 had to effectively drop the line, re-sync, generate a new bitfield table per tone to cope with changes to background noise and cross-talk that caused a need for a re-sync.
Perhaps there is a bug causing the DSLAM and the modem to become confused about the number of bits per tone, and which bits go in which DSL tone, on the transmission path. That would cause a very high bit-error-rate, causing packets to be dropped when checksums and fields come through corrupted.

Have you tried a different make/model DSL modem?

P.

[cid:csu-logo2370.bmp]<http://www.csu.edu.au/>

| ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN | MELBOURNE | ONTARIO | ORANGE | PORT MACQUARIE | SYDNEY | WAGGA WAGGA |

________________________________
LEGAL NOTICE
This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University (CSU) does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with CSU may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at CSU. The views expressed in this email are not necessarily those of CSU.

Charles Sturt University in Australia<http://www.csu.edu.au> The Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN: 83 878 708 551; CRICOS Provider Number: 00005F (National)). TEQSA Provider Number: PV12018
Charles Sturt University in Ontario<http://www.charlessturt.ca/> 860 Harrington Court, Burlington Ontario Canada L7N 3N4 Registration: www.peqab.ca<http://www.peqab.ca>

[cid:anniversay7901.bmp]

Consider the environment before printing this email.

[Beeson, Ayden]

Hey everybody,

For those of you that are interested, just a brief update.

I have been in touch with both Exetel's tier 1/2 support (via my support ticket) and Exetel's residential support manager and have been collecting some information for them.

I have not had many failures since the post, but I have had a few, last night I had a big one and managed to get a fair bit of troubleshooting done.

Things I have found in addition to my previous post:

Pings / traceroutes to international destinations (bbc.co.uk in this case) also suffer the problem, with the same 30ms increase, always exactly 30ms.
ATM pings end to end work without any packet loss or ping increase. Segment based atm pings always fail, I suspect they are blocked on the remote equipment (DSLAM?).
Reed-Solomon errors do not increase during the failure in any noteworthy way (1 or 2 every so often, no large increasing number or anything)

I'm going to look into borrowing the test 1941 we have at work w/ the ADSL WIC and maybe try that out at home, but I suspect it'll be the same. I'm going to have a look for IOS updates to my 887 as well.

I'll send another update when / if I have any more updates, hopefully it'll be sorted out soon. Thanks again to everybody who has offered advice, tips, config to check, or assorted similar scenarios etc., your advice has all been extremely positive as well as very helpful and interesting.

Cheers,
Ayden

Charles Sturt University

| ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN | MELBOURNE | ONTARIO | ORANGE | PORT MACQUARIE | SYDNEY | WAGGA WAGGA |

LEGAL NOTICE
This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University (CSU) does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with CSU may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at CSU. The views expressed in this email are not necessarily those of CSU.

Charles Sturt University in Australia http://www.csu.edu.au The Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN: 83 878 708 551; CRICOS Provider Numbers: 00005F (NSW), 01947G (VIC), 02960B (ACT)). TEQSA Provider Number: PV12018

Charles Sturt University in Ontario http://www.charlessturt.ca 860 Harrington Court, Burlington Ontario Canada L7N 3N4 Registration: www.peqab.ca

Con

[Damien Gardner Jnr]

Bear in mind, it's not really IOS updates you want, it's adsl firmware
updates.. http://forums.whirlpool.net.au/archive/2036510 has a really good
list to choose from.. On my 877, I settled for 6.0.10 which had a good mix
of stability and speed (I now sync at 5mbps instead of 4 on standard 877
firmware, but not the 6 it was syncing on with a different version but very
unstable)

Cheers,

DG

On 12 September 2014 11:09, Beeson, Ayden <***@csu.edu.au> wrote:

> Hey everybody,
>
> For those of you that are interested, just a brief update.
>
> I have been in touch with both Exetel's tier 1/2 support (via my support
> ticket) and Exetel's residential support manager and have been collecting
> some information for them.
>
> I have not had many failures since the post, but I have had a few, last
> night I had a big one and managed to get a fair bit of troubleshooting done.
>
> Things I have found in addition to my previous post:
>
> Pings / traceroutes to international destinations (bbc.co.uk in this
> case) also suffer the problem, with the same 30ms increase, always exactly
> 30ms.
> ATM pings end to end work without any packet loss or ping increase.
> Segment based atm pings always fail, I suspect they are blocked on the
> remote equipment (DSLAM?).
> Reed-Solomon errors do not increase during the failure in any noteworthy
> way (1 or 2 every so often, no large increasing number or anything)
>
> I'm going to look into borrowing the test 1941 we have at work w/ the ADSL
> WIC and maybe try that out at home, but I suspect it'll be the same. I'm
> going to have a look for IOS updates to my 887 as well.
>
> I'll send another update when / if I have any more updates, hopefully
> it'll be sorted out soon. Thanks again to everybody who has offered advice,
> tips, config to check, or assorted similar scenarios etc., your advice has
> all been extremely positive as well as very helpful and interesting.
>
> Cheers,
> Ayden
>
> Charles Sturt University
>
> | ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN | MELBOURNE |
> ONTARIO | ORANGE | PORT MACQUARIE | SYDNEY | WAGGA WAGGA |
>
> LEGAL NOTICE
> This email (and any attachment) is confidential and is intended for the
> use of the addressee(s) only. If you are not the intended recipient of this
> email, you must not copy, distribute, take any action in reliance on it or
> disclose it to anyone. Any confidentiality is not waived or lost by reason
> of mistaken delivery. Email should be checked for viruses and defects
> before opening. Charles Sturt University (CSU) does not accept liability
> for viruses or any consequence which arise as a result of this email
> transmission. Email communications with CSU may be subject to automated
> email filtering, which could result in the delay or deletion of a
> legitimate email before it is read at CSU. The views expressed in this
> email are not necessarily those of CSU.
>
> Charles Sturt University in Australia http://www.csu.edu.au The Grange
> Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN: 83 878 708
> 551; CRICOS Provider Numbers: 00005F (NSW), 01947G (VIC), 02960B (ACT)).
> TEQSA Provider Number: PV12018
>
> Charles Sturt University in Ontario http://www.charlessturt.ca 860
> Harrington Court, Burlington Ontario Canada L7N 3N4 Registration:
> www.peqab.ca
>
> Consider the environment before printing this email.
> _______________________________________________
> AusNOG mailing list
> ***@lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>



--

Damien Gardner Jnr
VK2TDG. Dip EE. GradIEAust
***@rendrag.net - http://www.rendrag.net/
--
We rode on the winds of the rising storm,
We ran to the sounds of thunder.
We danced among the lightning bolts,
and tore the world asunder

[Beeson, Ayden]

Yep good point, it’s been so long since I messed with it I always forget to think about them being technically separate, Cisco bundle them into the IOS release but I have used other versions before to override the IOS version (on an 857 that I used to use) as the “latest” IOS for that was so far behind it wasn’t funny.

Cheers for the link, I’ll have a look ☺

Thanks,
Ayden Beeson

From: Damien Gardner Jnr [mailto:***@rendrag.net]
Sent: Friday, 12 September 2014 11:19 AM
To: Beeson, Ayden
Cc: ***@lists.ausnog.net
Subject: Re: [AusNOG] Strange ADSL problem - troubleshooting / diagnosis advice wanted

Bear in mind, it's not really IOS updates you want, it's adsl firmware updates.. http://forums.whirlpool.net.au/archive/2036510 has a really good list to choose from.. On my 877, I settled for 6.0.10 which had a good mix of stability and speed (I now sync at 5mbps instead of 4 on standard 877 firmware, but not the 6 it was syncing on with a different version but very unstable)

Cheers,

DG

On 12 September 2014 11:09, Beeson, Ayden <***@csu.edu.au<mailto:***@csu.edu.au>> wrote:
Hey everybody,

For those of you that are interested, just a brief update.

I have been in touch with both Exetel's tier 1/2 support (via my support ticket) and Exetel's residential support manager and have been collecting some information for them.

I have not had many failures since the post, but I have had a few, last night I had a big one and managed to get a fair bit of troubleshooting done.

Things I have found in addition to my previous post:

Pings / traceroutes to international destinations (bbc.co.uk<http://bbc.co.uk> in this case) also suffer the problem, with the same 30ms increase, always exactly 30ms.
ATM pings end to end work without any packet loss or ping increase. Segment based atm pings always fail, I suspect they are blocked on the remote equipment (DSLAM?).
Reed-Solomon errors do not increase during the failure in any noteworthy way (1 or 2 every so often, no large increasing number or anything)

I'm going to look into borrowing the test 1941 we have at work w/ the ADSL WIC and maybe try that out at home, but I suspect it'll be the same. I'm going to have a look for IOS updates to my 887 as well.

I'll send another update when / if I have any more updates, hopefully it'll be sorted out soon. Thanks again to everybody who has offered advice, tips, config to check, or assorted similar scenarios etc., your advice has all been extremely positive as well as very helpful and interesting.

Cheers,
Ayden

Charles Sturt University

| ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN | MELBOURNE | ONTARIO | ORANGE | PORT MACQUARIE | SYDNEY | WAGGA WAGGA |

LEGAL NOTICE
This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University (CSU) does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with CSU may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at CSU. The views expressed in this email are not necessarily those of CSU.

Charles Sturt University in Australia http://www.csu.edu.au The Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN: 83 878 708 551; CRICOS Provider Numbers: 00005F (NSW), 01947G (VIC), 02960B (ACT)). TEQSA Provider Number: PV12018

Charles Sturt University in Ontario http://www.charlessturt.ca 860 Harrington Court, Burlington Ontario Canada L7N 3N4 Registration: www.peqab.ca<http://www.peqab.ca>

Consider the environment before printing this email.
_______________________________________________
AusNOG mailing list
***@lists.ausnog.net<mailto:***@lists.ausnog.net>
http://lists.ausnog.net/mailman/listinfo/ausnog



--

Damien Gardner Jnr
VK2TDG. Dip EE. GradIEAust
***@rendrag.net<mailto:***@rendrag.net> - http://www.rendrag.net/
--
We rode on the winds of the rising storm,
We ran to the sounds of thunder.
We danced among the lightning bolts,
and tore the world asunder

[cid:csu-logo4b40.bmp]<http://www.csu.edu.au/>

| ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN | MELBOURNE | ONTARIO | ORANGE | PORT MACQUARIE | SYDNEY | WAGGA WAGGA |

________________________________
LEGAL NOTICE
This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University (CSU) does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with CSU may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at CSU. The views expressed in this email are not necessarily those of CSU.

Charles Sturt University in Australia<http://www.csu.edu.au> The Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN: 83 878 708 551; CRICOS Provider Number: 00005F (National)). TEQSA Provider Number: PV12018
Charles Sturt University in Ontario<http://www.charlessturt.ca/> 860 Harrington Court, Burlington Ontario Canada L7N 3N4 Registration: www.peqab.ca<http://www.peqab.ca>

[cid:anniversay5878.bmp]

Consider the environment before printing this email.

[Guy Ellis]

Since your error counters are clean, and have stable line sync (I
think), changing the ADSL firmware might just confuse the matter?
I think your problem is at a higher layer - Wireshark is your friend ;-)

- G.

On 12/09/2014 11:25 AM, Beeson, Ayden wrote:
>
> Yep good point, it's been so long since I messed with it I always
> forget to think about them being technically separate, Cisco bundle
> them into the IOS release but I have used other versions before to
> override the IOS version (on an 857 that I used to use) as the
> "latest" IOS for that was so far behind it wasn't funny.
>
> Cheers for the link, I'll have a look J
>
> Thanks,
>
> Ayden Beeson//
>
> *From:*Damien Gardner Jnr [mailto:***@rendrag.net]
> *Sent:* Friday, 12 September 2014 11:19 AM
> *To:* Beeson, Ayden
> *Cc:* ***@lists.ausnog.net
> *Subject:* Re: [AusNOG] Strange ADSL problem - troubleshooting /
> diagnosis advice wanted
>
> Bear in mind, it's not really IOS updates you want, it's adsl firmware
> updates.. http://forums.whirlpool.net.au/archive/2036510 has a really
> good list to choose from.. On my 877, I settled for 6.0.10 which had
> a good mix of stability and speed (I now sync at 5mbps instead of 4 on
> standard 877 firmware, but not the 6 it was syncing on with a
> different version but very unstable)
>
> Cheers,
>
>
> DG
>
> On 12 September 2014 11:09, Beeson, Ayden <***@csu.edu.au
> <mailto:***@csu.edu.au>> wrote:
>
> Hey everybody,
>
> For those of you that are interested, just a brief update.
>
> I have been in touch with both Exetel's tier 1/2 support (via my
> support ticket) and Exetel's residential support manager and have
> been collecting some information for them.
>
> I have not had many failures since the post, but I have had a few,
> last night I had a big one and managed to get a fair bit of
> troubleshooting done.
>
> Things I have found in addition to my previous post:
>
> Pings / traceroutes to international destinations (bbc.co.uk
> <http://bbc.co.uk> in this case) also suffer the problem, with the
> same 30ms increase, always exactly 30ms.
> ATM pings end to end work without any packet loss or ping
> increase. Segment based atm pings always fail, I suspect they are
> blocked on the remote equipment (DSLAM?).
> Reed-Solomon errors do not increase during the failure in any
> noteworthy way (1 or 2 every so often, no large increasing number
> or anything)
>
> I'm going to look into borrowing the test 1941 we have at work w/
> the ADSL WIC and maybe try that out at home, but I suspect it'll
> be the same. I'm going to have a look for IOS updates to my 887 as
> well.
>
> I'll send another update when / if I have any more updates,
> hopefully it'll be sorted out soon. Thanks again to everybody who
> has offered advice, tips, config to check, or assorted similar
> scenarios etc., your advice has all been extremely positive as
> well as very helpful and interesting.
>
> Cheers,
> Ayden
>
> Charles Sturt University
>
> | ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN |
> MELBOURNE | ONTARIO | ORANGE | PORT MACQUARIE | SYDNEY | WAGGA WAGGA |
>
> LEGAL NOTICE
> This email (and any attachment) is confidential and is intended
> for the use of the addressee(s) only. If you are not the intended
> recipient of this email, you must not copy, distribute, take any
> action in reliance on it or disclose it to anyone. Any
> confidentiality is not waived or lost by reason of mistaken
> delivery. Email should be checked for viruses and defects before
> opening. Charles Sturt University (CSU) does not accept liability
> for viruses or any consequence which arise as a result of this
> email transmission. Email communications with CSU may be subject
> to automated email filtering, which could result in the delay or
> deletion of a legitimate email before it is read at CSU. The views
> expressed in this email are not necessarily those of CSU.
>
> Charles Sturt University in Australia http://www.csu.edu.au The
> Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795
> (ABN: 83 878 708 551; CRICOS Provider Numbers: 00005F (NSW),
> 01947G (VIC), 02960B (ACT)). TEQSA Provider Number: PV12018
>
> Charles Sturt University in Ontario http://www.charlessturt.ca 860
> Harrington Court, Burlington Ontario Canada L7N 3N4 Registration:
> www.peqab.ca <http://www.peqab.ca>
>
> Consider the environment before printing this email.
>
> _______________________________________________
> AusNOG mailing list
> ***@lists.ausnog.net <mailto:***@lists.ausnog.net>
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
>
> --
>
> Damien Gardner Jnr
> VK2TDG. Dip EE. GradIEAust
> ***@rendrag.net <mailto:***@rendrag.net> -
> http://www.rendrag.net/_
> _--
> We rode on the winds of the rising storm,
> We ran to the sounds of thunder.
> We danced among the lightning bolts,
> and tore the world asunder
>
> Charles Sturt University <http://www.csu.edu.au/>
>
> | ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN | MELBOURNE | ONTARIO | ORANGE | PORT
> MACQUARIE | SYDNEY | WAGGA WAGGA |
>
> ------------------------------------------------------------------------
> LEGAL NOTICE
> This email (and any attachment) is confidential and is intended for
> the use of the addressee(s) only. If you are not the intended
> recipient of this email, you must not copy, distribute, take any
> action in reliance on it or disclose it to anyone. Any confidentiality
> is not waived or lost by reason of mistaken delivery. Email should be
> checked for viruses and defects before opening. Charles Sturt
> University (CSU) does not accept liability for viruses or any
> consequence which arise as a result of this email transmission. Email
> communications with CSU may be subject to automated email filtering,
> which could result in the delay or deletion of a legitimate email
> before it is read at CSU. The views expressed in this email are not
> necessarily those of CSU.
>
> Charles Sturt University in Australia <http://www.csu.edu.au> The
> Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN:
> 83 878 708 551; CRICOS Provider Number: 00005F (National)). TEQSA
> Provider Number: PV12018
> Charles Sturt University in Ontario <http://www.charlessturt.ca/> 860
> Harrington Court, Burlington Ontario Canada L7N 3N4 Registration:
> www.peqab.ca <http://www.peqab.ca>
>
> Consider the environment before printing this email.
>
>
> _______________________________________________
> AusNOG mailing list
> ***@lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog


--
Guy Ellis
***@traverse.com.au
www.traverse.com.au
T: [phone] M: [phone]

[Beeson, Ayden]

Yep, I'm not planning to change it until I've run out of other ideas, but it is in reserve :)

Thanks,
Ayden Beeson

From: AusNOG [mailto:ausnog-***@lists.ausnog.net] On Behalf Of Guy Ellis
Sent: Friday, 12 September 2014 11:34 AM
To: ***@lists.ausnog.net
Subject: Re: [AusNOG] Strange ADSL problem - troubleshooting / diagnosis advice wanted

Since your error counters are clean, and have stable line sync (I think), changing the ADSL firmware might just confuse the matter?
I think your problem is at a higher layer - Wireshark is your friend ;-)

- G.

On 12/09/2014 11:25 AM, Beeson, Ayden wrote:
Yep good point, it's been so long since I messed with it I always forget to think about them being technically separate, Cisco bundle them into the IOS release but I have used other versions before to override the IOS version (on an 857 that I used to use) as the "latest" IOS for that was so far behind it wasn't funny.

Cheers for the link, I'll have a look :)

Thanks,
Ayden Beeson

From: Damien Gardner Jnr [mailto:***@rendrag.net]
Sent: Friday, 12 September 2014 11:19 AM
To: Beeson, Ayden
Cc: ***@lists.ausnog.net<mailto:***@lists.ausnog.net>
Subject: Re: [AusNOG] Strange ADSL problem - troubleshooting / diagnosis advice wanted

Bear in mind, it's not really IOS updates you want, it's adsl firmware updates.. http://forums.whirlpool.net.au/archive/2036510 has a really good list to choose from.. On my 877, I settled for 6.0.10 which had a good mix of stability and speed (I now sync at 5mbps instead of 4 on standard 877 firmware, but not the 6 it was syncing on with a different version but very unstable)

Cheers,

DG

On 12 September 2014 11:09, Beeson, Ayden <***@csu.edu.au<mailto:***@csu.edu.au>> wrote:
Hey everybody,

For those of you that are interested, just a brief update.

I have been in touch with both Exetel's tier 1/2 support (via my support ticket) and Exetel's residential support manager and have been collecting some information for them.

I have not had many failures since the post, but I have had a few, last night I had a big one and managed to get a fair bit of troubleshooting done.

Things I have found in addition to my previous post:

Pings / traceroutes to international destinations (bbc.co.uk<http://bbc.co.uk> in this case) also suffer the problem, with the same 30ms increase, always exactly 30ms.
ATM pings end to end work without any packet loss or ping increase. Segment based atm pings always fail, I suspect they are blocked on the remote equipment (DSLAM?).
Reed-Solomon errors do not increase during the failure in any noteworthy way (1 or 2 every so often, no large increasing number or anything)

I'm going to look into borrowing the test 1941 we have at work w/ the ADSL WIC and maybe try that out at home, but I suspect it'll be the same. I'm going to have a look for IOS updates to my 887 as well.

I'll send another update when / if I have any more updates, hopefully it'll be sorted out soon. Thanks again to everybody who has offered advice, tips, config to check, or assorted similar scenarios etc., your advice has all been extremely positive as well as very helpful and interesting.

Cheers,
Ayden

Charles Sturt University

| ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN | MELBOURNE | ONTARIO | ORANGE | PORT MACQUARIE | SYDNEY | WAGGA WAGGA |

LEGAL NOTICE
This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University (CSU) does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with CSU may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at CSU. The views expressed in this email are not necessarily those of CSU.

Charles Sturt University in Australia http://www.csu.edu.au The Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN: 83 878 708 551; CRICOS Provider Numbers: 00005F (NSW), 01947G (VIC), 02960B (ACT)). TEQSA Provider Number: PV12018

Charles Sturt University in Ontario http://www.charlessturt.ca 860 Harrington Court, Burlington Ontario Canada L7N 3N4 Registration: www.peqab.ca<http://www.peqab.ca>

Consider the environment before printing this email.
_______________________________________________
AusNOG mailing list
***@lists.ausnog.net<mailto:***@lists.ausnog.net>
http://lists.ausnog.net/mailman/listinfo/ausnog



--

Damien Gardner Jnr
VK2TDG. Dip EE. GradIEAust
***@rendrag.net<mailto:***@rendrag.net> - http://www.rendrag.net/
--
We rode on the winds of the rising storm,
We ran to the sounds of thunder.
We danced among the lightning bolts,
and tore the world asunder

[cid:***@01CFCE82.834521D0]<http://www.csu.edu.au/>

| ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN | MELBOURNE | ONTARIO | ORANGE | PORT MACQUARIE | SYDNEY | WAGGA WAGGA |

________________________________
LEGAL NOTICE
This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University (CSU) does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with CSU may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at CSU. The views expressed in this email are not necessarily those of CSU.

Charles Sturt University in Australia<http://www.csu.edu.au> The Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN: 83 878 708 551; CRICOS Provider Number: 00005F (National)). TEQSA Provider Number: PV12018
Charles Sturt University in Ontario<http://www.charlessturt.ca/> 860 Harrington Court, Burlington Ontario Canada L7N 3N4 Registration: www.peqab.ca<http://www.peqab.ca>

[cid:***@01CFCE82.834521D0]
Consider the environment before printing this email.




_______________________________________________

AusNOG mailing list

***@lists.ausnog.net<mailto:***@lists.ausnog.net>

http://lists.ausnog.net/mailman/listinfo/ausnog




--

Guy Ellis

***@traverse.com.au<mailto:***@traverse.com.au>

www.traverse.com.au<http://www.traverse.com.au>

T: [phone] M: [phone]

[Noel Butler]

Another end user problem, wonder why no one here is a quick to state
this as they are with Daniel...

On 12/09/2014 12:10, Beeson, Ayden wrote:

> Yep, I'm not planning to change it until I've run out of other ideas, but it is in reserve J
>
> Thanks,
>
> Ayden Beeson_ _
>
> FROM: AusNOG [mailto:ausnog-***@lists.ausnog.net] ON BEHALF OF Guy Ellis
> SENT: Friday, 12 September 2014 11:34 AM
> TO: ***@lists.ausnog.net
> SUBJECT: Re: [AusNOG] Strange ADSL problem - troubleshooting / diagnosis advice wanted
>
> Since your error counters are clean, and have stable line sync (I think), changing the ADSL firmware might just confuse the matter?
> I think your problem is at a higher layer - Wireshark is your friend ;-)
>
> - G.
>
> On 12/09/2014 11:25 AM, Beeson, Ayden wrote:
>
> Yep good point, it's been so long since I messed with it I always forget to think about them being technically separate, Cisco bundle them into the IOS release but I have used other versions before to override the IOS version (on an 857 that I used to use) as the "latest" IOS for that was so far behind it wasn't funny.
>
> Cheers for the link, I'll have a look J
>
> Thanks,
>
> Ayden Beeson_ _
>
> FROM: Damien Gardner Jnr [mailto:***@rendrag.net]
> SENT: Friday, 12 September 2014 11:19 AM
> TO: Beeson, Ayden
> CC: ***@lists.ausnog.net
> SUBJECT: Re: [AusNOG] Strange ADSL problem - troubleshooting / diagnosis advice wanted
>
> Bear in mind, it's not really IOS updates you want, it's adsl firmware updates.. http://forums.whirlpool.net.au/archive/2036510 [2] has a really good list to choose from.. On my 877, I settled for 6.0.10 which had a good mix of stability and speed (I now sync at 5mbps instead of 4 on standard 877 firmware, but not the 6 it was syncing on with a different version but very unstable)
>
> Cheers,
>
> DG
>
> On 12 September 2014 11:09, Beeson, Ayden <***@csu.edu.au> wrote:
>
> Hey everybody,
>
> For those of you that are interested, just a brief update.
>
> I have been in touch with both Exetel's tier 1/2 support (via my support ticket) and Exetel's residential support manager and have been collecting some information for them.
>
> I have not had many failures since the post, but I have had a few, last night I had a big one and managed to get a fair bit of troubleshooting done.
>
> Things I have found in addition to my previous post:
>
> Pings / traceroutes to international destinations (bbc.co.uk [3] in this case) also suffer the problem, with the same 30ms increase, always exactly 30ms.
> ATM pings end to end work without any packet loss or ping increase. Segment based atm pings always fail, I suspect they are blocked on the remote equipment (DSLAM?).
> Reed-Solomon errors do not increase during the failure in any noteworthy way (1 or 2 every so often, no large increasing number or anything)
>
> I'm going to look into borrowing the test 1941 we have at work w/ the ADSL WIC and maybe try that out at home, but I suspect it'll be the same. I'm going to have a look for IOS updates to my 887 as well.
>
> I'll send another update when / if I have any more updates, hopefully it'll be sorted out soon. Thanks again to everybody who has offered advice, tips, config to check, or assorted similar scenarios etc., your advice has all been extremely positive as well as very helpful and interesting.
>
> Cheers,
> Ayden
>
> Charles Sturt University
>
> | ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN | MELBOURNE | ONTARIO | ORANGE | PORT MACQUARIE | SYDNEY | WAGGA WAGGA |
>
> LEGAL NOTICE
> This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University (CSU) does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with CSU may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at CSU. The views expressed in this email are not necessarily those of CSU.
>
> Charles Sturt University in Australia http://www.csu.edu.au [4] The Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN: 83 878 708 551; CRICOS Provider Numbers: 00005F (NSW), 01947G (VIC), 02960B (ACT)). TEQSA Provider Number: PV12018
>
> Charles Sturt University in Ontario http://www.charlessturt.ca [5] 860 Harrington Court, Burlington Ontario Canada L7N 3N4 Registration: www.peqab.ca [6]
>
> Consider the environment before printing this email.
>
> _______________________________________________
> AusNOG mailing list
> ***@lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog [1]
>
> --
>
> Damien Gardner Jnr
> VK2TDG. Dip EE. GradIEAust
> ***@rendrag.net - http://www.rendrag.net/ [7]
> --
> We rode on the winds of the rising storm,
> We ran to the sounds of thunder.
> We danced among the lightning bolts,
> and tore the world asunder
>
> [8]
>
> | ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN | MELBOURNE | ONTARIO | ORANGE | PORT MACQUARIE | SYDNEY | WAGGA WAGGA |
>
> -------------------------
>
> LEGAL NOTICE
> This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University (CSU) does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with CSU may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at CSU. The views expressed in this email are not necessarily those of CSU.
>
> Charles Sturt University in Australia [4] The Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN: 83 878 708 551; CRICOS Provider Number: 00005F (National)). TEQSA Provider Number: PV12018
> Charles Sturt University in Ontario [9] 860 Harrington Court, Burlington Ontario Canada L7N 3N4 Registration: www.peqab.ca [6]
>
> Consider the environment before printing this email.
>
> _______________________________________________
>
> AusNOG mailing list
>
> ***@lists.ausnog.net
>
> http://lists.ausnog.net/mailman/listinfo/ausnog [1]

--

Guy Ellis

***@traverse.com.au

www.traverse.com.au [10]

T: [phone] M: [phone]

_______________________________________________
AusNOG mailing list
***@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog [1]



Links:
------
[1] http://lists.ausnog.net/mailman/listinfo/ausnog
[2] http://forums.whirlpool.net.au/archive/2036510
[3] http://bbc.co.uk
[4] http://www.csu.edu.au
[5] http://www.charlessturt.ca
[6] http://www.peqab.ca
[7] http://www.rendrag.net/
[8] http://www.csu.edu.au/
[9] http://www.charlessturt.ca/
[10] http://www.traverse.com.au

[Guy Ellis]

There is an upside to this one (Don't know about Daniel's case).
Most of this discussion is of a technical nature and maybe helpful to
Operators generally.

Besides it's a heck of a lot better than the p_ss and moan session we
had earlier in the week about Conroy / Turnbull etc and related
conspiracy theories!

- G.

On 12/09/2014 1:45 PM, Noel Butler wrote:
>
> Another end user problem, wonder why no one here is a quick to state
> this as they are with Daniel...
>
> On 12/09/2014 12:10, Beeson, Ayden wrote:
>
>> Yep, I'm not planning to change it until I've run out of other ideas,
>> but it is in reserve J
>>
>> Thanks,
>>
>> Ayden Beeson//
>>
>> *From:*AusNOG [mailto:ausnog-***@lists.ausnog.net] *On Behalf Of
>> *Guy Ellis
>> *Sent:* Friday, 12 September 2014 11:34 AM
>> *To:* ***@lists.ausnog.net
>> *Subject:* Re: [AusNOG] Strange ADSL problem - troubleshooting /
>> diagnosis advice wanted
>>
>> Since your error counters are clean, and have stable line sync (I
>> think), changing the ADSL firmware might just confuse the matter?
>> I think your problem is at a higher layer - Wireshark is your friend ;-)
>>
>> - G.
>>
>> On 12/09/2014 11:25 AM, Beeson, Ayden wrote:
>>
>> Yep good point, it's been so long since I messed with it I always
>> forget to think about them being technically separate, Cisco
>> bundle them into the IOS release but I have used other versions
>> before to override the IOS version (on an 857 that I used to use)
>> as the "latest" IOS for that was so far behind it wasn't funny.
>>
>> Cheers for the link, I'll have a look J
>>
>> Thanks,
>>
>> Ayden Beeson//
>>
>> *From:*Damien Gardner Jnr [mailto:***@rendrag.net]
>> *Sent:* Friday, 12 September 2014 11:19 AM
>> *To:* Beeson, Ayden
>> *Cc:* ***@lists.ausnog.net <mailto:***@lists.ausnog.net>
>> *Subject:* Re: [AusNOG] Strange ADSL problem - troubleshooting /
>> diagnosis advice wanted
>>
>> Bear in mind, it's not really IOS updates you want, it's adsl
>> firmware updates.. http://forums.whirlpool.net.au/archive/2036510
>> has a really good list to choose from.. On my 877, I settled for
>> 6.0.10 which had a good mix of stability and speed (I now sync at
>> 5mbps instead of 4 on standard 877 firmware, but not the 6 it was
>> syncing on with a different version but very unstable)
>>
>> Cheers,
>>
>>
>> DG
>>
>> On 12 September 2014 11:09, Beeson, Ayden <***@csu.edu.au
>> <mailto:***@csu.edu.au>> wrote:
>>
>> Hey everybody,
>>
>> For those of you that are interested, just a brief update.
>>
>> I have been in touch with both Exetel's tier 1/2 support (via
>> my support ticket) and Exetel's residential support manager
>> and have been collecting some information for them.
>>
>> I have not had many failures since the post, but I have had a
>> few, last night I had a big one and managed to get a fair bit
>> of troubleshooting done.
>>
>> Things I have found in addition to my previous post:
>>
>> Pings / traceroutes to international destinations (bbc.co.uk
>> <http://bbc.co.uk> in this case) also suffer the problem,
>> with the same 30ms increase, always exactly 30ms.
>> ATM pings end to end work without any packet loss or ping
>> increase. Segment based atm pings always fail, I suspect they
>> are blocked on the remote equipment (DSLAM?).
>> Reed-Solomon errors do not increase during the failure in any
>> noteworthy way (1 or 2 every so often, no large increasing
>> number or anything)
>>
>> I'm going to look into borrowing the test 1941 we have at
>> work w/ the ADSL WIC and maybe try that out at home, but I
>> suspect it'll be the same. I'm going to have a look for IOS
>> updates to my 887 as well.
>>
>> I'll send another update when / if I have any more updates,
>> hopefully it'll be sorted out soon. Thanks again to everybody
>> who has offered advice, tips, config to check, or assorted
>> similar scenarios etc., your advice has all been extremely
>> positive as well as very helpful and interesting.
>>
>> Cheers,
>> Ayden
>>
>> Charles Sturt University
>>
>> | ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN |
>> MELBOURNE | ONTARIO | ORANGE | PORT MACQUARIE | SYDNEY |
>> WAGGA WAGGA |
>>
>> LEGAL NOTICE
>> This email (and any attachment) is confidential and is
>> intended for the use of the addressee(s) only. If you are not
>> the intended recipient of this email, you must not copy,
>> distribute, take any action in reliance on it or disclose it
>> to anyone. Any confidentiality is not waived or lost by
>> reason of mistaken delivery. Email should be checked for
>> viruses and defects before opening. Charles Sturt University
>> (CSU) does not accept liability for viruses or any
>> consequence which arise as a result of this email
>> transmission. Email communications with CSU may be subject to
>> automated email filtering, which could result in the delay or
>> deletion of a legitimate email before it is read at CSU. The
>> views expressed in this email are not necessarily those of CSU.
>>
>> Charles Sturt University in Australia http://www.csu.edu.au
>> The Grange Chancellery, Panorama Avenue, Bathurst NSW
>> Australia 2795 (ABN: 83 878 708 551; CRICOS Provider
>> Numbers: 00005F (NSW), 01947G (VIC), 02960B (ACT)). TEQSA
>> Provider Number: PV12018
>>
>> Charles Sturt University in Ontario
>> http://www.charlessturt.ca 860 Harrington Court, Burlington
>> Ontario Canada L7N 3N4 Registration: www.peqab.ca
>> <http://www.peqab.ca>
>>
>> Consider the environment before printing this email.
>>
>> _______________________________________________
>> AusNOG mailing list
>> ***@lists.ausnog.net <mailto:***@lists.ausnog.net>
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>>
>>
>> --
>>
>> Damien Gardner Jnr
>> VK2TDG. Dip EE. GradIEAust
>> ***@rendrag.net <mailto:***@rendrag.net> -
>> http://www.rendrag.net/
>> --
>> We rode on the winds of the rising storm,
>> We ran to the sounds of thunder.
>> We danced among the lightning bolts,
>> and tore the world asunder
>>
>> Charles Sturt University <http://www.csu.edu.au/>
>>
>> | ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN | MELBOURNE | ONTARIO | ORANGE | PORT
>> MACQUARIE | SYDNEY | WAGGA WAGGA |
>>
>> ------------------------------------------------------------------------
>>
>> *LEGAL NOTICE*
>> This email (and any attachment) is confidential and is intended
>> for the use of the addressee(s) only. If you are not the intended
>> recipient of this email, you must not copy, distribute, take any
>> action in reliance on it or disclose it to anyone. Any
>> confidentiality is not waived or lost by reason of mistaken
>> delivery. Email should be checked for viruses and defects before
>> opening. Charles Sturt University (CSU) does not accept liability
>> for viruses or any consequence which arise as a result of this
>> email transmission. Email communications with CSU may be subject
>> to automated email filtering, which could result in the delay or
>> deletion of a legitimate email before it is read at CSU. The
>> views expressed in this email are not necessarily those of CSU.
>>
>> Charles Sturt University in Australia <http://www.csu.edu.au> The
>> Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795
>> (ABN: 83 878 708 551; CRICOS Provider Number: 00005F (National)).
>> TEQSA Provider Number: PV12018
>> Charles Sturt University in Ontario <http://www.charlessturt.ca/>
>> 860 Harrington Court, Burlington Ontario Canada L7N 3N4
>> Registration: www.peqab.ca <http://www.peqab.ca>
>>
>> Consider the environment before printing this email.
>>
>>
>>
>> _______________________________________________
>>
>> AusNOG mailing list
>>
>> ***@lists.ausnog.net <mailto:***@lists.ausnog.net>
>>
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>>
>>
>>
>> --
>> Guy Ellis
>> ***@traverse.com.au <mailto:***@traverse.com.au>
>> www.traverse.com.au <http://www.traverse.com.au>
>> T: [phone] M: [phone]
>>
>> _______________________________________________
>> AusNOG mailing list
>> ***@lists.ausnog.net <mailto:***@lists.ausnog.net>
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
>
> _______________________________________________
> AusNOG mailing list
> ***@lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog


--
Guy Ellis
***@traverse.com.au
www.traverse.com.au
T: [phone] M: [phone]

[Noel Butler]

It's still end user stuff, and unrelated in the charter of AusNog, as is
the community TV thread (that space is not up for NBN) amongst others.

christ, people are worried about this list turning into whingepool? Too
late, its already there, whether you get away with it or not depends if
your in the "in crowd" or not.

If you want to have rules, they gotta be enforced globally without bias
and favouritism, not just when mods feel like it or because a member is
"popular", or not.

I've had this out with David before, but it seems very little ever
changes (much like the board, cant recall the last time I saw an ausnog
board election notice)

anyway, happy weekend all

On 12/09/2014 14:17, Guy Ellis wrote:

> There is an upside to this one (Don't know about Daniel's case).
> Most of this discussion is of a technical nature and maybe helpful to Operators generally.
>
> Besides it's a heck of a lot better than the p_ss and moan session we had earlier in the week about Conroy / Turnbull etc and related conspiracy theories!

[Beeson, Ayden]

I actually checked the charter prior to posting, and found it says:
<snip> “the discussion of technically focused operational issues, and the discussion of technical issues relating to provision of internet services”</snip>
http://www.ausnog.net/mailing_list/charter

I believe the main issue that people have taken offense with Daniel’s posts in the past would be that some of them were easily resolved with some Google searching (that is not to say all of them, he often has genuine questions), this was more of a highly technical and abstract issue that I was going to find a lot of garbage for (and had) whereas I was looking for a more technical perspective than that would give me.

While I don’t think I was in violation of the list charter, I did warn people in advance anyway of exactly what it was, people did seem interested in the outcome and a lot of great advice was offered so it was valuable, even if just to me ☺

Also I wouldn’t claim I’m “popular” on the list, if I had to label myself anything it would be “annoying lurker / occasional contributor”

But it is a fair point and I was concerned about posting it in the first place, so I’d like to think I was on the right side of the fence, even if I was skirting it.

Thanks,
Ayden Beeson

From: AusNOG [mailto:ausnog-***@lists.ausnog.net] On Behalf Of Noel Butler
Sent: Friday, 12 September 2014 4:30 PM
To: ***@lists.ausnog.net
Subject: Re: [AusNOG] Strange ADSL problem - troubleshooting / diagnosis advice wanted


It's still end user stuff, and unrelated in the charter of AusNog, as is the community TV thread (that space is not up for NBN) amongst others.

christ, people are worried about this list turning into whingepool? Too late, its already there, whether you get away with it or not depends if your in the "in crowd" or not.

If you want to have rules, they gotta be enforced globally without bias and favouritism, not just when mods feel like it or because a member is "popular", or not.

I've had this out with David before, but it seems very little ever changes (much like the board, cant recall the last time I saw an ausnog board election notice)



anyway, happy weekend all



On 12/09/2014 14:17, Guy Ellis wrote:
There is an upside to this one (Don't know about Daniel's case).
Most of this discussion is of a technical nature and maybe helpful to Operators generally.

Besides it's a heck of a lot better than the p_ss and moan session we had earlier in the week about Conroy / Turnbull etc and related conspiracy theories!

[cid:csu-logo53d3.bmp]<http://www.csu.edu.au/>

| ALBURY-WODONGA | BATHURST | CANBERRA | DUBBO | GOULBURN | MELBOURNE | ONTARIO | ORANGE | PORT MACQUARIE | SYDNEY | WAGGA WAGGA |

________________________________
LEGAL NOTICE
This email (and any attachment) is confidential and is intended for the use of the addressee(s) only. If you are not the intended recipient of this email, you must not copy, distribute, take any action in reliance on it or disclose it to anyone. Any confidentiality is not waived or lost by reason of mistaken delivery. Email should be checked for viruses and defects before opening. Charles Sturt University (CSU) does not accept liability for viruses or any consequence which arise as a result of this email transmission. Email communications with CSU may be subject to automated email filtering, which could result in the delay or deletion of a legitimate email before it is read at CSU. The views expressed in this email are not necessarily those of CSU.

Charles Sturt University in Australia<http://www.csu.edu.au> The Grange Chancellery, Panorama Avenue, Bathurst NSW Australia 2795 (ABN: 83 878 708 551; CRICOS Provider Number: 00005F (National)). TEQSA Provider Number: PV12018
Charles Sturt University in Ontario<http://www.charlessturt.ca/> 860 Harrington Court, Burlington Ontario Canada L7N 3N4 Registration: www.peqab.ca<http://www.peqab.ca>

[cid:anniversay45a1.bmp]

Consider the environment before printing this email.

[Jeremy Visser]

On 10/09/14 14:39, Paul Brooks wrote:
> ADSL2+ is supposed to re-train to a new sync rate seamlessly without
> packet drops, whereas the older ADSL1 had to effectively drop the
> line, re-sync, generate a new bitfield table per tone to cope with
> changes to background noise and cross-talk that caused a need for a
> re-sync.

I thought that was a feature of VDSL2, not ADSL2+.

I’d be interested to see a source on that as happy to be wrong.

[Jarryd Sullivan]

http://www.cisco.com/c/en/us/td/docs/routers/access/800/software/configuration/guide/SCG800Guide/SCG800_Guide_BookMap_chapter_010.html#con_1219160

Jarryd Sullivan


-----Original Message-----
From: AusNOG [mailto:ausnog-***@lists.ausnog.net] On Behalf Of Jeremy Visser
Sent: Wednesday, 10 September 2014 2:59 PM
To: ***@lists.ausnog.net
Subject: Re: [AusNOG] Strange ADSL problem - troubleshooting / diagnosis advice wanted

On 10/09/14 14:39, Paul Brooks wrote:
> ADSL2+ is supposed to re-train to a new sync rate seamlessly without
> packet drops, whereas the older ADSL1 had to effectively drop the
> line, re-sync, generate a new bitfield table per tone to cope with
> changes to background noise and cross-talk that caused a need for a
> re-sync.

I thought that was a feature of VDSL2, not ADSL2+.

I'd be interested to see a source on that as happy to be wrong.
_______________________________________________
AusNOG mailing list
***@lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog

________________________________

The information contained in this message and any attachments may be confidential information. If you are not the intended recipient, you must not use or forward the information contained in these documents. If you have received this message in error, please delete the email and notify the sender.

Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments.

[Guy Ellis]

It's called Seamless Rate Adaption (SRA) and is part of the ADSL2+
standards.

You might be confusing it with Vectoring as in the case of VDSL2?

- G.

On 10/09/2014 3:28 PM, Jeremy Visser wrote:
> On 10/09/14 14:39, Paul Brooks wrote:
>> ADSL2+ is supposed to re-train to a new sync rate seamlessly without
>> packet drops, whereas the older ADSL1 had to effectively drop the
>> line, re-sync, generate a new bitfield table per tone to cope with
>> changes to background noise and cross-talk that caused a need for a
>> re-sync.
> I thought that was a feature of VDSL2, not ADSL2+.
>
> I’d be interested to see a source on that as happy to be wrong.
> _______________________________________________
> AusNOG mailing list
> ***@lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>


--
Guy Ellis
***@traverse.com.au
www.traverse.com.au
T: [phone] M: [phone]

[Jason Reid]

To OP

I would be testing another router on that line before sodding too much time
on it - I've seen too many fail after 4-5 years to count.

Regards
Jason Reid

On Wednesday, 10 September 2014, Guy Ellis <***@traverse.com.au> wrote:

> It's called Seamless Rate Adaption (SRA) and is part of the ADSL2+
> standards.
>
> You might be confusing it with Vectoring as in the case of VDSL2?
>
> - G.
>
> On 10/09/2014 3:28 PM, Jeremy Visser wrote:
>
>> On 10/09/14 14:39, Paul Brooks wrote:
>>
>>> ADSL2+ is supposed to re-train to a new sync rate seamlessly without
>>> packet drops, whereas the older ADSL1 had to effectively drop the
>>> line, re-sync, generate a new bitfield table per tone to cope with
>>> changes to background noise and cross-talk that caused a need for a
>>> re-sync.
>>>
>> I thought that was a feature of VDSL2, not ADSL2+.
>>
>> I’d be interested to see a source on that as happy to be wrong.
>> _______________________________________________
>> AusNOG mailing list
>> ***@lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>>
>
> --
> Guy Ellis
> ***@traverse.com.au
> www.traverse.com.au
> T: [phone] M: [phone]
>
> _______________________________________________
> AusNOG mailing list
> ***@lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>


--
Jason Reid

[Paul Brooks]

On 10/09/2014 3:28 PM, Jeremy Visser wrote:
> On 10/09/14 14:39, Paul Brooks wrote:
>> ADSL2+ is supposed to re-train to a new sync rate seamlessly without
>> packet drops, whereas the older ADSL1 had to effectively drop the
>> line, re-sync, generate a new bitfield table per tone to cope with
>> changes to background noise and cross-talk that caused a need for a
>> re-sync.
> I thought that was a feature of VDSL2, not ADSL2+.
>
> I’d be interested to see a source on that as happy to be wrong.

Its actually goes back to ADSL2:

G.992.5 Jan 2009 ADSL2+

https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.992.5-200901-I!!ZPF-E&type=items


Page 'ii':
This Recommendation defines several optional capabilities and features:
– transport of STM and/or ATM and/or Packets;
– transport of a network timing reference;
– multiple latency paths;
– multiple frame bearers;
– short initialization procedure;
*– dynamic rate repartitioning;**
**– seamless rate adaptation;*
- extended impulse noise protection;
- erasure decoding;
- virtual noise;
- impulse noise monitor.
"

G.992.3 April 2009 ADSL2:

https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.992.3-200904-I!!ZPF-E&type=items

Page 'ii':
"This Recommendation defines several optional capabilities and features:
• transport of STM and/or ATM and/or Packets;
• transport of a network timing reference;
• multiple latency paths;
• multiple frame bearers;
• short initialization procedure;
*• dynamic rate repartitioning;**
**• seamless rate adaptation;*
• extended impulse noise protection;
• erasure decoding;
• virtual noise;
• impulse noise monitor."

"Relative to Recommendation ITU-T G.992.1, the following PMD-related features have
been added:
• New line diagnostics procedures available for both successful and unsuccessful
initialization
scenarios, loop characterization and trouble-shooting.
*• Enhanced on-line reconfiguration capabilities including bitswaps and seamless rate
adaptation.**
**• Optional short initialization sequence for recovery from errors or fast resumption
of operation.**
**• Optional seamless rate adaptation with line rate changes during showtime.*"

Clause 8.16:
"8.16 On-line reconfiguration of the PMD function
On-line reconfiguration of the PMD function is intended to allow changes in the
control parameters
without interruption of service and without errors (i.e., bitswap, dynamic rate
repartitioning and
seamless rate adaptation)."

VDSL2 doesn't really add much functionality to ADSL2 other than the vastly expanded
frequency range.

cheers...

Paul.

[Jarrad Mitchell]

I'm not sure if it has been mentioned or not as I just joined, but VDSL2 supports Vectoring, which as I understand it is basically scheduling transmission across the different pairs in say a 100 pair bundle. This way, cross talk based interference is run.
Quote Paul:"VDSL2 doesn't really add much functionality to ADSL2 other than the vastly expanded frequency range."
'Frequency Range' literally means Bandwidth ;) How much data you can transport over that - the Bitrate, which is what us IT folks generally mean when we say 'bandwidth' - really just comes down to how clever you are with math.
For Example:Interleaving in ADSL2 allows you to dedicate less of your bitrate to error correction, and hence make available more bandwidth.
Vectoring in VDSL2 allows the DSLAM some control over how much noise each pair will be subject to. Imagining we have Pairs A,B,C,D in a flat ribbon. Vectoring would ensure that Pairs A&C and B&D Transmit at the same time, but never A&B and C&D. Because of this, each individual pair is subject to less crosstalk, and hence more bandwidth is usable over the same physical medium, and a higher bitrate can be achieved by increasing the width of your modulation scheme (eg, moving from 256 Bins to 512 Bins as in ADSL2->2+) or changing the complexity of your scheme (eg, ADSL1->ADSL2).
Sorry If I've repeated someone,
Cheers,
Jarrad

Date: Fri, 12 Sep 2014 18:03:52 +1000
From: pbrooks-***@layer10.com.au
To: ***@lists.ausnog.net; ***@visser.name
Subject: Re: [AusNOG] Strange ADSL problem - troubleshooting / diagnosis advice wanted






On 10/09/2014 3:28 PM, Jeremy Visser
wrote:



On 10/09/14 14:39, Paul Brooks wrote:


ADSL2+ is supposed to re-train to a new sync rate seamlessly without
packet drops, whereas the older ADSL1 had to effectively drop the
line, re-sync, generate a new bitfield table per tone to cope with
changes to background noise and cross-talk that caused a need for a
re-sync.


I thought that was a feature of VDSL2, not ADSL2+.

I’d be interested to see a source on that as happy to be wrong.



Its actually goes back to ADSL2:



G.992.5 Jan 2009 ADSL2+



https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.992.5-200901-I!!ZPF-E&type=items





Page 'ii':

This Recommendation defines several optional capabilities and
features:

– transport of STM and/or ATM and/or Packets;

– transport of a network timing reference;

– multiple latency paths;

– multiple frame bearers;

– short initialization procedure;

– dynamic rate repartitioning;

– seamless rate adaptation;

- extended impulse noise protection;

- erasure decoding;

- virtual noise;

- impulse noise monitor.

"



G.992.3 April 2009 ADSL2:



https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.992.3-200904-I!!ZPF-E&type=items



Page 'ii':

"This Recommendation defines several optional capabilities and
features:

• transport of STM and/or ATM and/or Packets;

• transport of a network timing reference;

• multiple latency paths;

• multiple frame bearers;

• short initialization procedure;

• dynamic rate repartitioning;

• seamless rate adaptation;

• extended impulse noise protection;

• erasure decoding;

• virtual noise;

• impulse noise monitor."



"Relative to Recommendation ITU-T G.992.1, the following PMD-related
features have been added:

• New line diagnostics procedures available for both successful and
unsuccessful initialization

scenarios, loop characterization and trouble-shooting.

• Enhanced on-line reconfiguration capabilities including
bitswaps and seamless rate adaptation.

• Optional short initialization sequence for recovery from
errors or fast resumption of operation.

• Optional seamless rate adaptation with line rate changes
during showtime."



Clause 8.16:

"8.16 On-line reconfiguration of the PMD function

On-line reconfiguration of the PMD function is intended to allow
changes in the control parameters

without interruption of service and without errors (i.e., bitswap,
dynamic rate repartitioning and

seamless rate adaptation)."



VDSL2 doesn't really add much functionality to ADSL2 other than the
vastly expanded frequency range.



cheers...



Paul.

[John Edwards]

On 12 Sep 2014, at 6:05 pm, Jarrad Mitchell <***@outlook.com.au> wrote:

> I'm not sure if it has been mentioned or not as I just joined, but VDSL2 supports Vectoring, which as I understand it is basically scheduling transmission across the different pairs in say a 100 pair bundle.

It’s even cooler than that - the DSLAM uses the inherent crosstalk to correct the signal at the far end, by deliberately transmitting in a way that will constructively interfere.

The less appreciated part of the technology is that this calculation can’t be done in parallel. It needs to process the the complete symbol stream of every active port on the DSLAM in real time, in what is a 2^n-1 calculation for n connections in a binder. This also requires at least twice the backplane bandwidth to get the data into the vectoring processor and back into the line card.

> Quote Paul:
> "VDSL2 doesn't really add much functionality to ADSL2 other than the vastly expanded frequency range.”

Perhaps not at the PHY layer, but VDSL2 reboots the model and ends the need for PPPoE/LLC/ATM by defaulting to Packet-Transfer-Mode. While not a new standard, it mitigates the ATM tax we’ve been paying for 15 years on ADSL variants.

John

[Mark ZZZ Smith]

>________________________________
> From: Paul Brooks <pbrooks-***@layer10.com.au>
>To: ***@lists.ausnog.net; ***@visser.name
>Sent: Friday, 12 September 2014, 18:03
>Subject: Re: [AusNOG] Strange ADSL problem - troubleshooting / diagnosis advice wanted
>
>
>
>On 10/09/2014 3:28 PM, Jeremy Visser wrote:
>
>On 10/09/14 14:39, Paul Brooks wrote:
>>ADSL2+ is supposed to re-train to a new sync rate seamlessly without
packet drops, whereas the older ADSL1 had to effectively drop the
line, re-sync, generate a new bitfield table per tone to cope with
changes to background noise and cross-talk that caused a need for a
re-sync.
>>I thought that was a feature of VDSL2, not ADSL2+. I’d be interested to see a source on that as happy to be wrong.
>Its actually goes back to ADSL2:
>
>G.992.5 Jan 2009 ADSL2+
>
>https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.992.5-200901-I!!ZPF-E&type=items
>
>
>Page 'ii':
>This Recommendation defines several optional capabilities and
features:
>– transport of STM and/or ATM and/or Packets;
>– transport of a network timing reference;
>– multiple latency paths;
>– multiple frame bearers;
>– short initialization procedure;
>– dynamic rate repartitioning;
>– seamless rate adaptation;


So I've looked a bit into SRA in the past. I think theoretically it is a good idea.

[Jonathan Thorpe]

Hi Mark,

I agree with what you're saying regarding SRA being a mask for problems, but in my experience, the connection needs to be pretty poor before it can be considered bad enough for the ISP/Telstra to investigate. If SRA works as it says on the box, it could offer some relief of some problems that aren't within the scope of being considered bad enough to be investigated as a line fault.

Given that ADSL modems only train down to a slower speed, even during times of intermittent interference, this is not a problem that ISPs are likely to be keen to solve.

As an example, I have a client using iiNet that on a good day gets 2.5Mbps sync, which is about right for the distance. Often, there's an "event" that takes place (around the same time every day) that causes this to sync at below 1Mbps and the modem stays there until it's rebooted.

I can only presume that given this is in a light industrial area, there's electrical interference (i.e. as the result of a motor starting up) that's causing the connection to drop.

It would be nice if ISPs enabled this as a line profile option as we do with the likes of Annex M, but I don't hold my breath.

Kind Regards,
Jonathan

-----Original Message-----
From: AusNOG [mailto:ausnog-***@lists.ausnog.net] On Behalf Of Mark ZZZ Smith
Sent: Monday, 15 September 2014 11:35 AM
To: Paul Brooks; ***@lists.ausnog.net; ***@visser.name
Subject: Re: [AusNOG] Strange ADSL problem - troubleshooting / diagnosis advice wanted



>________________________________
> From: Paul Brooks <pbrooks-***@layer10.com.au>
>To: ***@lists.ausnog.net; ***@visser.name
>Sent: Friday, 12 September 2014, 18:03
>Subject: Re: [AusNOG] Strange ADSL problem - troubleshooting /
>diagnosis advice wanted
>
>
>
>On 10/09/2014 3:28 PM, Jeremy Visser wrote:
>
>On 10/09/14 14:39, Paul Brooks wrote:
>>ADSL2+ is supposed to re-train to a new sync rate seamlessly without
packet drops, whereas the older ADSL1 had to effectively drop the line, re-sync, generate a new bitfield table per tone to cope with changes to background noise and cross-talk that caused a need for a re-sync.
>>I thought that was a feature of VDSL2, not ADSL2+. I’d be interested to see a source on that as happy to be wrong.
>Its actually goes back to ADSL2:
>
>G.992.5 Jan 2009 ADSL2+
>
>https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.992.5-200901-
>I!!ZPF-E&type=items
>
>
>Page 'ii':
>This Recommendation defines several optional capabilities and
features:
>– transport of STM and/or ATM and/or Packets; – transport of a network
>timing reference; – multiple latency paths; – multiple frame bearers; –
>short initialization procedure; – dynamic rate repartitioning; –
>seamless rate adaptation;


So I've looked a bit into SRA in the past. I think theoretically it is a good idea. From what I recall it was an option on Ericsson DSLAMs on a per-line basis.

I think the trouble with it is that as above shows it is optional, and on the few modems I looked at that support it, it had to be manually enabled. Getting non-technical customers to do that successfully on a large scale would be impossible.

Secondly, I don't think the return for the time an ISP spends enabling it is high enough. Drop outs do annoy customers, however it also prompts them to contact the helpdesk, and that seems to be the way ISPs are in the habit of reactively identifying line faults. My understanding of SRA is that it would hide all or most dropouts from a "reactive support" ISP.

(I'd like to see ISPs proactively identifying line faults by either using their sessions database to identify lines/customers with lots of dropouts, or alternatively, start proactively walking through their DSLAM network looking for excessive dropouts etc. or dramatic changes in line characteristics. You'd either identify customers who don't realise they have a fault or save time of customers who do and need to find time to call the helpdesk. In either case you'd increase your customers' satisfaction with your service, and also be able to use those proactive fault calls to fill in quiet times in the helpdesk.)


>- extended impulse noise protection;
>- erasure decoding;
>- virtual noise;
>- impulse noise monitor.
>"
>
>G.992.3 April 2009 ADSL2:
>
>https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.992.3-200904-
>I!!ZPF-E&type=items
>
>Page 'ii':
>"This Recommendation defines several optional capabilities and
features:
>• transport of STM and/or ATM and/or Packets; • transport of a network
>timing reference; • multiple latency paths; • multiple frame bearers; •
>short initialization procedure; • dynamic rate repartitioning; •
>seamless rate adaptation; • extended impulse noise protection; •
>erasure decoding; • virtual noise; • impulse noise monitor."
>
>"Relative to Recommendation ITU-T G.992.1, the following PMD-related
features have been added:
>• New line diagnostics procedures available for both successful and
unsuccessful initialization
>scenarios, loop characterization and trouble-shooting.
>• Enhanced on-line reconfiguration capabilities including bitswaps and seamless rate adaptation.
>• Optional short initialization sequence for recovery from errors or fast resumption of operation.
>• Optional seamless rate adaptation with line rate changes during showtime."
>
>Clause 8.16:
>"8.16 On-line reconfiguration of the PMD function On-line
>reconfiguration of the PMD function is intended to allow
changes in the control parameters
>without interruption of service and without errors (i.e., bitswap,
dynamic rate repartitioning and
>seamless rate adaptation)."
>
>VDSL2 doesn't really add much functionality to ADSL2 other than the
vastly expanded frequency range.
>
>cheers...
>
>
>
>
>
>Paul.
>
>
>
>
>
>
>_______________________________________________
>AusNOG mailing list
>***@lists.ausnog.net
>http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
>
_______________________________________________
AusNOG mailing list
***@lists.ausnog.net
http://lists