On going micro-breaks / DNS issues with DNS on Cable (Wellington)

Forums › One New Zealand (including Vodafone, WxC, Farmside) › On going micro-breaks / DNS issues with DNS on Cable (Wellington)

gzcwnk

23 posts

Geek

#214085 27-Apr-2017 11:43

Hi,

I am trying to figure out an ongoing issue with my cable modem service. For a while now I have monitored it with AWS's route53 alarm service, and I see outages (and experience them). I also get DNS failures where for some minutes, my bind9 server cannot seem to get any results for 5 or so minutes then works fine it serves cached info no issues. So while new web connections fail, at the same time however existing connections continue to work fine. Right now I am a bit stumped but I know as soon as I ring Vodafone they will say nothing is wrong (they always do) as I am trying to collect some evidence/proof. So is anyone else in the Wellington area seeing something similar?

DjShadow

4088 posts

Uber Geek

ID Verified

Trusted

#1771179 27-Apr-2017 11:46

Are you on the oldschool cable service or FibreX (DOCSIS 3.1)?

tieke

674 posts

Ultimate Geek

ID Verified

#1771192 27-Apr-2017 12:11

Where are you located? Island Bay for instance has had major ongoing problems for years.

I suspect you are more likely to have problems with the new FibreX service, as my old cable connection had no problems but the new one has relatively frequent dropouts.

If you are on FibreX, do you have a dynamic or static IP?

gzcwnk

23 posts

Geek

#1771213 27-Apr-2017 12:33

"cable" since about 1999 or so, Ngaio. We were supposed to get Fibre in June2016 but now apparently its 2020 and that is a maybe.

Smokeping isnt really showing an issue. I installed it many years ago and pinged each of Clear's routers all the way to the west coast but these days much of it is now prevented. Clear then were painful, I had them back numerous times and the techie finally told me the router at the end of the street was designed for 600ppl and there were 2500+ on it so I was wasting their time.

http://202.78.148.43/cgi-bin/smokeping.cgi?target=_charts

Whatever is going on its getting worse ie more frequent.

JimmyCorrigan

49 posts

Geek

#1774276 2-May-2017 14:18

We are in Northland, Wellington and been on the VF cable for about a year. (Switched from Spark adsl, which was rubbish. Cable speeds far superior)

Had largely been OK, but in recent months have experienced intermittent bursts of service outage for typically 1-5 mins. The supplied modem/router (Technicolor) pretty much always shows it is connected 'downstream'. I have periodically reset it, and usually after it revives, it reconnects - although this is likely a coincidence of timing.

I have not made any support calls to VF. The outages are never for very long, and there is no discernible pattern. So it is more of an annoyance, especially if i'm working from home, than anything severe.

Roll on the fibre!

antoniosk

2358 posts

Uber Geek

ID Verified

Trusted

Lifetime subscriber

#1774298 2-May-2017 15:05

Its pretty clear reading these conversations in this forum and others, that the connection between the modem and the core cable network is being dropped and re-established on demand. This is ok for pull traffic - typical web stuff - but for anything working on a permanent open inbound connection not so good.

Key thing is that the connection isnt being 'dropped' per se, just going dormant, and what people are seeing is something akin to an 'outage'.

This feels to me like vodafone needs to take a different approach to diagnosing the experience and finding out why the sessions are being dropped. Normal fault processes deal with things like line breaks, disabled services and so on.

Intermittent behaviour is trickier and not something for basic level 2 support to address.

@mikehales.... over to you

________

Antoniosk

MikeHales

615 posts

Ultimate Geek

Trusted

#1774304 2-May-2017 15:12

It's a fair question and funnily enough I've had 2 conversations about this very thing today. So, while I may not have an answer now, we're definitely aware of it and exploring how to address.

gzcwnk

23 posts

Geek

#1774575 2-May-2017 20:29

99% sure it isnt going dormant from lack of use, I odnt think my wife and son ever get off it, LOL. It is certainly random, the strange thing is I'd expect smokeping to pick it up but it isnt yet AWS does. Its got me wondering if the issue is more "backbone" than local, hence why I asked "aloud".

@jimmy "Had largely been OK, but in recent months have experienced intermittent bursts of service outage for typically 1-5 mins"

That is an interesting comment, Ive looked at each break I still have an email for and its 60seconds or 900 seconds, no other variation.

========

You are receiving this email because your Amazon CloudWatch Alarm "graywitch-test" in the US East - N. Virginia region has entered the ALARM state, because "Threshold Crossed: 1 datapoint (0.0) was less than the threshold (1.0)." at "Sunday 30 April, 2017 04:19:03 UTC".

View this alarm in the AWS Management Console:
https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#s=Alarms&alarm=graywitch-test

Alarm Details:
- Name:                       graywitch-test
- Description:                graywitch-test
- State Change:               OK -> ALARM
- Reason for State Change:    Threshold Crossed: 1 datapoint (0.0) was less than the threshold (1.0).
- Timestamp:                  Sunday 30 April, 2017 04:19:03 UTC
- AWS Account:                40xxxxxx
Threshold:
- The alarm is in the ALARM state when the metric is LessThanThreshold 1.0 for 900 seconds.

Monitored Metric:
- MetricNamespace:                     AWS/Route53
- MetricName:                          HealthCheckStatus
- Dimensions:                          [HealthCheckId = 8131282d-ce05-4830-8fa9-66ebc03257ef]
- Period:                              900 seconds
- Statistic:                           Minimum
- Unit:                                not specified

State Change Actions:
- OK:
- ALARM: [arn:aws:sns:us-east-1:402xxxxxxx:graywitch]
- INSUFFICIENT_DATA:

========

You are receiving this email because your Amazon CloudWatch Alarm "grwaywitch2-awsroute53-88ab54f0-8578-44ec-b1fa-8d657fd01039-Low-HealthCheckStatus" in the US East - N. Virginia region has entered the ALARM state, because "Threshold Crossed: 1 datapoint (0.0) was less than the threshold (1.0)." at "Monday 20 March, 2017 23:37:32 UTC".

View this alarm in the AWS Management Console:
https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#s=Alarms&alarm=grwaywitch2-awsroute53-88ab54f0-8578-44ec-b1fa-8d657fd01039-Low-HealthCheckStatus

Alarm Details:
- Name:                       grwaywitch2-awsroute53-88ab54f0-8578-44ec-b1fa-8d657fd01039-Low-HealthCheckStatus
- Description:
- State Change:               OK -> ALARM
- Reason for State Change:    Threshold Crossed: 1 datapoint (0.0) was less than the threshold (1.0).
- Timestamp:                  Monday 20 March, 2017 23:37:32 UTC
- AWS Account:                402xxxxxx

Threshold:
- The alarm is in the ALARM state when the metric is LessThanThreshold 1.0 for 60 seconds.

Monitored Metric:
- MetricNamespace:                     AWS/Route53
- MetricName:                          HealthCheckStatus
- Dimensions:                          [HealthCheckId = 88ab54f0-8578-44ec-b1fa-8d657fd01039]
- Period:                              60 seconds
- Statistic:                           Minimum
- Unit:                                not specified

State Change Actions:
- OK:
- ALARM: [arn:aws:sns:us-east-1:402xxxxxxxxxxxx:graywitch]
- INSUFFICIENT_DATA:

========

You are receiving this email because your Amazon CloudWatch Alarm "graywitch-test" in the US East - N. Virginia region has entered the ALARM state, because "Threshold Crossed: 1 datapoint (0.0) was less than the threshold (1.0)." at "Friday 18 November, 2016 01:20:03 UTC".

View this alarm in the AWS Management Console:
https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#s=Alarms&alarm=graywitch-test

Alarm Details:
- Name:                       graywitch-test
- Description:                graywitch-test
- State Change:               OK -> ALARM
- Reason for State Change:    Threshold Crossed: 1 datapoint (0.0) was less than the threshold (1.0).
- Timestamp:                  Friday 18 November, 2016 01:20:03 UTC
- AWS Account:                4025xxxxxxxxxx

Threshold:
- The alarm is in the ALARM state when the metric is LessThanThreshold 1.0 for 900 seconds.

Monitored Metric:
- MetricNamespace:            AWS/Route53
- MetricName:                 HealthCheckStatus
- Dimensions:                 [HealthCheckId = 8131282d-ce05-4830-8fa9-66ebc03257ef]
- Period:                     900 seconds
- Statistic:                  Minimum
- Unit:                       not specified

State Change Actions:
- OK:
- ALARM: [arn:aws:sns:us-east-1:402xxxxxxx7:graywitch]
- INSUFFICIENT_DATA:

=======

This 60 or 900sec might however just be a function of AWS in some way but I cant immediately see how, Im not that experienced with it.

For these sort of breaks smokeping should show a break also,

http://202.78.148.43/cgi-bin/smokeping.cgi?target=DNS.Vodafone

So I smokeping vodafone's DNS server so if it was my local link I think I'd see that 15min break but I do not, hence head scratch time.