[AusNOG] Cisco GRE Tunnel weirdness
Raphael, Tim
tim.raphael at zetta.com.au
Sat Jan 4 14:43:24 EST 2014
Initially I would agree this is an MTU issue though I have seen issues with (Cisco) GRE and Telstra WAN services before. I've had tunnels that just wouldn't come up in the first place so we resorted to IP-IP tunnelling. This goes to prove that Telstra has before done some traffic filtering - no idea why.
Regards,
Tim Raphael
> On 4 Jan 2014, at 9:01 am, "ausnog-request at lists.ausnog.net" <ausnog-request at lists.ausnog.net> wrote:
>
> Send AusNOG mailing list submissions to
> ausnog at lists.ausnog.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.ausnog.net/mailman/listinfo/ausnog
> or, via email, send a message with subject or body 'help' to
> ausnog-request at lists.ausnog.net
>
> You can reach the person managing the list at
> ausnog-owner at lists.ausnog.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of AusNOG digest..."
>
>
> Today's Topics:
>
> 1. Cisco GRE Tunnel weirdness (joe at apcs.com.au)
> 2. Re: Cisco GRE Tunnel weirdness (Nathan Brookfield)
> 3. Re: Cisco GRE Tunnel weirdness (joe at apcs.com.au)
> 4. Re: Cisco GRE Tunnel weirdness (Nathan Brookfield)
> 5. Re: Cisco GRE Tunnel weirdness (Nathan Brookfield)
> 6. Re: Cisco GRE Tunnel weirdness (Tony)
> 7. Re: Cisco GRE Tunnel weirdness (joe at apcs.com.au)
> 8. Port 32764 Remote Admin Vulnerability? (Brad Peczka)
> 9. Re: Rack Studs - AWESOME (Tom Storey)
> 10. Weekly Routing Table Report (Routing Analysis Role Account)
> 11. BGP Update Report (cidr-report at potaroo.net)
> 12. Re: Rack Studs - AWESOME (Mark ZZZ Smith)
> 13. Re: Rack Studs - AWESOME (Lloyd Wood)
> 14. Re: Port 32764 Remote Admin Vulnerability? (Tim March)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 03 Jan 2014 17:49:01 +1100
> From: joe at apcs.com.au
> To: ausnog at lists.ausnog.net
> Subject: [AusNOG] Cisco GRE Tunnel weirdness
> Message-ID: <2c4dccc7e164f24c4f368ed2080e0d04 at apcs.com.au>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Hi List,
>
> I have a GRE tunnel between 2 sites over a link limited to 1500 MTU.
>
> As such we have mtu set to 1440 and mss-adjust to 1400 on both ends.
> This is overly cautious probably but it was working.
>
> Anyway - it had been working quite fine for some time, but randomly we
> started seeing massive performance issues. Bandwidth throughput halved
> and ping times sky rocketed (~50ms to ~1000ms). We tried bringing down
> the tunnel and back up, no luck, and even power cycled each end (Cisco
> 3945's), no luck.
>
> We have confirmed that the config's had not been changed for weeks.
> Neither end had crashed and rebooted. The tunnel itself did not go down
> between 'working' and 'not working'. Performance and ping times via the
> tunnel endpoint address' is fine, proving (to me) that the networks
> between the 2 sites are not the issue, but the tunnel itself. No links
> are saturated, and CPU performance is quite tame (both before and during
> the issue)
>
> For now we have gone back to backup path but I haven't been able to
> find similar problems online, and my own Cisco tunnel experience leaves
> me empty so far.
>
> Has anyone experienced a similar issue? A working tunnel suddenly
> having major performance issues?
>
> Thanks,
> Joe
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 3 Jan 2014 06:51:15 +0000
> From: Nathan Brookfield <Nathan.Brookfield at simtronic.com.au>
> To: "joe at apcs.com.au" <joe at apcs.com.au>
> Cc: "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net>
> Subject: Re: [AusNOG] Cisco GRE Tunnel weirdness
> Message-ID: <754A5E8E-A519-4357-8174-16D8995C0B2D at simtronic.com.au>
> Content-Type: text/plain; charset="us-ascii"
>
> It sounds like an issue with a hop in the path. Have you tried iperf or similar tests outside of the tunnel to both end points?
>
> Kindest Regards,
> Nathan Brookfield
>
> Chief Executive Officer
> Simtronic Technologies Pty Ltd
>
> Web: http://simtronic.com.au
> Phone: 1300 592 330
> Fax: (02) 4749 4950
>
> On 3 Jan 2014, at 17:49, "joe at apcs.com.au<mailto:joe at apcs.com.au>" <joe at apcs.com.au<mailto:joe at apcs.com.au>> wrote:
>
> Hi List,
>
> I have a GRE tunnel between 2 sites over a link limited to 1500 MTU.
>
> As such we have mtu set to 1440 and mss-adjust to 1400 on both ends. This is overly cautious probably but it was working.
>
> Anyway - it had been working quite fine for some time, but randomly we started seeing massive performance issues. Bandwidth throughput halved and ping times sky rocketed (~50ms to ~1000ms). We tried bringing down the tunnel and back up, no luck, and even power cycled each end (Cisco 3945's), no luck.
>
> We have confirmed that the config's had not been changed for weeks. Neither end had crashed and rebooted. The tunnel itself did not go down between 'working' and 'not working'. Performance and ping times via the tunnel endpoint address' is fine, proving (to me) that the networks between the 2 sites are not the issue, but the tunnel itself. No links are saturated, and CPU performance is quite tame (both before and during the issue)
>
> For now we have gone back to backup path but I haven't been able to find similar problems online, and my own Cisco tunnel experience leaves me empty so far.
>
> Has anyone experienced a similar issue? A working tunnel suddenly having major performance issues?
>
> Thanks,
> Joe
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net<mailto:AusNOG at lists.ausnog.net>
> http://lists.ausnog.net/mailman/listinfo/ausnog
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140103/7a5c9e9c/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 03 Jan 2014 18:06:24 +1100
> From: joe at apcs.com.au
> To: Nathan Brookfield <Nathan.Brookfield at simtronic.com.au>
> Cc: ausnog at lists.ausnog.net
> Subject: Re: [AusNOG] Cisco GRE Tunnel weirdness
> Message-ID: <5db0c6904e87360f0666c63cd21a14ce at apcs.com.au>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Not specifically iperf but I was able to send 1500byte ping request with
> df bit set, outside of the tunnel, with no issues. (1501 bytes failed)
>
> This indicated to me that the path between the 2 sites should be OK. Let
> me know if you disagree?
>
>> On 2014-01-03 17:51, Nathan Brookfield wrote:
>> It sounds like an issue with a hop in the path. Have you tried iperf
>> or similar tests outside of the tunnel to both end points?
>>
>> Kindest Regards, Nathan Brookfield
>>
>> Chief Executive Officer
>> Simtronic Technologies Pty Ltd
>>
>> Web: http://simtronic.com.au [1]
>> Phone: 1300 592 330
>> Fax: (02) 4749 4950
>>
>> On 3 Jan 2014, at 17:49, "joe at apcs.com.au" <joe at apcs.com.au> wrote:
>>
>> Hi List,
>>
>> I have a GRE tunnel between 2 sites over a link limited to 1500 MTU.
>>
>> As such we have mtu set to 1440 and mss-adjust to 1400 on both ends.
>> This is overly cautious probably but it was working.
>>
>> Anyway - it had been working quite fine for some time, but randomly
>> we started seeing massive performance issues. Bandwidth throughput
>> halved and ping times sky rocketed (~50ms to ~1000ms). We tried
>> bringing down the tunnel and back up, no luck, and even power cycled
>> each end (Cisco 3945's), no luck.
>>
>> We have confirmed that the config's had not been changed for weeks.
>> Neither end had crashed and rebooted. The tunnel itself did not go
>> down between 'working' and 'not working'. Performance and ping times
>> via the tunnel endpoint address' is fine, proving (to me) that the
>> networks between the 2 sites are not the issue, but the tunnel itself.
>> No links are saturated, and CPU performance is quite tame (both before
>> and during the issue)
>>
>> For now we have gone back to backup path but I haven't been able to
>> find similar problems online, and my own Cisco tunnel experience
>> leaves me empty so far.
>>
>> Has anyone experienced a similar issue? A working tunnel suddenly
>> having major performance issues?
>>
>> Thanks,
>> Joe
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog [2]
>>
>>
>> Links:
>> ------
>> [1] http://simtronic.com.au
>> [2] http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 3 Jan 2014 07:07:34 +0000
> From: Nathan Brookfield <Nathan.Brookfield at simtronic.com.au>
> To: "joe at apcs.com.au" <joe at apcs.com.au>
> Cc: "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net>
> Subject: Re: [AusNOG] Cisco GRE Tunnel weirdness
> Message-ID:
> <C2CA75D1DFC40B4C818E07C656981703384051C5 at EX01.simtronic.com.au>
> Content-Type: text/plain; charset="utf-8"
>
> It doesn't sound like an MTU issue to me that's for sure.... Hmmm!
>
> Kindest Regards,
> Nathan Brookfield (VK2NAB)
>
> Chief Executive Officer
> Simtronic Technologies Pty Ltd
>
> Local: (02) 4749 4949 | Fax: (02) 4749 4950 | Direct: (02) 4749 4951
> Web: http://www.simtronic.com.au | E-mail: nathan.brookfield at simtronic.com.au
>
>
>
>
> -----Original Message-----
> From: joe at apcs.com.au [mailto:joe at apcs.com.au]
> Sent: Friday, 3 January 2014 6:06 PM
> To: Nathan Brookfield
> Cc: ausnog at lists.ausnog.net
> Subject: Re: [AusNOG] Cisco GRE Tunnel weirdness
>
> Not specifically iperf but I was able to send 1500byte ping request with df bit set, outside of the tunnel, with no issues. (1501 bytes failed)
>
> This indicated to me that the path between the 2 sites should be OK. Let me know if you disagree?
>
>> On 2014-01-03 17:51, Nathan Brookfield wrote:
>> It sounds like an issue with a hop in the path. Have you tried iperf
>> or similar tests outside of the tunnel to both end points?
>>
>> Kindest Regards, Nathan Brookfield
>>
>> Chief Executive Officer
>> Simtronic Technologies Pty Ltd
>>
>> Web: http://simtronic.com.au [1]
>> Phone: 1300 592 330
>> Fax: (02) 4749 4950
>>
>> On 3 Jan 2014, at 17:49, "joe at apcs.com.au" <joe at apcs.com.au> wrote:
>>
>> Hi List,
>>
>> I have a GRE tunnel between 2 sites over a link limited to 1500 MTU.
>>
>> As such we have mtu set to 1440 and mss-adjust to 1400 on both ends.
>> This is overly cautious probably but it was working.
>>
>> Anyway - it had been working quite fine for some time, but randomly
>> we started seeing massive performance issues. Bandwidth throughput
>> halved and ping times sky rocketed (~50ms to ~1000ms). We tried
>> bringing down the tunnel and back up, no luck, and even power cycled
>> each end (Cisco 3945's), no luck.
>>
>> We have confirmed that the config's had not been changed for weeks.
>> Neither end had crashed and rebooted. The tunnel itself did not go
>> down between 'working' and 'not working'. Performance and ping times
>> via the tunnel endpoint address' is fine, proving (to me) that the
>> networks between the 2 sites are not the issue, but the tunnel itself.
>> No links are saturated, and CPU performance is quite tame (both before
>> and during the issue)
>>
>> For now we have gone back to backup path but I haven't been able to
>> find similar problems online, and my own Cisco tunnel experience
>> leaves me empty so far.
>>
>> Has anyone experienced a similar issue? A working tunnel suddenly
>> having major performance issues?
>>
>> Thanks,
>> Joe
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog [2]
>>
>>
>> Links:
>> ------
>> [1] http://simtronic.com.au
>> [2] http://lists.ausnog.net/mailman/listinfo/ausnog
>
> ------------------------------
>
> Message: 5
> Date: Fri, 3 Jan 2014 07:08:47 +0000
> From: Nathan Brookfield <Nathan.Brookfield at simtronic.com.au>
> To: Nathan Brookfield <Nathan.Brookfield at simtronic.com.au>,
> "joe at apcs.com.au" <joe at apcs.com.au>
> Cc: "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net>
> Subject: Re: [AusNOG] Cisco GRE Tunnel weirdness
> Message-ID:
> <C2CA75D1DFC40B4C818E07C656981703384051EE at EX01.simtronic.com.au>
> Content-Type: text/plain; charset="us-ascii"
>
> When you were seeing this strangeness over the GRE, what was 'show proc cpu' looking like?
>
> Kindest Regards,
> Nathan Brookfield (VK2NAB)
>
> Chief Executive Officer
> Simtronic Technologies Pty Ltd
>
> Local: (02) 4749 4949 | Fax: (02) 4749 4950 | Direct: (02) 4749 4951
> Web: http://www.simtronic.com.au | E-mail: nathan.brookfield at simtronic.com.au
>
>
>
>
> -----Original Message-----
> From: AusNOG [mailto:ausnog-bounces at lists.ausnog.net] On Behalf Of Nathan Brookfield
> Sent: Friday, 3 January 2014 6:08 PM
> To: joe at apcs.com.au
> Cc: ausnog at lists.ausnog.net
> Subject: Re: [AusNOG] Cisco GRE Tunnel weirdness
>
> It doesn't sound like an MTU issue to me that's for sure.... Hmmm!
>
> Kindest Regards,
> Nathan Brookfield (VK2NAB)
>
> Chief Executive Officer
> Simtronic Technologies Pty Ltd
>
> Local: (02) 4749 4949 | Fax: (02) 4749 4950 | Direct: (02) 4749 4951
> Web: http://www.simtronic.com.au | E-mail: nathan.brookfield at simtronic.com.au
>
>
>
>
> -----Original Message-----
> From: joe at apcs.com.au [mailto:joe at apcs.com.au]
> Sent: Friday, 3 January 2014 6:06 PM
> To: Nathan Brookfield
> Cc: ausnog at lists.ausnog.net
> Subject: Re: [AusNOG] Cisco GRE Tunnel weirdness
>
> Not specifically iperf but I was able to send 1500byte ping request with df bit set, outside of the tunnel, with no issues. (1501 bytes failed)
>
> This indicated to me that the path between the 2 sites should be OK. Let me know if you disagree?
>
>> On 2014-01-03 17:51, Nathan Brookfield wrote:
>> It sounds like an issue with a hop in the path. Have you tried iperf
>> or similar tests outside of the tunnel to both end points?
>>
>> Kindest Regards, Nathan Brookfield
>>
>> Chief Executive Officer
>> Simtronic Technologies Pty Ltd
>>
>> Web: http://simtronic.com.au [1]
>> Phone: 1300 592 330
>> Fax: (02) 4749 4950
>>
>> On 3 Jan 2014, at 17:49, "joe at apcs.com.au" <joe at apcs.com.au> wrote:
>>
>> Hi List,
>>
>> I have a GRE tunnel between 2 sites over a link limited to 1500 MTU.
>>
>> As such we have mtu set to 1440 and mss-adjust to 1400 on both ends.
>> This is overly cautious probably but it was working.
>>
>> Anyway - it had been working quite fine for some time, but randomly
>> we started seeing massive performance issues. Bandwidth throughput
>> halved and ping times sky rocketed (~50ms to ~1000ms). We tried
>> bringing down the tunnel and back up, no luck, and even power cycled
>> each end (Cisco 3945's), no luck.
>>
>> We have confirmed that the config's had not been changed for weeks.
>> Neither end had crashed and rebooted. The tunnel itself did not go
>> down between 'working' and 'not working'. Performance and ping times
>> via the tunnel endpoint address' is fine, proving (to me) that the
>> networks between the 2 sites are not the issue, but the tunnel itself.
>> No links are saturated, and CPU performance is quite tame (both before
>> and during the issue)
>>
>> For now we have gone back to backup path but I haven't been able to
>> find similar problems online, and my own Cisco tunnel experience
>> leaves me empty so far.
>>
>> Has anyone experienced a similar issue? A working tunnel suddenly
>> having major performance issues?
>>
>> Thanks,
>> Joe
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog [2]
>>
>>
>> Links:
>> ------
>> [1] http://simtronic.com.au
>> [2] http://lists.ausnog.net/mailman/listinfo/ausnog
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 2 Jan 2014 23:19:54 -0800 (PST)
> From: Tony <td_miles at yahoo.com>
> To: "joe at apcs.com.au" <joe at apcs.com.au>, "ausnog at lists.ausnog.net"
> <ausnog at lists.ausnog.net>
> Subject: Re: [AusNOG] Cisco GRE Tunnel weirdness
> Message-ID:
> <1388733594.77252.YahooMailNeo at web164501.mail.gq1.yahoo.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Seemingly unrelated, but today two separate customer issues that have come to me:
>
> 1. A 2M p2p Telstra service where usable MTU across the link has dropped
> overnight to approx 200 bytes in size (from 1500). This caused OSPF to drop on the link and forced traffic onto a 3G backup service (fault logged with carrier)
>
>
> 2. Another customer reported that GRE has stopped working to their firewall that we provide IP connectivitiy to. Nothing changed by us, nothing changed by them, they are scheduling a reboot of the firewall.
>
> To top it off I've been having wierd issues on my link at home for the last couple of days (resold Telstra DSL port) and have just checked and for some reason the MTU on the virtual-access interface on our LNS for my service is not 1460 instead of the 1500 that it was previously. Setting "adjust-mss" on the LAN of my router has resolved my inability to access web stuff that was timing out, but leaves me no closer to knowing WHY the MTU has suddenly changed.
>
>
>
> Coincidence or conspiracy, who knows....
>
>
> As someone else said, try monitoring CPU & interface utilisation (graph via SNMP) to see whether that is taking a hit during your times of slowness. Is this a GRE tunnel over Internet or something else ? What speed ? 3945's are grunty enough to handle a fair amount of GRE traffic, but not if they are sustaining/filtering a DDOS attack at the same time.
>
>
>
> regards,
> Tony.
>
>
>
>
> ________________________________
> From: "joe at apcs.com.au" <joe at apcs.com.au>
> To: ausnog at lists.ausnog.net
> Sent: Friday, 3 January 2014 4:49 PM
> Subject: [AusNOG] Cisco GRE Tunnel weirdness
>
>
> Hi List,
>
> ? I have a GRE tunnel between 2 sites over a link limited to 1500 MTU.
>
> ? As such we have mtu set to 1440 and mss-adjust to 1400 on both ends.
> This is overly cautious probably but it was working.
>
> ? Anyway - it had been working quite fine for some time, but randomly we
> started seeing massive performance issues. Bandwidth throughput halved
> and ping times sky rocketed (~50ms to ~1000ms). We tried bringing down
> the tunnel and back up, no luck, and even power cycled each end (Cisco
> 3945's), no luck.
>
> ? We have confirmed that the config's had not been changed for weeks.
> Neither end had crashed and rebooted. The tunnel itself did not go down
> between 'working' and 'not working'. Performance and ping times via the
> tunnel endpoint address' is fine, proving (to me) that the networks
> between the 2 sites are not the issue, but the tunnel itself. No links
> are saturated, and CPU performance is quite tame (both before and during
> the issue)
>
> ? For now we have gone back to backup path but I haven't been able to
> find similar problems online, and my own Cisco tunnel experience leaves
> me empty so far.
>
> ? Has anyone experienced a similar issue? A working tunnel suddenly
> having major performance issues?
>
> Thanks,
> Joe
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140102/4a1de892/attachment-0001.html>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 03 Jan 2014 21:14:24 +1100
> From: joe at apcs.com.au
> To: Tony <td_miles at yahoo.com>
> Cc: ausnog at lists.ausnog.net
> Subject: Re: [AusNOG] Cisco GRE Tunnel weirdness
> Message-ID: <0ca400f575e59dee14b3f60c8bed3e02 at apcs.com.au>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Thanks for the info. Some of the network in the middle does appear to
> be Telstra related, but not directly in their xDSL/EU side of things.
> Could be a coincidence but helpful none-the-less.
>
> Traffic is roughly 100-130mbit during peak times. Both devices are SNMP
> monitored, CPU stayed steady before and during the problems (well, the
> CPU dropped in a similar ratio to the bandwidth throughput while the
> problem was occurring), and this was both ends. show proc cpu, I have to
> admit I only look at the summary at the top to get overall CPU usage,
> which matched our SNMP monitoring indicating only 10-15% load during the
> problems.
>
> Tony - if it is not too much trouble, can you shoot me a message when
> you see your problems disappear? Coming into the weekend we are OK with
> the backup path as it is not as mission critical (thank god for
> redundancies) so we will be researching and attempting a few things over
> the weekend. Would just be good to know when those problems subside, see
> if it coincides with our problems.
>
> Thanks,
> Joe
>
>> On 2014-01-03 18:19, Tony wrote:
>> Seemingly unrelated, but today two separate customer issues that have
>> come to me:
>>
>> 1. A 2M p2p Telstra service where usable MTU across the link has
>> dropped overnight to approx 200 bytes in size (from 1500). This caused
>> OSPF to drop on the link and forced traffic onto a 3G backup service
>> (fault logged with carrier)
>>
>> 2. Another customer reported that GRE has stopped working to their
>> firewall that we provide IP connectivitiy to. Nothing changed by us,
>> nothing changed by them, they are scheduling a reboot of the firewall.
>>
>> To top it off I've been having wierd issues on my link at home for the
>> last couple of days (resold Telstra DSL port) and have just checked
>> and for some reason the MTU on the virtual-access interface on our LNS
>> for my service is not 1460 instead of the 1500 that it was previously.
>> Setting "adjust-mss" on the LAN of my router has resolved my inability
>> to access web stuff that was timing out, but leaves me no closer to
>> knowing WHY the MTU has suddenly changed.
>>
>> Coincidence or conspiracy, who knows....
>>
>> As someone else said, try monitoring CPU & interface utilisation
>> (graph via SNMP) to see whether that is taking a hit during your times
>> of slowness. Is this a GRE tunnel over Internet or something else ?
>> What speed ? 3945's are grunty enough to handle a fair amount of GRE
>> traffic, but not if they are sustaining/filtering a DDOS attack at the
>> same time.
>>
>> regards,
>> Tony.
>>
>> -------------------------
>> FROM: "joe at apcs.com.au" <joe at apcs.com.au>
>> TO: ausnog at lists.ausnog.net
>> SENT: Friday, 3 January 2014 4:49 PM
>> SUBJECT: [AusNOG] Cisco GRE Tunnel weirdness
>>
>> Hi List,
>>
>> I have a GRE tunnel between 2 sites over a link limited to 1500 MTU.
>>
>> As such we have mtu set to 1440 and mss-adjust to 1400 on both ends.
>> This is overly cautious probably but it was working.
>>
>> Anyway - it had been working quite fine for some time, but randomly
>> we
>> started seeing massive performance issues. Bandwidth throughput halved
>>
>> and ping times sky rocketed (~50ms to ~1000ms). We tried bringing down
>>
>> the tunnel and back up, no luck, and even power cycled each end (Cisco
>>
>> 3945's), no luck.
>>
>> We have confirmed that the config's had not been changed for weeks.
>> Neither end had crashed and rebooted. The tunnel itself did not go
>> down
>> between 'working' and 'not working'. Performance and ping times via
>> the
>> tunnel endpoint address' is fine, proving (to me) that the networks
>> between the 2 sites are not the issue, but the tunnel itself. No links
>>
>> are saturated, and CPU performance is quite tame (both before and
>> during
>> the issue)
>>
>> For now we have gone back to backup path but I haven't been able to
>> find similar problems online, and my own Cisco tunnel experience
>> leaves
>> me empty so far.
>>
>> Has anyone experienced a similar issue? A working tunnel suddenly
>> having major performance issues?
>>
>> Thanks,
>> Joe
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog [1]
>>
>>
>>
>> Links:
>> ------
>> [1] http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
> ------------------------------
>
> Message: 8
> Date: Fri, 3 Jan 2014 23:18:12 +0800
> From: Brad Peczka <brad at bradpeczka.com>
> To: "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net>
> Subject: [AusNOG] Port 32764 Remote Admin Vulnerability?
> Message-ID:
> <DD45AC21DAF70543807CC4719639BAE302BE038A5792 at bpfs01.bp.local>
> Content-Type: text/plain; charset="us-ascii"
>
> Evening all,
>
> This cropped up on my radar this evening: https://github.com/elvanderb/TCP-32764
>
> There's some better coverage in an Ars article here: http://arstechnica.com/security/2014/01/backdoor-in-wireless-dsl-routers-lets-attacker-reset-router-get-admin/
>
> In a nutshell, it looks like there's an exploit in a range of Consumer and SOHO routers, whereby an unauthenticated administrative interface is listening on port 32764. Some models are only listening on the LAN interface, some models also listen to the WAN interface. On the right model, you can reset the username/password to one of your choosing and enable the remote administration interface.
>
> Would be interesting to see if there's a notable uptick in port scans for this over the coming days... ;-)
>
> Regards,
> -Brad.
>
> ------------------------------
>
> Message: 9
> Date: Fri, 3 Jan 2014 15:44:01 +0000
> From: Tom Storey <tom at snnap.net>
> To: Robert Hudson <hudrob at gmail.com>
> Cc: "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net>
> Subject: Re: [AusNOG] Rack Studs - AWESOME
> Message-ID:
> <CAFDgZgWCCAU7mk0TSstdhGgaJ8Wyv0a96UE2EzqJhZDAOUwLdg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Ive found the trick is to install them up-down rather than left-right.
> Might seem counter-intuitive, but Ive had far fewer issues doing it
> that way.
>
> And yes, use one of those little tools and you will save yourself
> mountains of headache and pain. The company I work for buys 100 packs
> of cage nuts from Minkels, and 1 is included in every single packet.
>
>
>> On 2 January 2014 22:13, Robert Hudson <hudrob at gmail.com> wrote:
>> That is a good point, they do work better when inserted using the right
>> tool.
>>
>> Though I have also had problems with traditional style cage nuts binding to
>> each other when used in adjacent rack holes. That is damned annoying.
>>
>>> On 02/01/2014 9:19 PM, "Luke Smith" <luke at smith.name> wrote:
>>>
>>> Before you get too down on traditional cage nuts be sure you know how to
>>> us the tool thats in almost every rack nut sack....
>>>
>>> http://www.youtube.com/watch?v=SRvVtzvlaIM
>>>
>>> No need for pinched fingers and broken nails.
>>>
>>> _______________________________________________
>>> AusNOG mailing list
>>> AusNOG at lists.ausnog.net
>>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
> ------------------------------
>
> Message: 10
> Date: Sat, 4 Jan 2014 04:12:32 +1000 (EST)
> From: Routing Analysis Role Account <cscora at apnic.net>
> To: lacnog at lacnic.net, caribnog-discuss at caribnog.org,
> gt-as at abranet.org.br, trnog at trnog.org, ausnog at lists.ausnog.net
> Subject: [AusNOG] Weekly Routing Table Report
> Message-ID: <201401031812.s03ICWZ8023071 at thyme.rand.apnic.net>
>
> This is an automated weekly mailing describing the state of the Internet
> Routing Table as seen from APNIC's router in Japan.
>
> The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
> TRNOG, CaribNOG and the RIPE Routing Working Group.
>
> Daily listings are sent to bgp-stats at lists.apnic.net
>
> For historical data, please see http://thyme.rand.apnic.net.
>
> If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.
>
> Routing Table Report 04:00 +10GMT Sat 04 Jan, 2014
>
> Report Website: http://thyme.rand.apnic.net
> Detailed Analysis: http://thyme.rand.apnic.net/current/
>
> Analysis Summary
> ----------------
>
> BGP routing table entries examined: 477051
> Prefixes after maximum aggregation: 190299
> Deaggregation factor: 2.51
> Unique aggregates announced to Internet: 236730
> Total ASes present in the Internet Routing Table: 45828
> Prefixes per ASN: 10.41
> Origin-only ASes present in the Internet Routing Table: 35488
> Origin ASes announcing only one prefix: 16270
> Transit ASes present in the Internet Routing Table: 5982
> Transit-only ASes present in the Internet Routing Table: 177
> Average AS path length visible in the Internet Routing Table: 4.6
> Max AS path length visible: 53
> Max AS path prepend of ASN ( 50404) 51
> Prefixes from unregistered ASNs in the Routing Table: 2654
> Unregistered ASNs in the Routing Table: 627
> Number of 32-bit ASNs allocated by the RIRs: 5637
> Number of 32-bit ASNs visible in the Routing Table: 4358
> Prefixes from 32-bit ASNs in the Routing Table: 13805
> Number of bogon 32-bit ASNs visible in the Routing Table: 1
> Special use prefixes present in the Routing Table: 0
> Prefixes being announced from unallocated address space: 1728
> Number of addresses announced to Internet: 2661253372
> Equivalent to 158 /8s, 159 /16s and 128 /24s
> Percentage of available address space announced: 71.9
> Percentage of allocated address space announced: 71.9
> Percentage of available address space allocated: 100.0
> Percentage of address space in use by end-sites: 95.4
> Total number of prefixes smaller than registry allocations: 166280
>
> APNIC Region Analysis Summary
> -----------------------------
>
> Prefixes being announced by APNIC Region ASes: 113324
> Total APNIC prefixes after maximum aggregation: 34178
> APNIC Deaggregation factor: 3.32
> Prefixes being announced from the APNIC address blocks: 115676
> Unique aggregates announced from the APNIC address blocks: 48507
> APNIC Region origin ASes present in the Internet Routing Table: 4870
> APNIC Prefixes per ASN: 23.75
> APNIC Region origin ASes announcing only one prefix: 1210
> APNIC Region transit ASes present in the Internet Routing Table: 841
> Average APNIC Region AS path length visible: 4.6
> Max APNIC Region AS path length visible: 28
> Number of APNIC region 32-bit ASNs visible in the Routing Table: 797
> Number of APNIC addresses announced to Internet: 730192064
> Equivalent to 43 /8s, 133 /16s and 216 /24s
> Percentage of available APNIC address space announced: 85.3
>
> APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431
> (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319,
> 58368-59391, 63488-63999, 131072-133631
> APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8,
> 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8,
> 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
> 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
> 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
> 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
> 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
> 222/8, 223/8,
>
> ARIN Region Analysis Summary
> ----------------------------
>
> Prefixes being announced by ARIN Region ASes: 163539
> Total ARIN prefixes after maximum aggregation: 81812
> ARIN Deaggregation factor: 2.00
> Prefixes being announced from the ARIN address blocks: 164167
> Unique aggregates announced from the ARIN address blocks: 75856
> ARIN Region origin ASes present in the Internet Routing Table: 15928
> ARIN Prefixes per ASN: 10.31
> ARIN Region origin ASes announcing only one prefix: 5986
> ARIN Region transit ASes present in the Internet Routing Table: 1673
> Average ARIN Region AS path length visible: 4.1
> Max ARIN Region AS path length visible: 24
> Number of ARIN region 32-bit ASNs visible in the Routing Table: 53
> Number of ARIN addresses announced to Internet: 1074982272
> Equivalent to 64 /8s, 18 /16s and 237 /24s
> Percentage of available ARIN address space announced: 56.9
>
> ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106
> (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153
> 3354-4607, 4865-5119, 5632-6655, 6912-7466
> 7723-8191, 10240-12287, 13312-15359, 16384-17407
> 18432-20479, 21504-23551, 25600-26591,
> 26624-27647, 29696-30719, 31744-33791
> 35840-36863, 39936-40959, 46080-47103
> 53248-55295, 62464-63487, 393216-394239
> ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8,
> 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8,
> 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8,
> 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8,
> 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8,
> 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8,
> 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8,
> 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8,
> 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8,
> 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8,
> 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8,
> 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8,
> 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8,
> 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8,
> 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8,
> 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8,
> 216/8,
>
> RIPE Region Analysis Summary
> ----------------------------
>
> Prefixes being announced by RIPE Region ASes: 120105
> Total RIPE prefixes after maximum aggregation: 61366
> RIPE Deaggregation factor: 1.96
> Prefixes being announced from the RIPE address blocks: 123796
> Unique aggregates announced from the RIPE address blocks: 79325
> RIPE Region origin ASes present in the Internet Routing Table: 17586
> RIPE Prefixes per ASN: 7.04
> RIPE Region origin ASes announcing only one prefix: 8315
> RIPE Region transit ASes present in the Internet Routing Table: 2840
> Average RIPE Region AS path length visible: 5.0
> Max RIPE Region AS path length visible: 53
> Number of RIPE region 32-bit ASNs visible in the Routing Table: 2550
> Number of RIPE addresses announced to Internet: 654989700
> Equivalent to 39 /8s, 10 /16s and 89 /24s
> Percentage of available RIPE address space announced: 95.2
>
> RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614
> (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631
> 6656-6911, 8192-9215, 12288-13311, 15360-16383
> 20480-21503, 24576-25599, 28672-29695
> 30720-31743, 33792-35839, 38912-39935
> 40960-45055, 47104-52223, 56320-58367
> 59392-61439, 61952-62463, 196608-200191
> RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8,
> 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8,
> 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8,
> 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8,
> 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8,
> 193/8, 194/8, 195/8, 212/8, 213/8, 217/8,
>
> LACNIC Region Analysis Summary
> ------------------------------
>
> Prefixes being announced by LACNIC Region ASes: 53686
> Total LACNIC prefixes after maximum aggregation: 10068
> LACNIC Deaggregation factor: 5.33
> Prefixes being announced from the LACNIC address blocks: 59163
> Unique aggregates announced from the LACNIC address blocks: 27528
> LACNIC Region origin ASes present in the Internet Routing Table: 2059
> LACNIC Prefixes per ASN: 28.73
> LACNIC Region origin ASes announcing only one prefix: 552
> LACNIC Region transit ASes present in the Internet Routing Table: 404
> Average LACNIC Region AS path length visible: 4.9
> Max LACNIC Region AS path length visible: 35
> Number of LACNIC region 32-bit ASNs visible in the Routing Table: 950
> Number of LACNIC addresses announced to Internet: 147393336
> Equivalent to 8 /8s, 201 /16s and 11 /24s
> Percentage of available LACNIC address space announced: 87.9
>
> LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247,
> 61440-61951, 262144-263679 plus ERX transfers
> LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
> 191/8, 200/8, 201/8,
>
> AfriNIC Region Analysis Summary
> -------------------------------
>
> Prefixes being announced by AfriNIC Region ASes: 11799
> Total AfriNIC prefixes after maximum aggregation: 2616
> AfriNIC Deaggregation factor: 4.51
> Prefixes being announced from the AfriNIC address blocks: 12521
> Unique aggregates announced from the AfriNIC address blocks: 4190
> AfriNIC Region origin ASes present in the Internet Routing Table: 698
> AfriNIC Prefixes per ASN: 17.94
> AfriNIC Region origin ASes announcing only one prefix: 207
> AfriNIC Region transit ASes present in the Internet Routing Table: 143
> Average AfriNIC Region AS path length visible: 4.7
> Max AfriNIC Region AS path length visible: 24
> Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 8
> Number of AfriNIC addresses announced to Internet: 48539392
> Equivalent to 2 /8s, 228 /16s and 167 /24s
> Percentage of available AfriNIC address space announced: 48.2
>
> AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers
> AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8,
>
> APNIC Region per AS prefix count summary
> ----------------------------------------
>
> ASN No of nets /20 equiv MaxAgg Description
> 4766 2945 11558 952 Korea Telecom
> 17974 2731 902 88 PT Telekomunikasi Indonesia
> 7545 2121 319 112 TPG Telecom Limited
> 4755 1812 392 191 TATA Communications formerly
> 9829 1563 1255 41 National Internet Backbone
> 9583 1295 101 537 Sify Limited
> 9498 1235 309 71 BHARTI Airtel Ltd.
> 7552 1226 1080 13 Viettel Corporation
> 4808 1141 2120 348 CNCGROUP IP network China169
> 24560 1098 382 167 Bharti Airtel Ltd., Telemedia
>
> Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC
>
> ARIN Region per AS prefix count summary
> ---------------------------------------
>
> ASN No of nets /20 equiv MaxAgg Description
> 6389 3029 3688 53 BellSouth.net Inc.
> 22773 2319 2939 138 Cox Communications Inc.
> 1785 2146 686 131 PaeTec Communications, Inc.
> 18566 2050 379 178 MegaPath Corporation
> 20115 1682 1665 593 Charter Communications
> 4323 1627 1081 411 tw telecom holdings, inc.
> 701 1506 11144 778 MCI Communications Services,
> 30036 1376 310 572 Mediacom Communications Corp
> 7018 1307 17746 847 AT&T Services, Inc.
> 6983 1294 756 580 ITC^Deltacom
>
> Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN
>
> RIPE Region per AS prefix count summary
> ---------------------------------------
>
> ASN No of nets /20 equiv MaxAgg Description
> 8402 1841 544 16 OJSC "Vimpelcom"
> 34984 1361 243 227 TELLCOM ILETISIM HIZMETLERI A
> 20940 1207 455 907 Akamai International B.V.
> 31148 1012 45 20 Freenet Ltd.
> 13188 922 100 26 TOV "Bank-Inform"
> 6849 857 361 35 JSC "Ukrtelecom"
> 8551 856 370 38 Bezeq International-Ltd
> 6830 770 2327 423 Liberty Global Operations B.V
> 12479 685 798 53 France Telecom Espana SA
> 35228 551 246 16 Telefonica UK Limited
>
> Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE
>
> LACNIC Region per AS prefix count summary
> -----------------------------------------
>
> ASN No of nets /20 equiv MaxAgg Description
> 28573 3438 1839 91 NET Servi?os de Comunica??o S
> 10620 2691 435 209 Telmex Colombia S.A.
> 18881 1790 908 20 Global Village Telecom
> 7303 1743 1163 230 Telecom Argentina S.A.
> 8151 1371 2857 429 Uninet S.A. de C.V.
> 11830 868 364 15 Instituto Costarricense de El
> 27947 858 93 89 Telconet S.A
> 7738 813 1562 37 Telemar Norte Leste S.A.
> 6503 792 434 60 Axtel, S.A.B. de C.V.
> 6147 780 373 27 Telefonica del Peru S.A.A.
>
> Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC
>
> AfriNIC Region per AS prefix count summary
> ------------------------------------------
>
> ASN No of nets /20 equiv MaxAgg Description
> 36998 1857 112 5 Sudanese Mobile Telephone (ZA
> 24863 893 338 26 Link Egypt (Link.NET)
> 6713 600 653 27 Office National des Postes et
> 8452 450 956 9 TE-AS
> 24835 299 144 9 Vodafone Data
> 3741 247 921 209 Internet Solutions
> 29571 240 21 14 Cote d'Ivoire Telecom
> 36992 226 505 27 ETISALAT MISR
> 15706 219 32 6 Sudatel (Sudan Telecom Co. Lt
> 29975 192 668 21 Vodacom
>
> Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC
>
> Global Per AS prefix count summary
> ----------------------------------
>
> ASN No of nets /20 equiv MaxAgg Description
> 28573 3438 1839 91 NET Servi?os de Comunica??o S
> 6389 3029 3688 53 BellSouth.net Inc.
> 4766 2945 11558 952 Korea Telecom
> 17974 2731 902 88 PT Telekomunikasi Indonesia
> 10620 2691 435 209 Telmex Colombia S.A.
> 22773 2319 2939 138 Cox Communications Inc.
> 1785 2146 686 131 PaeTec Communications, Inc.
> 7545 2121 319 112 TPG Telecom Limited
> 18566 2050 379 178 MegaPath Corporation
> 36998 1857 112 5 Sudanese Mobile Telephone (ZA
>
> Complete listing at http://thyme.rand.apnic.net/current/data-ASnet
>
> Global Per AS Maximum Aggr summary
> ----------------------------------
>
> ASN No of nets Net Savings Description
> 6389 3029 2976 BellSouth.net Inc.
> 17974 2731 2643 PT Telekomunikasi Indonesia
> 10620 2691 2482 Telmex Colombia S.A.
> 22773 2319 2181 Cox Communications Inc.
> 1785 2146 2015 PaeTec Communications, Inc.
> 7545 2121 2009 TPG Telecom Limited
> 4766 2945 1993 Korea Telecom
> 18566 2050 1872 MegaPath Corporation
> 36998 1857 1852 Sudanese Mobile Telephone (ZA
> 8402 1841 1825 OJSC "Vimpelcom"
>
> Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet
>
> List of Unregistered Origin ASNs (Global)
> -----------------------------------------
>
> Bad AS Designation Network Transit AS Description
> 30662 UNALLOCATED 8.2.129.0/24 3356 Level 3 Communicatio
> 14728 UNALLOCATED 8.8.192.0/23 3356 Level 3 Communicatio
> 14728 UNALLOCATED 8.8.196.0/22 3356 Level 3 Communicatio
> 14728 UNALLOCATED 8.8.200.0/23 3356 Level 3 Communicatio
> 14728 UNALLOCATED 8.8.202.0/23 3356 Level 3 Communicatio
> 53506 UNALLOCATED 8.17.102.0/23 2828 XO Communications
> 62828 UNALLOCATED 8.21.130.0/24 4323 tw telecom holdings,
> 62850 UNALLOCATED 8.25.147.0/24 46887 Lightower Fiber Netw
> 20260 UNALLOCATED 8.25.160.0/24 3356 Level 3 Communicatio
> 20260 UNALLOCATED 8.25.161.0/24 3356 Level 3 Communicatio
>
> Complete listing at http://thyme.rand.apnic.net/current/data-badAS
>
> Advertised Unallocated Addresses
> --------------------------------
>
> Network Origin AS Description
> 23.90.128.0/18 27418 OUTOFWALL INC.
> 23.91.0.0/19 40676 Psychz Networks
> 23.91.14.0/24 40676 Psychz Networks
> 23.91.32.0/19 36315 Servpac Inc.
> 23.91.80.0/20 21560 Netstream Communications, LLC
> 23.91.96.0/20 37958 Beijing Blue I.T Technologies
> 23.91.112.0/21 32475 SingleHop
> 23.91.120.0/21 36351 SoftLayer Technologies Inc.
> 23.91.160.0/19 36493 FIBERNETICS CORPORATION
> 23.91.160.0/22 36493 FIBERNETICS CORPORATION
>
> Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA
>
> Number of prefixes announced per prefix length (Global)
> -------------------------------------------------------
>
> /1:0 /2:0 /3:0 /4:0 /5:0 /6:0
> /7:0 /8:16 /9:11 /10:31 /11:92 /12:254
> /13:473 /14:937 /15:1636 /16:12856 /17:6785 /18:11435
> /19:23329 /20:33183 /21:35757 /22:50722 /23:44179 /24:253010
> /25:798 /26:953 /27:433 /28:47 /29:71 /30:28
> /31:0 /32:15
>
> Advertised prefixes smaller than registry allocations
> -----------------------------------------------------
>
> ASN No of nets Total ann. Description
> 18566 2005 2050 MegaPath Corporation
> 36998 1822 1857 Sudanese Mobile Telephone (ZA
> 6389 1699 3029 BellSouth.net Inc.
> 22773 1563 2319 Cox Communications Inc.
> 8402 1530 1841 OJSC "Vimpelcom"
> 30036 1217 1376 Mediacom Communications Corp
> 1785 1163 2146 PaeTec Communications, Inc.
> 11492 1152 1189 CABLE ONE, INC.
> 6983 1036 1294 ITC^Deltacom
> 22561 977 1252 CenturyTel Internet Holdings,
>
> Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos
>
> Number of /24s announced per /8 block (Global)
> ----------------------------------------------
>
> 1:935 2:843 3:3 4:16 5:840 6:21
> 8:638 12:1872 13:3 14:898 15:9 16:3
> 17:20 18:24 20:36 23:653 24:1752 27:1691
> 31:1514 32:44 33:2 34:5 36:111 37:1944
> 38:917 39:5 40:182 41:3329 42:246 44:14
> 46:2116 47:10 49:707 50:857 52:12 54:44
> 55:3 56:4 57:26 58:1141 59:590 60:369
> 61:1501 62:1202 63:1966 64:4375 65:2334 66:4133
> 67:2096 68:1084 69:3307 70:907 71:510 72:2023
> 74:2584 75:321 76:304 77:1146 78:1028 79:682
> 80:1283 81:1084 82:645 83:737 84:649 85:1215
> 86:400 87:1012 88:523 89:1581 90:152 91:5719
> 92:636 93:1614 94:2112 95:1466 96:531 97:351
> 98:1081 99:41 100:33 101:701 103:3890 105:534
> 106:142 107:348 108:548 109:2036 110:978 111:1140
> 112:602 113:814 114:767 115:1052 116:1015 117:833
> 118:1222 119:1292 120:325 121:774 122:1884 123:1290
> 124:1398 125:1456 128:654 129:236 130:356 131:665
> 132:341 133:159 134:320 135:73 136:277 137:271
> 138:354 139:174 140:202 141:353 142:551 143:405
> 144:499 145:92 146:566 147:428 148:789 149:361
> 150:152 151:481 152:410 153:208 154:50 155:526
> 156:316 157:418 158:287 159:809 160:360 161:465
> 162:976 163:232 164:663 165:586 166:281 167:639
> 168:1037 169:123 170:1162 171:185 172:12 173:1692
> 174:670 175:551 176:1361 177:2596 178:1924 179:345
> 180:1604 181:931 182:1424 183:479 184:633 185:1179
> 186:2790 187:1463 188:1957 189:1283 190:7318 191:16
> 192:7048 193:5431 194:4025 195:3404 196:1346 197:1063
> 198:4815 199:5527 200:6057 201:2557 202:9008 203:8926
> 204:4537 205:2638 206:2909 207:2820 208:3955 209:3708
> 210:3080 211:1630 212:2170 213:1952 214:869 215:83
> 216:5448 217:1723 218:608 219:323 220:1271 221:587
> 222:349 223:565
>
> End of report
>
>
> ------------------------------
>
> Message: 11
> Date: Fri, 3 Jan 2014 22:00:02 GMT
> From: cidr-report at potaroo.net
> To: cidr-report at potaroo.net
> Cc: nanog at nanog.org, routing-wg at ripe.net, ausnog at ausnog.net,
> apops at apops.net, eof-list at ripe.net, afnog at afnog.org
> Subject: [AusNOG] BGP Update Report
> Message-ID: <201401032200.s03M02Dh090087 at wattle.apnic.net>
>
> BGP Update Report
> Interval: 26-Dec-13 -to- 02-Jan-14 (7 days)
> Observation Point: BGP Peering with AS131072
>
> TOP 20 Unstable Origin AS
> Rank ASN Upds % Upds/Pfx AS-Name
> 1 - AS30783 47548 2.8% 1398.5 -- RSD Rased Maral Ava Jonoob JSC
> 2 - AS35819 43311 2.6% 95.6 -- MOBILY-AS Etihad Etisalat Company (Mobily)
> 3 - AS14287 37356 2.2% 691.8 -- TRIAD-TELECOM - Triad Telecom, Inc.
> 4 - AS8402 34786 2.1% 63.8 -- CORBINA-AS OJSC "Vimpelcom"
> 5 - AS9829 32777 1.9% 41.1 -- BSNL-NIB National Internet Backbone
> 6 - AS3816 27847 1.6% 85.9 -- COLOMBIA TELECOMUNICACIONES S.A. ESP
> 7 - AS7552 24698 1.5% 30.5 -- VIETEL-AS-AP Viettel Corporation
> 8 - AS34744 24085 1.4% 47.2 -- GVM S.C. GVM SISTEM 2003 S.R.L.
> 9 - AS12615 21761 1.3% 253.0 -- GCN-AS Global Communication Net Plc
> 10 - AS13118 21052 1.2% 1913.8 -- ASN-YARTELECOM OJSC Rostelecom
> 11 - AS18403 19971 1.2% 46.9 -- FPT-AS-AP The Corporation for Financing & Promoting Technology
> 12 - AS41691 19090 1.1% 636.3 -- SUMTEL-AS-RIPE Summa Telecom LLC
> 13 - AS4775 18133 1.1% 1295.2 -- GLOBE-TELECOM-AS Globe Telecoms
> 14 - AS7029 16799 1.0% 22.9 -- WINDSTREAM - Windstream Communications Inc
> 15 - AS45899 14532 0.9% 44.9 -- VNPT-AS-VN VNPT Corp
> 16 - AS49687 14054 0.8% 116.1 -- REQ SC RoSite Equipment SRL
> 17 - AS59217 12723 0.8% 12723.0 -- AZONNELIMITED-AS-AP Azonne Limited
> 18 - AS1221 12698 0.8% 453.5 -- ASN-TELSTRA Telstra Pty Ltd
> 19 - AS17974 12494 0.7% 6.2 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
> 20 - AS11976 12183 0.7% 143.3 -- FIDN - Fidelity Communication International Inc.
>
>
> TOP 20 Unstable Origin AS (Updates per announced prefix)
> Rank ASN Upds % Upds/Pfx AS-Name
> 1 - AS59217 12723 0.8% 12723.0 -- AZONNELIMITED-AS-AP Azonne Limited
> 2 - AS54465 8392 0.5% 8392.0 -- QPM-AS-1 - QuickPlay Media Inc.
> 3 - AS41189 4661 0.3% 4661.0 -- ICONCEPT-AS Faroese Telecom
> 4 - AS28477 3573 0.2% 3573.0 -- UNIVERSIDAD AUTONOMA DEL ESTADO DE MORELOS
> 5 - AS22747 3018 0.2% 3018.0 -- TCIS - TulsaConnect, LLC
> 6 - AS30437 4983 0.3% 2491.5 -- GE-MS003 - General Electric Company
> 7 - AS45808 2215 0.1% 2215.0 -- UTP-MY Bandar Seri Iskandar
> 8 - AS32244 6538 0.4% 2179.3 -- LIQUID-WEB-INC - Liquid Web, Inc.
> 9 - AS62431 2023 0.1% 2023.0 -- NCSC-IE-AS National Cyber Security Centre
> 10 - AS13118 21052 1.2% 1913.8 -- ASN-YARTELECOM OJSC Rostelecom
> 11 - AS19406 3784 0.2% 1892.0 -- TWRS-MA - Towerstream I, Inc.
> 12 - AS18570 1806 0.1% 1806.0 -- ECHOSTAR-BROADCASTING-CORPORATION - EchoStar Broadcasting Corperation
> 13 - AS7202 8706 0.5% 1741.2 -- FAMU - Florida A & M University
> 14 - AS60932 1699 0.1% 1699.0 -- AVAYE-BANDAR DADE PARDAZAN AVAYE BANDAR COMPANY
> 15 - AS47870 1515 0.1% 1515.0 -- NEWBAY-ASN NewBay Software Ltd
> 16 - AS6629 10358 0.6% 1479.7 -- NOAA-AS - NOAA
> 17 - AS60345 2945 0.2% 1472.5 -- NBITI-AS Nahjol Balagheh International Research Institution
> 18 - AS30783 47548 2.8% 1398.5 -- RSD Rased Maral Ava Jonoob JSC
> 19 - AS40877 2640 0.2% 1320.0 -- PSCMETALS - PSC Metals, Inc.
> 20 - AS22895 1318 0.1% 1318.0 -- CMR1122 - CMR LLC
>
>
> TOP 20 Unstable Prefixes
> Rank Prefix Upds % Origin AS -- AS Name
> 1 - 109.161.64.0/20 21042 1.2% AS13118 -- ASN-YARTELECOM OJSC Rostelecom
> 2 - 103.243.164.0/22 12723 0.7% AS59217 -- AZONNELIMITED-AS-AP Azonne Limited
> 3 - 192.58.232.0/24 10327 0.6% AS6629 -- NOAA-AS - NOAA
> 4 - 85.249.160.0/20 9944 0.6% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC
> 7 - 89.221.206.0/24 8646 0.5% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC
> 8 - 206.152.15.0/24 8392 0.5% AS54465 -- QPM-AS-1 - QuickPlay Media Inc.
> 9 - 208.73.244.0/22 7423 0.4% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.
> 10 - 208.88.232.0/22 7418 0.4% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.
> 11 - 216.162.0.0/20 7417 0.4% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.
> 12 - 208.78.116.0/22 7414 0.4% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.
> 13 - 208.70.20.0/22 7377 0.4% AS14287 -- TRIAD-TELECOM - Triad Telecom, Inc.
> 14 - 148.218.0.0/16 6887 0.4% AS11172 -- Alestra, S. de R.L. de C.V.
> AS28477 -- UNIVERSIDAD AUTONOMA DEL ESTADO DE MORELOS
> 15 - 67.210.190.0/23 6681 0.4% AS11976 -- FIDN - Fidelity Communication International Inc.
> 16 - 183.87.110.0/24 5642 0.3% AS45194 -- SIPL-AS Syscon Infoway Pvt. Ltd., Internet Service Provider, India.
> 17 - 103.2.238.0/24 5640 0.3% AS45194 -- SIPL-AS Syscon Infoway Pvt. Ltd., Internet Service Provider, India.
> 18 - 115.170.128.0/17 5506 0.3% AS4847 -- CNIX-AP China Networks Inter-Exchange
> 19 - 165.156.25.0/24 4974 0.3% AS30437 -- GE-MS003 - General Electric Company
> 20 - 193.34.104.0/22 4661 0.3% AS41189 -- ICONCEPT-AS Faroese Telecom
>
> Details at http://bgpupdates.potaroo.net
> ------------------------------------
> Copies of this report are mailed to:
> nanog at nanog.org
> eof-list at ripe.net
> apops at apops.net
> routing-wg at ripe.net
> afnog at afnog.org
>
>
> ------------------------------
>
> Message: 12
> Date: Fri, 3 Jan 2014 14:27:16 -0800 (PST)
> From: Mark ZZZ Smith <markzzzsmith at yahoo.com.au>
> To: Luke Smith <luke at smith.name>, "ausnog at lists.ausnog.net"
> <ausnog at lists.ausnog.net>
> Subject: Re: [AusNOG] Rack Studs - AWESOME
> Message-ID:
> <1388788036.99528.YahooMailNeo at web161901.mail.bf1.yahoo.com>
> Content-Type: text/plain; charset=iso-8859-1
>
>
>
>
>
>
>> ________________________________
>> From: Luke Smith <luke at smith.name>
>> To: "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net>
>> Sent: Thursday, 2 January 2014 9:19 PM
>> Subject: Re: [AusNOG] Rack Studs - AWESOME
>>
>>
>>
>> Before you get too down on traditional cage nuts be sure you know how to us the tool thats in almost every rack nut sack....?
>>
>>
>> http://www.youtube.com/watch?v=SRvVtzvlaIM
>>
>>
>>
>> No need for pinched fingers and broken nails.
>
> I was taught in the early 1990s that cage nuts had slightly different sized tabs on them, and the shorter tab was to be oriented towards the inside of the rack. This allowed them to be more easily inserted/removed with your hands, as the shorter tab side had more play in it. I've noticed most cage nuts are like this since, other than cheaper ones, which you can usually tell by the thinner clip metal and slightly sharper edges on the clips and nuts.
>
>
>
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
> ------------------------------
>
> Message: 13
> Date: Sat, 4 Jan 2014 09:37:46 +1100
> From: Lloyd Wood <lloyd.wood at yahoo.co.uk>
> To: Tom Storey <tom at snnap.net>
> Cc: "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net>
> Subject: Re: [AusNOG] Rack Studs - AWESOME
> Message-ID: <465E2F67-9C4E-44E2-B57D-9D5FB8552E69 at yahoo.co.uk>
> Content-Type: text/plain; charset=us-ascii
>
> Apparently that's using them as intended; I've seen old racks where there are depressions between holes where the tabs are supposed to rest.
>
> But up-down only works where there's some space to work in. I doubt the original designers envisaged the rack cramming that we're all used to.
>
> And what's with all the metric and imperial screw/nut sizes? Gah.
>
>> On 4 Jan 2014, at 02:44, Tom Storey <tom at snnap.net> wrote:
>>
>> Ive found the trick is to install them up-down rather than left-right.
>> Might seem counter-intuitive, but Ive had far fewer issues doing it
>> that way.
>
>
> ------------------------------
>
> Message: 14
> Date: Sat, 04 Jan 2014 11:58:16 +1100
> From: Tim March <march.tim at gmail.com>
> To: ausnog at lists.ausnog.net
> Subject: Re: [AusNOG] Port 32764 Remote Admin Vulnerability?
> Message-ID: <52C75CA8.4020908 at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
>
> Yup...
>
> http://threatpost.com/probes-against-linksys-backdoor-port-surging/103410
>
> https://isc.sans.org/forums/diary/Scans+Increase+for+New+Linksys+Backdoor+32764+TCP+/17336
>
>
> T.
>
>> On 4/01/14 2:18 AM, Brad Peczka wrote:
>> Evening all,
>>
>> This cropped up on my radar this evening: https://github.com/elvanderb/TCP-32764
>>
>> There's some better coverage in an Ars article here: http://arstechnica.com/security/2014/01/backdoor-in-wireless-dsl-routers-lets-attacker-reset-router-get-admin/
>>
>> In a nutshell, it looks like there's an exploit in a range of Consumer and SOHO routers, whereby an unauthenticated administrative interface is listening on port 32764. Some models are only listening on the LAN interface, some models also listen to the WAN interface. On the right model, you can reset the username/password to one of your choosing and enable the remote administration interface.
>>
>> Would be interesting to see if there's a notable uptick in port scans for this over the coming days... ;-)
>>
>> Regards,
>> -Brad.
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>
> --
> PGP/GNUPG Public Key: http://d3vnu11.com/pub.key
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
> ------------------------------
>
> End of AusNOG Digest, Vol 23, Issue 5
> *************************************
>
________________________________
ZettaServe Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this email by mistake and delete this email from your system. Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. ZettaServe Pty Ltd accepts no liability for any damage caused by any virus transmitted by this email.
More information about the AusNOG
mailing list