[AusNOG] Re Cisco Catalyst 3560 CG PoE
Carl Gough
carl at mobsource.com
Mon Feb 17 21:21:37 EST 2014
Anyone in need of 2x #cisco #catalyst 3560 CG PoE ?
contact offline
0425 266 764
carl at mobsource.com
On 17 Feb 2014, at 17:33, 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. Re: steering inbound BGP (Telstra) (Ben)
> 2. Re: steering inbound BGP (Telstra) (Tony)
> 3. Re: steering inbound BGP (Telstra) (Brad Gould)
> 4. Re: NTT packet loss?? (Bruce Forster)
> 5. Re: NTP Reflection coming in over Equinix IX (James Braunegg)
> 6. Re: NTP Reflection coming in over Equinix IX (James Braunegg)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 17 Feb 2014 18:42:51 +1300
> From: Ben <ben at meh.net.nz>
> To: Matthew Moyle-Croft <mmc at mmc.com.au>
> Cc: "AusNOG \(AusNOG at lists.ausnog.net\)" <AusNOG at lists.ausnog.net>
> Subject: Re: [AusNOG] steering inbound BGP (Telstra)
> Message-ID: <20140217054251.GM10059 at meh.net.nz>
> Content-Type: text/plain; charset=us-ascii
>
> On Sun, Feb 16, 2014 at 08:55:33PM -0800, Matthew Moyle-Croft wrote:
>>
>> On 16 Feb 2014, at 8:48 pm, Ben <ben at meh.net.nz> wrote:
>>
>> ...
>>
>>>>>
>>>>
>>>> "Fallback routes"?
>>>
>>> Err, advertising with less prepending for the same subnet.
>>
>> This is about more specifics.
>>
>>>
>>>> More specifics are a common tool used to TE traffic. The issue is if your /24s aren't globally advertised.
>>>
>>> Ok, so say Telstra advertise routes at Equninx Los Angeles, and the other provider doesn't advertise at Equninix Los Angeles, then
>>> people close to that are going to often have local preference set to send via peering exchange. But say they have a low end router
>>> for peering, and theey decide to strip /24s, or default route+peering routes. (the same can apply for domestic traffic, but it's
>>> more significant and more obvious for international)
>>
>> If they're stripping /24s and/or have default then they're going to be getting to the interwebz via a transit provider who WILL have full routes because they're clearly not big enough to have routers that cope with being in the DFZ.
>
> Not necessarily. I've been doing some lookups, and struggling to find examples of places that Vocus and NTT aren't at, but Telstra are, or
> common local preference for provider type isuses. I figure an example of where it's not working international would work best.
>
>
>>>
>>> If you advertise a /23 to Telstra, and /23 and two /24s to your other provider, then when Telstra receive this traffic what are they
>>> meant to do with it? Is that clearer?
>> They'll follow the /24s toward where you're advertising them. Not ideal, but Telstra have decided to not offer fairly standard tools (BGP communities) so my empathy for them is as close to zero as you can get.
>
> Say you have a 100 megabit pipe with Telstra, and a gigabit pipe with Vocus, and you were getting 200 megabit/sec for a file coming internationally from a Telstra
> peer in say London by advertising a /23 to Telstra, and two /24s to Vocus -- yeah wishful thinking, but say Vocus shut down their linx peer -- right now LINX is showing
> for his subnet as:
>
> https://stats.linx.net/cgi-pub/xlg.pl?run=true&site=LINX-London&query_type=+BGP&address=202.128.102.1&Submit=Submit
>
>
> So it's only Vocus and Telstra at least, with lots of prepends to Telstra. So Telstra are carrying the traffic.. now along the way should they pass it off to Vocus, or should they
> just keep carrying it? Right thinking generally dictates that traffic should stay within Telstra to the end destination, otherwise some infarious party could steal the traffic, and
> some parties block receiving routes that they're advertising -- but that isn't necessarily goign to hold over for more specific routes. Say they do pass it on Vocus, then you'll
> bypass the rate limit of the link. If they don't, then you don't fix the initial issue.
>
> And unless all providers are at all the same internet exchanges and with the same peering agreements this will happen to some degree.
>
>> From what he said it sounded like he wasn't trying to gently shift traffic, but rather to move all traffic off of the secondary link.
>
>>>
>>>
>>>> The main issue is - if your other provider(s) don't have good domestic Australian connectivity, but again, I kind of assume anyone doing this has some clue and/or deserves some failure based learning.
>>>
>>> Maybe I don't understand the problem completely. From my understanding the idea was to get rid of all traffic off the fallback link, unless there's an actual outage, whilst still
>>> advertising BGP routes. That in itself is not acheivable from what I can tell. And by advertising more specficially I can't see any advantage to just prepending normally. If telstra
>>> do accept the /24 over the /23, and send to the customer regardless, and still advertise out the /23 then there is a chance for misdirected traffic either going to the customer via
>>> their alternative provider, or still going through their normal link.
>>
>> Again, prepending is irrelevant. /24s will always win as they are more specific. If you're not clear on that I'd do some reading up on routing.
>
> Yeh sure so the /24 wins. But that's not the issue - the issue that once traffic has come in Telstra's netowrk, they really should send it through to him. And if it does go via Vocus
> (which there is some chance of) then that means that Telstra are carrying traffic that may be over the capacity of their link.
>
> You can't expect providers to have global rate limits over their whole network at every location, so usually individual links are charged for. So it basically bypasses charging.
>
>
> It'd be even more significant if he wanted to prefer Telstra over Vocus, and much easier to come up with examples that actually would be problematic -
>
> Vocus advertise his subnet in New Zealand over APE, in Auckland, so easy straight peering - and I know for a fact that there are providers in New Zealand that have APE routes and
> domestic but don't have full international tables - they will send traffic over APE to him, if any routes exist via APE/Vocus. I don't know for sure what they'd do if you advertised
> a /24 via Telstra and a /23 via Vocus.
>
> Ben
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 16 Feb 2014 21:45:35 -0800 (PST)
> From: Tony <td_miles at yahoo.com>
> To: Joshua D'Alton <joshua at railgun.com.au>, Chris Gibbs
> <Chris.Gibbs at gosford.nsw.gov.au>
> Cc: "AusNOG \(AusNOG at lists.ausnog.net\)" <AusNOG at lists.ausnog.net>
> Subject: Re: [AusNOG] steering inbound BGP (Telstra)
> Message-ID:
> <1392615935.92201.YahooMailNeo at web164502.mail.gq1.yahoo.com>
> Content-Type: text/plain; charset="utf-8"
>
> I've done this in the past (but don't claim to be an expert). Track a BGP prefix on one of the links and if it dissapears start advertising BGP routes on the alternate link. You may be wondering what stops the tracked prefix from appearing via the backup link and never going down, the answer was that the primary BGP provider was configured for "domestic routes" and the backup provider was configured for "default only" so that the only service the tracked /16 would appear from was the primary link.
>
> From memory the reason for doing this was that the backup link was a lot smaller in comparison to the primary one, so was only to be used in the "emergency" situation (it was a DSL2 service backing up a 10M fibre, the backup link have also had a small per MB data allowance on it). Yes, it was a small customer with a single /24 (their own one from ages ago) and this is how they wanted it to work. They were aware of the failover times involved and were happy with this.
>
> Many strange and bizarre things are possible if you think hard enough about how to do them. This doesn't always mean they are good things to do but as long as you don't bust anything feel free to be creative !
>
>
> regards,
> Tony.
>
>
>
>
> ________________________________
> From: Joshua D'Alton <joshua at railgun.com.au>
> To: Chris Gibbs <Chris.Gibbs at gosford.nsw.gov.au>
> Cc: "AusNOG (AusNOG at lists.ausnog.net)" <AusNOG at lists.ausnog.net>
> Sent: Monday, 17 February 2014 1:15 PM
> Subject: Re: [AusNOG] steering inbound BGP (Telstra)
>
>
>
> I could be wrong but BGP just doesn't support what you're wanting, and even more so no carrier is ever really going to work in the way you describe. It should never make sense (for a carrier) to not prefer their own routes (which are directly connected, ie admin dist 1), vs those of their peers (even if settlement free, admin dist 1+N), even if communities were involved (i believe telstra do use communities internally between telstra/telstraglobal/reach).
>
> Even if you advertised /24s telstra would still use their own learned routes (from you) rather than peer learned routes (from your alternate upstream), as designed BGP.
>
> I don't know for sure it is default behaviour for TWI, but I believe it is default for... the internet in general.
>
> I think the only way to achieve what you want would be to engineer the system such that nothing is advertised to telstra, and only advertised if the other link goes down. I can think of a few ways to do this, but keeping in mind BGP announce times, it wouldn't be a 100% uptime.
>
> Good luck with the traffic engineering, there are definitely a few onlist that are experts.
>
>
>
> On Mon, Feb 17, 2014 at 1:59 PM, Chris Gibbs <Chris.Gibbs at gosford.nsw.gov.au> wrote:
>
> Hey all,
>> ?
>> We currently utilise Telstra Internet Direct services for our primary inbound for AS38236, I would like to move to using Telstra as the least preferred and swap to another provider for inbound.
>> ?
>> When I tested the swap, the majority of domestic looking glasses were confirming inbound through our preferred inbound. However Telstra always seems to prefer their own routes instead of peer learnt; even after setting either as-prepend or MED. A Telstra engineer confirmed this.
>> ?
>> My question is pretty much is there any other way to steer inbound traffic to us through Telstra? (without grabbing a /23 and advertising more specific 2 x /24s or using communities, which Telstra doesn?t support)
>> ?
>> The only other alternative would be to swap providers at our DR site, and we originally had issues getting a service installed there.
>> ?
>> Does anyone also know if this is the default behaviour through Telstra Wholesale Internet?
>> ?
>> Cheers ,
>> Chris Gibbs
>> Network and Security Engineer | Information Management & Technology
>> Gosford City Council
>> (PO Box 21)
>> Gosford NSW?2250
>> P? (02) 43258888
>> M? 0408 222 496
>> E? Chris.Gibbs at gosford.nsw.gov.au
>> ?
>> ? gosford.nsw.gov.au
>> ?
>> ?
>>
>> ________________________________
>> The information contained in this email may be confidential.
>> You should only
> disclose, re-transmit, copy, distribute, act in reliance on or commercialise the
> information if you are authorised to do so. Gosford City Council does not
> represent, warrant or guarantee that the communication is free of errors, virus
> or interference.
>> Gosford City Council complies with the
> Privacy and
>> Personal Information Protection Act (1998).?See Council's Privacy
> Statement
>> ________________________________
>>
>> _______________________________________________
>> 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140216/506825c2/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 17 Feb 2014 05:56:41 +0000
> From: Brad Gould <bradley at internode.com.au>
> To: Ben <ben at meh.net.nz>, Matthew Moyle-Croft <mmc at mmc.com.au>
> Cc: "AusNOG \(AusNOG at lists.ausnog.net\)" <AusNOG at lists.ausnog.net>
> Subject: Re: [AusNOG] steering inbound BGP (Telstra)
> Message-ID:
> <2CE8D38BC62EB541A15E1B767F5889239A20DAA9 at EXCHMBX-ADL2-01.staff.internode.com.au>
>
> Content-Type: text/plain; charset="us-ascii"
>
> BGP has limited knobs. Its the hand we are are dealt. One way of traffic engineering is advertising variable length subnets to space you own. It has limitations and advantages.
>
> Another method is buying two equal bandwidth paths to the internet off different providers. Again, offers limitations and advantages. One advantage is that its simple. Prepend lots on one and you have active/standby.
>
> The complication comes where people hope that they can achieve novel outcomes, simply, cheaply and quickly. At best you can only choose two, and often only one.
>
> Brad
>
>
>
>
>
>
> -----Original Message-----
> From: AusNOG [mailto:ausnog-bounces at lists.ausnog.net] On Behalf Of Ben
> Sent: Monday, 17 February 2014 4:13 PM
> To: Matthew Moyle-Croft
> Cc: AusNOG (AusNOG at lists.ausnog.net)
> Subject: Re: [AusNOG] steering inbound BGP (Telstra)
>
> On Sun, Feb 16, 2014 at 08:55:33PM -0800, Matthew Moyle-Croft wrote:
>>
>> On 16 Feb 2014, at 8:48 pm, Ben <ben at meh.net.nz> wrote:
>>
>> ...
>>
>>>>>
>>>>
>>>> "Fallback routes"?
>>>
>>> Err, advertising with less prepending for the same subnet.
>>
>> This is about more specifics.
>>
>>>
>>>> More specifics are a common tool used to TE traffic. The issue is if your /24s aren't globally advertised.
>>>
>>> Ok, so say Telstra advertise routes at Equninx Los Angeles, and the
>>> other provider doesn't advertise at Equninix Los Angeles, then
>>> people close to that are going to often have local preference set to
>>> send via peering exchange. But say they have a low end router for
>>> peering, and theey decide to strip /24s, or default route+peering
>>> routes. (the same can apply for domestic traffic, but it's more
>>> significant and more obvious for international)
>>
>> If they're stripping /24s and/or have default then they're going to be getting to the interwebz via a transit provider who WILL have full routes because they're clearly not big enough to have routers that cope with being in the DFZ.
>
> Not necessarily. I've been doing some lookups, and struggling to find examples of places that Vocus and NTT aren't at, but Telstra are, or common local preference for provider type isuses. I figure an example of where it's not working international would work best.
>
>
>>>
>>> If you advertise a /23 to Telstra, and /23 and two /24s to your
>>> other provider, then when Telstra receive this traffic what are they meant to do with it? Is that clearer?
>> They'll follow the /24s toward where you're advertising them. Not ideal, but Telstra have decided to not offer fairly standard tools (BGP communities) so my empathy for them is as close to zero as you can get.
>
> Say you have a 100 megabit pipe with Telstra, and a gigabit pipe with Vocus, and you were getting 200 megabit/sec for a file coming internationally from a Telstra peer in say London by advertising a /23 to Telstra, and two /24s to Vocus -- yeah wishful thinking, but say Vocus shut down their linx peer -- right now LINX is showing for his subnet as:
>
> https://stats.linx.net/cgi-pub/xlg.pl?run=true&site=LINX-London&query_type=+BGP&address=202.128.102.1&Submit=Submit
>
>
> So it's only Vocus and Telstra at least, with lots of prepends to Telstra. So Telstra are carrying the traffic.. now along the way should they pass it off to Vocus, or should they just keep carrying it? Right thinking generally dictates that traffic should stay within Telstra to the end destination, otherwise some infarious party could steal the traffic, and some parties block receiving routes that they're advertising -- but that isn't necessarily goign to hold over for more specific routes. Say they do pass it on Vocus, then you'll bypass the rate limit of the link. If they don't, then you don't fix the initial issue.
>
> And unless all providers are at all the same internet exchanges and with the same peering agreements this will happen to some degree.
>
>> From what he said it sounded like he wasn't trying to gently shift traffic, but rather to move all traffic off of the secondary link.
>
>>>
>>>
>>>> The main issue is - if your other provider(s) don't have good domestic Australian connectivity, but again, I kind of assume anyone doing this has some clue and/or deserves some failure based learning.
>>>
>>> Maybe I don't understand the problem completely. From my
>>> understanding the idea was to get rid of all traffic off the
>>> fallback link, unless there's an actual outage, whilst still
>>> advertising BGP routes. That in itself is not acheivable from what I can tell. And by advertising more specficially I can't see any advantage to just prepending normally. If telstra do accept the /24 over the /23, and send to the customer regardless, and still advertise out the /23 then there is a chance for misdirected traffic either going to the customer via their alternative provider, or still going through their normal link.
>>
>> Again, prepending is irrelevant. /24s will always win as they are more specific. If you're not clear on that I'd do some reading up on routing.
>
> Yeh sure so the /24 wins. But that's not the issue - the issue that once traffic has come in Telstra's netowrk, they really should send it through to him. And if it does go via Vocus (which there is some chance of) then that means that Telstra are carrying traffic that may be over the capacity of their link.
>
> You can't expect providers to have global rate limits over their whole network at every location, so usually individual links are charged for. So it basically bypasses charging.
>
>
> It'd be even more significant if he wanted to prefer Telstra over Vocus, and much easier to come up with examples that actually would be problematic -
>
> Vocus advertise his subnet in New Zealand over APE, in Auckland, so easy straight peering - and I know for a fact that there are providers in New Zealand that have APE routes and domestic but don't have full international tables - they will send traffic over APE to him, if any routes exist via APE/Vocus. I don't know for sure what they'd do if you advertised a /24 via Telstra and a /23 via Vocus.
>
> Ben
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 17 Feb 2014 16:11:58 +1000
> From: Bruce Forster <bruce at tubes.net.au>
> To: "Joshua D'Alton" <joshua at railgun.com.au>
> Cc: "ausnog at ausnog.net" <ausnog at ausnog.net>
> Subject: Re: [AusNOG] NTT packet loss??
> Message-ID:
> <CADaR5wN2G0-z_s5L4fWi4ithQoon2QK1zhfjde9fAtqVjOF88g at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> What I have got is:
>
> <snip>
>
> The latest update is that there is a partial restoration of some these
> circuits, but still not ETR on a complete fix.
>
> </snip>
>
> However that said things are a lot better then this morning :)
>
>
> On 17 February 2014 15:30, Joshua D'Alton <joshua at railgun.com.au> wrote:
>
>> Seems fully restored now, I had notice from a LA provider that full
>> connectivity is restored.
>>
>>
>> On Mon, Feb 17, 2014 at 12:07 PM, Chris Chaundy <chris.chaundy at gmail.com>wrote:
>>
>>>
>>> Advice is that circuits have been partially restored and things should be
>>> improving...
>>>
>>>
>>> On Mon, Feb 17, 2014 at 10:38 AM, Chris Chaundy <chris.chaundy at gmail.com>wrote:
>>>
>>>> Some detail - the fault is on transmit from Paddington to Tumon Bay.
>>>>
>>>>
>>>> On Mon, Feb 17, 2014 at 10:35 AM, Chris Chaundy <chris.chaundy at gmail.com
>>>>> wrote:
>>>>
>>>>> There is a reported AJC cable outage commencing 03:45 ADST - no more
>>>>> detail or ETR at this time.
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Feb 17, 2014 at 10:30 AM, Bruce Forster <bruce at tubes.net.au>wrote:
>>>>>
>>>>>> Yes i can see loss to both of them..
>>>>>>
>>>>>>
>>>>>> On 17 February 2014 09:25, Branko Stanic <branko.stanic at rea-group.com>wrote:
>>>>>>
>>>>>>> So we see it getting to Amazon VPN endpoints in US East and Japan:
>>>>>>> For example: 27.0.1.16 & 72.21.209.194
>>>>>>>
>>>>>>> Mtr otuput (10 packets):
>>>>>>>
>>>>>>> HOST: *.eqx.realestate.com. Loss% Snt Last Avg Best Wrst
>>>>>>> StDev
>>>>>>> 1. 203.17.253.252 0.0% 10 0.3 0.3 0.3
>>>>>>> 0.6 0.1
>>>>>>> 2. 202.167.227.69 0.0% 10 0.3 5.3 0.3
>>>>>>> 41.5 13.0
>>>>>>> 3. 202.68.67.41 0.0% 10 0.4 3.0 0.4
>>>>>>> 26.0 8.1
>>>>>>> 4. xe-5-1-0.r05.sydnau01.au.bb. 0.0% 10 0.6 0.7 0.6
>>>>>>> 1.3 0.2
>>>>>>> 5. p16-1-2-0.r02.lsanca03.us.bb 10.0% 10 266.3 263.5 259.4
>>>>>>> 266.4 2.6
>>>>>>> 6. xe-2-1-9.r20.lsanca03.us.bb. 10.0% 10 298.1 283.5 264.2
>>>>>>> 298.1 10.1
>>>>>>> 7. ae-6.r20.osakjp02.jp.bb.gin. 20.0% 10 375.3 382.1 373.6
>>>>>>> 392.7 7.7
>>>>>>> 8. ae-4.r23.osakjp02.jp.bb.gin. 20.0% 10 365.8 376.0 365.8
>>>>>>> 382.9 6.8
>>>>>>> 9. 61.200.91.154 20.0% 10 367.5 376.0 367.5
>>>>>>> 390.7 7.7
>>>>>>> 10. 27.0.0.189 30.0% 10 380.1 381.6 376.0
>>>>>>> 390.1 5.3
>>>>>>> 11. 27.0.0.204 30.0% 10 383.5 381.0 376.4
>>>>>>> 388.4 4.7
>>>>>>> 12. 27.0.1.16 30.0% 10 381.8 308.6 210.5
>>>>>>> 381.8 87.0
>>>>>>>
>>>>>>>
>>>>>>> *Branko Stanic* Network Engineer
>>>>>>>
>>>>>>> T +61 4 0574 0061
>>>>>>>
>>>>>>> Email branko.stanic at rea-group.com
>>>>>>>
>>>>>>> Visit www.rea-group.com
>>>>>>>
>>>>>>> [image: REA Group]
>>>>>>>
>>>>>>> From: Bruce Forster <bruce at tubes.net.au>
>>>>>>> Date: Monday, 17 February 2014 10:17 am
>>>>>>> To: REA USER <branko.stanic at rea-group.com>
>>>>>>> Cc: "ausnog at lists.ausnog.net" <ausnog at lists.ausnog.net>
>>>>>>> Subject: Re: [AusNOG] NTT packet loss??
>>>>>>>
>>>>>>> Can you give a sample ip?
>>>>>>>
>>>>>>>
>>>>>>> On 17 February 2014 09:09, Branko Stanic <branko.stanic at rea-group.com
>>>>>>>> wrote:
>>>>>>>
>>>>>>>> Is anyone seeing packet loss through NTT?
>>>>>>>>
>>>>>>>> We see 10-20% packet loss from EQX SYD2 to US and Japan since 3:49
>>>>>>>> AM ....
>>>>>>>>
>>>>>>>>
>>>>>>>> *Branko Stanic* Network Engineer
>>>>>>>>
>>>>>>>> T +61 4 0574 0061 <%2B61%204%200574%200061>
>>>>>>>>
>>>>>>>> Email branko.stanic at rea-group.com
>>>>>>>>
>>>>>>>> Visit www.rea-group.com
>>>>>>>>
>>>>>>>> [image: REA Group]
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> AusNOG mailing list
>>>>>>>> AusNOG at lists.ausnog.net
>>>>>>>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>>
>>>>>>> Bruce
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>>
>>>>>> Bruce
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>>
>>
>
>
> --
> Regards,
>
> Bruce
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140217/ed2a754f/attachment-0001.html>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: EE84100F-9B00-4BB1-A54A-14D1B42F824D[33].png
> Type: image/png
> Size: 10127 bytes
> Desc: not available
> URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140217/ed2a754f/attachment-0002.png>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: EE84100F-9B00-4BB1-A54A-14D1B42F824D[32].png
> Type: image/png
> Size: 10127 bytes
> Desc: not available
> URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140217/ed2a754f/attachment-0003.png>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 17 Feb 2014 06:29:06 +0000
> From: James Braunegg <james.braunegg at micron21.com>
> To: "Dobbins, Roland" <rdobbins at arbor.net>, "ausnog at lists.ausnog.net"
> <ausnog at lists.ausnog.net>
> Subject: Re: [AusNOG] NTP Reflection coming in over Equinix IX
> Message-ID:
> <CA7E867D448D8B489EFF2E97E266038A1DE68ADA at RA-EX01.raprinting.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Dear All
>
>
>
> For those interested I updated my DDoS NTP attack info page with additional information regarding NTP attack packet sizes as per Roland's information and also included an NTP DDoS attack graph showing mitigation via edge packet filtering.
>
>
>
> Updates can be found here - http://www.micron21.com/ddos-ntp/
>
>
>
> Kindest Regards
>
>
>
> James Braunegg
> P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616
> E: james.braunegg at micron21.com<mailto:james.braunegg at micron21.com> | ABN: 12 109 977 666
> W: www.micron21.com/ddos-protection<http://www.micron21.com/ddos-protection> T: @micron21
>
>
> [Description: Description: Description: Description: M21.jpg]
> This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.
>
>
>
>
>
>
> -----Original Message-----
> From: AusNOG [mailto:ausnog-bounces at lists.ausnog.net] On Behalf Of Dobbins, Roland
> Sent: Monday, February 17, 2014 3:15 PM
> To: ausnog at lists.ausnog.net
> Subject: Re: [AusNOG] NTP Reflection coming in over Equinix IX
>
>
>
>
>
> On Feb 14, 2014, at 7:43 AM, James Braunegg <james.braunegg at micron21.com<mailto:james.braunegg at micron21.com>> wrote:
>
>
>
>> I'll email you the pcap file for an off line discussion would be interesting to see if different version of wire shark show different data...
>
>
>
> James and I've already corresponded, here's what's apparently going on - the ntp RFCs state that ntp packets should be padded with 0s in order to fit a 64-bit boundary, and different attack tools/mechanisms perform differing amounts of padding.
>
>
>
> Here's a breakdown in terms of observed monlist packet sizes:
>
>
>
> ntp attack tool used in this most recent spate of attacks - 50 bytes, per James' weblog post.
>
>
>
> ntpdos.py - 60 bytes
>
>
>
> ntp_monlist.py = 234 bytes
>
>
>
> monlist, sysstat, et. al. from ntpdc/ntpq - 234 bytes
>
>
>
> So, the monlist packet-size varies based upon the amount of padding implemented by each tool author.
>
>
>
> The one constant I've found is that regular ntp time-sync requests are ~90 bytes in size. So, blocking traffic at the relevant edges destined for UDP/123 with a size of 50 byes, 60 bytes, and 234 bytes appears to be a non-destructive way of dropping level-6/-7 admin commands whilst still allowing time-sync to function. Be sure and pilot this prior to general deployment, though.
>
>
>
> -----------------------------------------------------------------------
>
> Roland Dobbins <rdobbins at arbor.net<mailto:rdobbins at arbor.net>> // <http://www.arbornetworks.com>
>
>
>
> Luck is the residue of opportunity and design.
>
>
>
> -- John Milton
>
>
>
> _______________________________________________
>
> 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/20140217/659588d5/attachment-0001.html>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: image001.jpg
> Type: image/jpeg
> Size: 2683 bytes
> Desc: image001.jpg
> URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140217/659588d5/attachment-0001.jpg>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 17 Feb 2014 06:35:29 +0000
> From: James Braunegg <james.braunegg at micron21.com>
> To: "Dobbins, Roland" <rdobbins at arbor.net>, "ausnog at lists.ausnog.net"
> <ausnog at lists.ausnog.net>
> Subject: Re: [AusNOG] NTP Reflection coming in over Equinix IX
> Message-ID:
> <CA7E867D448D8B489EFF2E97E266038A1DE68B23 at RA-EX01.raprinting.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Dear all sorry.. .I failed at copy paste...
>
>
>
> Woops... try http://www.micron21.com/ddos-ntp
>
>
>
> Without the slash ;-)
>
> Kindest Regards
>
> James Braunegg
> P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616
> E: james.braunegg at micron21.com<mailto:james.braunegg at micron21.com> | ABN: 12 109 977 666
> W: www.micron21.com/ddos-protection<http://www.micron21.com/ddos-protection> T: @micron21
>
>
> [Description: Description: Description: Description: M21.jpg]
> This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.
>
> From: AusNOG [mailto:ausnog-bounces at lists.ausnog.net] On Behalf Of James Braunegg
> Sent: Monday, February 17, 2014 5:29 PM
> To: Dobbins, Roland; ausnog at lists.ausnog.net
> Subject: Re: [AusNOG] NTP Reflection coming in over Equinix IX
>
>
> Dear All
>
>
>
> For those interested I updated my DDoS NTP attack info page with additional information regarding NTP attack packet sizes as per Roland's information and also included an NTP DDoS attack graph showing mitigation via edge packet filtering.
>
>
>
> Updates can be found here - http://www.micron21.com/ddos-ntp/
>
>
>
> Kindest Regards
>
>
>
> James Braunegg
> P: 1300 769 972 | M: 0488 997 207 | D: (03) 9751 7616
> E: james.braunegg at micron21.com<mailto:james.braunegg at micron21.com> | ABN: 12 109 977 666
> W: www.micron21.com/ddos-protection<http://www.micron21.com/ddos-protection> T: @micron21
>
>
> [Description: Description: Description: Description: M21.jpg]
> This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.
>
>
>
>
>
>
> -----Original Message-----
> From: AusNOG [mailto:ausnog-bounces at lists.ausnog.net] On Behalf Of Dobbins, Roland
> Sent: Monday, February 17, 2014 3:15 PM
> To: ausnog at lists.ausnog.net<mailto:ausnog at lists.ausnog.net>
> Subject: Re: [AusNOG] NTP Reflection coming in over Equinix IX
>
>
>
>
>
> On Feb 14, 2014, at 7:43 AM, James Braunegg <james.braunegg at micron21.com<mailto:james.braunegg at micron21.com>> wrote:
>
>
>
>> I'll email you the pcap file for an off line discussion would be interesting to see if different version of wire shark show different data...
>
>
>
> James and I've already corresponded, here's what's apparently going on - the ntp RFCs state that ntp packets should be padded with 0s in order to fit a 64-bit boundary, and different attack tools/mechanisms perform differing amounts of padding.
>
>
>
> Here's a breakdown in terms of observed monlist packet sizes:
>
>
>
> ntp attack tool used in this most recent spate of attacks - 50 bytes, per James' weblog post.
>
>
>
> ntpdos.py - 60 bytes
>
>
>
> ntp_monlist.py = 234 bytes
>
>
>
> monlist, sysstat, et. al. from ntpdc/ntpq - 234 bytes
>
>
>
> So, the monlist packet-size varies based upon the amount of padding implemented by each tool author.
>
>
>
> The one constant I've found is that regular ntp time-sync requests are ~90 bytes in size. So, blocking traffic at the relevant edges destined for UDP/123 with a size of 50 byes, 60 bytes, and 234 bytes appears to be a non-destructive way of dropping level-6/-7 admin commands whilst still allowing time-sync to function. Be sure and pilot this prior to general deployment, though.
>
>
>
> -----------------------------------------------------------------------
>
> Roland Dobbins <rdobbins at arbor.net<mailto:rdobbins at arbor.net>> // <http://www.arbornetworks.com>
>
>
>
> Luck is the residue of opportunity and design.
>
>
>
> -- John Milton
>
>
>
> _______________________________________________
>
> 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/20140217/f1b6bd1a/attachment.html>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: image001.jpg
> Type: image/jpeg
> Size: 2683 bytes
> Desc: image001.jpg
> URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140217/f1b6bd1a/attachment.jpg>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
> ------------------------------
>
> End of AusNOG Digest, Vol 24, Issue 52
> **************************************
Carl Gough Founder, CEO Tel: +61 425 266 764
mobsource.com Network as a Service
Sydney Silicon Valley New York London
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140217/d1b576ac/attachment.html>
More information about the AusNOG
mailing list