Spectrum TV authentication failures

[Jay R. Ashworth]

NANOG is probably not the optimal venue for looking into auth failures on 
the IPTV service which Spectrum/Charter/TWC/BH's TV app for Android uses 
(which are legion), even though it probably uses RADIUS to get the work
done.

Anyone got a pointer to a better venue for such questions?

Cheers,
-- jra

-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

RE: DMCA processing software

[Tony Wicks]

Speaking for Networks outside of the USA (and not being at all helpful sorry), 
/dev/null works well. Sorry, couldn't help myself...



-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jason Baugher
Sent: Wednesday, 7 June 2017 5:18 PM
To: NANOG 
Subject: DMCA processing software

I'm curious what people are using to manage DMCA takedown notices in mid-sized 
networks. I've been searching, and have found the ACNS spec, and a few obscure 
references to an RT plugin, but not much else. As the ISP I work for grows, 
manual handling of notices is starting to be a problem. I'd prefer something 
open-source so we can extend it to hook into our other systems, but primarily I 
need something to parse the notice emails, store the information, track the 
number of incidents over time, and generate letters to users.

If nothing exists, and everyone just has in-house proprietary systems, then 
we'll start down the same road, but I don't like to re-invent the wheel if I 
can help it.

Thanks

DMCA processing software

[Jason Baugher]

I'm curious what people are using to manage DMCA takedown notices in
mid-sized networks. I've been searching, and have found the ACNS spec, and
a few obscure references to an RT plugin, but not much else. As the ISP I
work for grows, manual handling of notices is starting to be a problem. I'd
prefer something open-source so we can extend it to hook into our other
systems, but primarily I need something to parse the notice emails, store
the information, track the number of incidents over time, and generate
letters to users.

If nothing exists, and everyone just has in-house proprietary systems, then
we'll start down the same road, but I don't like to re-invent the wheel if
I can help it.

Thanks

Re: IPv4 Hijacking For Idiots

[Christopher Morrow]

On Tue, Jun 6, 2017 at 9:13 PM, Mark Andrews  wrote:

>
> In message  gmail.com>, Christopher Morrow writes:
> >
> > On Tue, Jun 6, 2017 at 8:26 PM, Mark Andrews  wrote:
> >
> > > Now we could continue discussing how easy it is to hijack addresses
> > > of we could spend the time addressing the problem.  All it takes is
> > > a couple of transit providers to no longer accept word-of-mouth and
> > > the world will transition overnight.
> >
> > i don't think any transit providers were used in the previous thread
> worth
> > of examples/comms...
> > I don't know that IXP folk either:
> >   1) want to be the police of this
> >   2) should actually be the police of this (what is internet abuse? from
> > who's perspective? oh...)
> >
> > The 'solution' here isn't new though... well, one solution anyway:
> >   https://tools.ietf.org/html/rfc6810
>
> You missed the point.  We have the mechanisms to prevent hijacking
> today.  We just need to use them and stop using the traditional
>

apologies for taking your bait.


> mechanisms which cannot be mathematically be verified as correct.
>
>
i agree.


> Getting to that stage requires several companies to simultaneously
> say "we will no longer accept  as valid mechanisms to verify
> routes announcements.  You need to use X or else we won't accept
> the announcement".  Yes, this requires guts to do.
>
>
agreed here as well.


> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>

Re: IPv4 Hijacking For Idiots

[Mark Andrews]

In message 
, 
Christopher Morrow writes:
>
> On Tue, Jun 6, 2017 at 8:26 PM, Mark Andrews  wrote:
>
> > Now we could continue discussing how easy it is to hijack addresses
> > of we could spend the time addressing the problem.  All it takes is
> > a couple of transit providers to no longer accept word-of-mouth and
> > the world will transition overnight.
>
> i don't think any transit providers were used in the previous thread worth
> of examples/comms...
> I don't know that IXP folk either:
>   1) want to be the police of this
>   2) should actually be the police of this (what is internet abuse? from
> who's perspective? oh...)
>
> The 'solution' here isn't new though... well, one solution anyway:
>   https://tools.ietf.org/html/rfc6810

You missed the point.  We have the mechanisms to prevent hijacking
today.  We just need to use them and stop using the traditional
mechanisms which cannot be mathematically be verified as correct.

Getting to that stage requires several companies to simultaneously
say "we will no longer accept  as valid mechanisms to verify
routes announcements.  You need to use X or else we won't accept
the announcement".  Yes, this requires guts to do.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: IPv4 Hijacking For Idiots

[Mark Andrews]

In message <2541cadf-4a76-b172-b395-0822f1889...@bryanfields.net>, Bryan Fields 
writes:
> On 6/6/17 9:13 PM, Mark Andrews wrote:
> > Getting to that stage requires several companies to simultaneously
> > say "we will no longer accept  as valid mechanisms to verify
> > routes announcements.  You need to use X or else we won't accept
> > the announcement".  Yes, this requires guts to do.
> 
> And what of legacy address holders?  ARIN will not permit RPKI use of their
> blocks.

This really doesn't prevent it being used.  RPKI could have a forth
CA for legacy holders that don't accept ARIN's terms for issuing
of RPKI.  You just need to co-ordinate yourselves.  There is nothing
magical about the current three other than they are accepted by
everyone.

Or we can just abandon IPv4 and its legacy baggage and do it for
IPv6.

Mark

> -- 
> Bryan Fields
> 
> 727-409-1194 - Voice
> http://bryanfields.net
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: IPv4 Hijacking For Idiots

[Hank Nussbacher]

On 06/06/2017 03:20, William Herrin wrote:

Ronald,

Here is how I would do it:

1.  As you noted in your first email in this thread, find an abandoned
ASN, lets call it AS12345, with a POC of supp...@acme.com
2.  Create a domain called acme-corp.com and a user called peering
3.  Contact an IX, preferably not one in a Westernized, clueful area:
https://en.wikipedia.org/wiki/List_of_Internet_exchange_points
4.  Using peer...@acme-corp.com, state that you are AS12345 and you wish
to join their wonderful IXP and to bring you router to their IXP for
peering purposes and to pay full membership dues.
5.  In general, not much due diligence will be done, since all Acme is
requesting is to colo their router in the same room/floor/building as
the IX and the IX is always trying to increase membership.  Not every IX
in the world is as diligent as LINX (example):
https://www.linx.net/join-linx/joining-procedure
6.  In the event the IX does ask for some documentation, create a logo,
forge a few documents, create a nice corporate landing page with the
logo, etc.Remember, the ASN hijacker will have done their homework
and shy away from clueful IXs.
7.  Pay your membership, bring your router to the IX and install it
8.  IX announces to all members about the existence of a new IX member.
9.  Major/large peers will shy away from small unknown ASNs, but there
are always many smaller IX members who are willing to peer with you
simply by sending them an email.
10.  Of the 56 IX members at clueless IX, 18 have peered with you within
a week and you have established your bona-fides.  You are now in your
way to growing your business :-)

Regards,
Hank

> On Mon, Jun 5, 2017 at 6:56 AM, Ronald F. Guilmette 
> wrote:
>
>> So, I guess then, if you're clever, you look and see who the ASN you've
>> just successfully hijacked has historically peered with, and then you
>> somehow arrange to send route announcements to those guys, right?
>> (I'm talking about AS206776 and AS57344 here, BTW.)
>>
>> But see, this is where I get lost.  I mean how do you push your route
>> announcements to these guys?
>
> Hi Ron,
>
> You actually got lost a couple steps back.
>
> First, you want to control the POC emails for the IP addresses. Controlling
> just the POC emails for the AS number won't do you any good.
>
> Let's say you have gained control of the POC emails for the IP address
> block. Stay completely away from the historical BGP peers. They might know
> the real registrant and get suspicious when you show up. Go to somebody
> else, dummy up some letterhead for the purported registrant and write
> yourself a letter authorizing the ISP to whom the letter is presented to
> route those IP addresses. Explain that you're a networking contractor
> working for the organization holding the registration and give them
> adequate contact information for yourself: postal address, email, phone.
> Not "1234 Main, box 30" but "1234 Main, Suite 30". Paid for with the
> cash-bought debit card. You get the idea.
>
> Then you pay the ISP to connect you to the Internet and present your
> letter. Until the inevitable complaints roll it, that's it: you have
> control of those IP addresses.
>
>
>
>> (I don't actually know that much about
>> how BGP actually works in practice, so please bear with me.)  How do
>> you know what IP address to send your announcements to?
>
> You don't. Even if the session wasn't disabled when the customer stopped
> paying, you're not physically connected to the same network interface where
> it was configured. This reasoning path is a dead end.
>
>
> I've read article after article after article bemoanging the fact that
>> "BGP isn't secure",
>
> They're talking about a different problem: ISPs are supposed to configure
> end-user BGP sessions per BCP38 which limits which BGP announcements the
> customer can make. Some ISPs are sloppy and incompetent and don't do this.
> Unfortunately, once you're a level or two upstream the backbone ISP
> actually can't do much to limit the BGP announcements because it's often
> impractical to determine whether a block of IP addresses can legitimately
> be announced from a given peer.
>
> Regards,
> Bill Herrin
>
>
>
>

Re: Templating/automating configuration

[Nick Hilliard]

Graham Johnston wrote:
> Short of complete SDN, for those of you that have some degree of
> configuration templating and/or automation tools what is it that you
> run? I'm envisioning some sort of tool that let's me define template
> snippets of configuration and aids in their deployment to devices.
> I'm okay doing the heaving lifting in defining everything, I'm just
> looking for the tool that stitches it together and hopefully makes
> things a little less error prone for those who aren't as adept.

you would probably want to look at napalm for something like this.  It
will back-end into ansible or more recently, salt stack.

Nick

Looking for Cisco ASR9000v feedback

[Erik Sundberg]

Does anyone have any experience with the Cisco 9000v?

Looking for the pro's, con's, and the gotcha's of moving our 1G ports to the 
9000V.







CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or 
previous e-mail messages attached to it may contain confidential information 
that is legally privileged. If you are not the intended recipient, or a person 
responsible for delivering it to the intended recipient, you are hereby 
notified that any disclosure, copying, distribution or use of any of the 
information contained in or attached to this transmission is STRICTLY 
PROHIBITED. If you have received this transmission in error please notify the 
sender immediately by replying to this e-mail. You must destroy the original 
transmission and its attachments without reading or saving in any manner. Thank 
you.

Re: Templating/automating configuration

[Stefan]

http://ipspace.net - search on everything ref network automation, under
webinars. Ivan is among the best in analysis and consolidation of such
info, and in documenting all options you may have.

Once you see what he has to offer, and definitely not only in the network
automation space, you may want to subscribe to all his webinars repository
access.

Regards,
***Stefan

On Jun 6, 2017 8:24 AM, "Graham Johnston"  wrote:

> Short of complete SDN, for those of you that have some degree of
> configuration templating and/or automation tools what is it that you run?
> I'm envisioning some sort of tool that let's me define template snippets of
> configuration and aids in their deployment to devices. I'm okay doing the
> heaving lifting in defining everything, I'm just looking for the tool that
> stitches it together and hopefully makes things a little less error prone
> for those who aren't as adept.
>
> Graham Johnston
> Network Planner
> Westman Communications Group
> 204.717.2829
> johnst...@westmancom.com
>
>

Re: Looking for Cisco ASR9000v feedback

[Tom Hill]

On 06/06/17 15:34, Erik Sundberg wrote:
> Looking for the pro's, con's, and the gotcha's of moving our 1G ports to the 
> 9000V.

The nV licenses for one. Talk about printing money.

-- 
Tom

Re: IPv4 Hijacking For Idiots

[Christopher Morrow]

On Tue, Jun 6, 2017 at 2:25 AM, Hank Nussbacher 
wrote:
(I think this is really Ron and Bill chatting, but some of the linkage got
lost on the tubes)


> >
> > I've read article after article after article bemoanging the fact that
> >> "BGP isn't secure",
> >
> > They're talking about a different problem: ISPs are supposed to configure
> > end-user BGP sessions per BCP38 which limits which BGP announcements the
> > customer can make. Some ISPs are sloppy and incompetent and don't do
> this.
> > Unfortunately, once you're a level or two upstream the backbone ISP
> > actually can't do much to limit the BGP announcements because it's often
> > impractical to determine whether a block of IP addresses can legitimately
> > be announced from a given peer.
>

just a clarifying note: I don't think bcp38 talks about BGP at all,
actually...
I think bill is actually saying:

 "ISPs are supposed to configure bcp38 to filter TRAFFIC from their
customers/peers and BGP filters to limit the scope of the customer routes
sent/received"

I don't think the filtering of customer prefixes/announcements is actually
covered in a BCP though.

Re: Templating/automating configuration

[Alexis Letessier]

Go templates: http://golang.org  Fast and simple with gRPC 
and other good stuff like kelsey’s confd (a daemon that watches for changes and 
update templates)

% go doc text/template
package template // import "text/template"

Package template implements data-driven templates for generating textual
output.

To generate HTML output, see package html/template, which has the same
interface as this package but automatically secures HTML output against
certain attacks.

Templates are executed by applying them to a data structure. Annotations in
the template refer to elements of the data structure (typically a field of a
struct or a key in a map) to control execution and derive values to be
displayed. Execution of the template walks the structure and sets the
cursor, represented by a period '.' and called "dot", to the value at the
current location in the structure as execution proceeds.

The input text for a template is UTF-8-encoded text in any format.
"Actions"--data evaluations or control structures--are delimited by "{{" and
"}}"; all text outside actions is copied to the output unchanged. Except for
raw strings, actions may not span newlines, although comments can.

Once parsed, a template may be executed safely in parallel.

Here is a trivial example that prints "17 items are made of wool".

type Inventory struct {
Material string
Countuint
}
sweaters := Inventory{"wool", 17}
tmpl, err := template.New("test").Parse("{{.Count}} items are made of 
{{.Material}}")
if err != nil { panic(err) }
err = tmpl.Execute(os.Stdout, sweaters)
if err != nil { panic(err) }

Alexis

> On 6 Jun 2017, at 15:22, Graham Johnston  wrote:
> 
> Short of complete SDN, for those of you that have some degree of 
> configuration templating and/or automation tools what is it that you run? I'm 
> envisioning some sort of tool that let's me define template snippets of 
> configuration and aids in their deployment to devices. I'm okay doing the 
> heaving lifting in defining everything, I'm just looking for the tool that 
> stitches it together and hopefully makes things a little less error prone for 
> those who aren't as adept.
> 
> Graham Johnston
> Network Planner
> Westman Communications Group
> 204.717.2829
> johnst...@westmancom.com
> 

Re: NANOG70 tee shirt mystery

[Andy Grosser]

That's correct.
Andy 

> On Jun 4, 2017, at 8:10 PM, Jon Sevier  wrote:
> 
> It's a play on Pearl Jam's "Ten" album cover as best as I can tell.
> 
> -Jon
> 
>> On Jun 4, 2017 16:57, "Matthew Petach"  wrote:
>> 
>> So, I've been staring at the NANOG70 tee shirt for
>> a bit now:
>> 
>> https://flic.kr/p/VejX5y
>> 
>> and I have to admit, I'm a bit stymied.
>> 
>> Usually, the tee-shirts are somewhat referential
>> to the location or to a particular event; but this
>> one is leaving me scratching my head.
>> 
>> Is it perhaps a shot of the network engineering
>> "Ooops (I broke the network again)"  concert
>> tour?
>> 
>> Or is there some other cultural reference at
>> play that I'm not aware of?
>> 
>> Enquiring minds want to know!(tm).  :)
>> 
>> Matt
>> 

AT Broken Uverse IPv6 routing.

[Brandon Jackson via NANOG]

Sorry for the noise but normal support channels are not understanding IPv6
is broken, they just see IPv4 works.

Can anyone contact me or maybe provide a contact or pass this along to
someone in ATT who can deal with broken IPv6 routing for Uverse Res/Small
Biz IPv6 blocks that are being assigned.

For Example one block that was delegated via DHCP-DP is
2600:1700:8250:8390::/60 tracing to it from anywhere outside of AT gets a
"Destination net unreachable".

Note this seems to have going on since atleast the 31st but likely longer,
that's just when the gateway was updated to DHCP-PD from 6rd. 3 Examples of
traces below.

Note even 2001:506:7825:839::1 seems to issues with connectivity but it
might not matter as much as that just the "WAN" of the gateway.

>From an HE.net connection
 2  ge5-4.core1.ash1.he.net (2001:470:0:90::1)  25.200 ms  24.878 ms
 24.650 ms
 3  100ge3-1.core1.nyc4.he.net (2001:470:0:299::2)  33.407 ms  25.643 ms
 25.245 ms
 4  as7018-att.10gigabitethernet2-3.core1.nyc4.he.net (2001:470:0:1dd::2)
 29.880 ms !N  32.288 ms !N  31.917 ms !N

>From Cogent Looking Glass in ATL

traceroute to 2600:1700:8250:8390::1 (2600:1700:8250:8390::1), 30 hops max,
80 byte packets
 1  2001:550:1:310::1 (2001:550:1:310::1)  0.989 ms  0.992 ms
 2  te0-18-0-2.ccr42.atl01.atlas.cogentco.com (2001:550:0:1000::9a36:2fc5)
 0.983 ms  0.990 ms
 3  be2848.ccr41.atl04.atlas.cogentco.com (2001:550:0:1000::9a36:676)
 2.018 ms be2790.ccr22.atl02.atlas.cogentco.com
(2001:550:0:1000::9a36:1ba6)  1.191 ms
 4  2001:1890:1fff:501:192:205:36:237 (2001:1890:1fff:501:192:205:36:237)
 8.640 ms !N 2001:550:3::166 (2001:550:3::166)  8.270 ms !N


>From Sprint Looking Glass in ATL

traceroute6 to 2600:1700:8250:8390::1 (2600:1700:8250:8390::1) from
2600:0:1:1239:144:228:243:98, 64 hops max, 12 byte packets
 1  sl-mst50-atl-ae10.0.v6.sprintlink.net (2600:0:2:1239:144:232:14:86)
 0.635 ms  0.551 ms  0.457 ms
 2  2600:0:3:1239:144:232:0:6a (2600:0:3:1239:144:232:0:6a)  6.672 ms !N
 7.277 ms !N  7.984 ms !N

Re: IPv4 Hijacking For Idiots

[Christopher Morrow]

On Tue, Jun 6, 2017 at 8:26 PM, Mark Andrews  wrote:

> Now we could continue discussing how easy it is to hijack addresses
> of we could spend the time addressing the problem.  All it takes is
> a couple of transit providers to no longer accept word-of-mouth and
> the world will transition overnight.
>

i don't think any transit providers were used in the previous thread worth
of examples/comms...
I don't know that IXP folk either:
  1) want to be the police of this
  2) should actually be the police of this (what is internet abuse? from
who's perspective? oh...)

The 'solution' here isn't new though... well, one solution anyway:
  https://tools.ietf.org/html/rfc6810

Re: NANOG 70 network diagram and upstream

[Dave Temkin]

Yes, frankly, it doesn't cost us (NANOG) anything - the sponsors like to do
it for the "cool" factor, and so long as it's not an undue burden on us,
they can throw as much bandwidth at us as they'd like.

-Dave

On Sun, Jun 4, 2017 at 4:02 PM, James Breeden  wrote:

> Yeah, I was wondering about that 4x100G. is that a necessity or a "because
> we can" move?
>
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Eric Dugas
> Sent: Friday, June 2, 2017 4:35 PM
> To: Aaron Gould 
> Cc: NANOG 
> Subject: RE: NANOG 70 network diagram and upstream
>
> And the 4x100G. That's four times the capacity of the network I work for.
> ~100k subs.
>
> On Jun 2, 2017 16:54, "Aaron Gould"  wrote:
>
> > Btw
> >
> > Wow, a ~2 million dollar boundary (dual PTX1000's) for the NANOG 70
> > conference geez
> >
> > -aaron
> >
> > -Original Message-
> > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Eric Kuhnke
> > Sent: Friday, June 2, 2017 1:43 PM
> > To: nanog@nanog.org list 
> > Subject: NANOG 70 network diagram and upstream
> >
> > Just a small thing, but as one of the folks who used to work on the
> > core network gear of AS11404, the network diagram has something in it
> > that might confuse attendees as to who is really sponsoring the upstream:
> >
> > https://www.nanog.org/meetings/nanog70/diagram
> >
> > AS11404 was formerly known as Spectrum Networks, acquired in 2013 by
> > Wavedivision Holdings LLC (Wave Broadband) and became the backbone of
> > the Wave network. It's a totally different thing than the Charter
> > service which is trademarked as as Spectrum.
> >
> > https://www.peeringdb.com/asn/11404
> >
> > The logo in the right side bubble there shouldn't be the
> > Charter/Spectrum trademarked font, but rather should be Wave, who
> > built the dark fiber into the hotel and are providing the upstream.
> > The last mile fiber into the hotel is Wave.
> >
> >
> > -Eric
> >
> >
>

Re: NANOG 70 network diagram and upstream

[Andrew Conrad]

Looks like the network diagram was updated and they ended up with just 2x 10Gb 
circuits from Wave. I guess the 100Gb connections and redundant carriers fell 
through?

--Andrew 


> On Jun 4, 2017, at 5:33 PM, Eric Kuhnke  wrote:
> 
> Doesn't cost a lot to use the regional shelf spares stocked by Juniper for
> a couple of days...
> 
> On Jun 4, 2017 4:03 PM, "James Breeden"  wrote:
> 
>> Yeah, I was wondering about that 4x100G. is that a necessity or a "because
>> we can" move?
>> 
>> 
>> -Original Message-
>> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Eric Dugas
>> Sent: Friday, June 2, 2017 4:35 PM
>> To: Aaron Gould 
>> Cc: NANOG 
>> Subject: RE: NANOG 70 network diagram and upstream
>> 
>> And the 4x100G. That's four times the capacity of the network I work for.
>> ~100k subs.
>> 
>>> On Jun 2, 2017 16:54, "Aaron Gould"  wrote:
>>> 
>>> Btw
>>> 
>>> Wow, a ~2 million dollar boundary (dual PTX1000's) for the NANOG 70
>>> conference geez
>>> 
>>> -aaron
>>> 
>>> -Original Message-
>>> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Eric Kuhnke
>>> Sent: Friday, June 2, 2017 1:43 PM
>>> To: nanog@nanog.org list 
>>> Subject: NANOG 70 network diagram and upstream
>>> 
>>> Just a small thing, but as one of the folks who used to work on the
>>> core network gear of AS11404, the network diagram has something in it
>>> that might confuse attendees as to who is really sponsoring the upstream:
>>> 
>>> https://www.nanog.org/meetings/nanog70/diagram
>>> 
>>> AS11404 was formerly known as Spectrum Networks, acquired in 2013 by
>>> Wavedivision Holdings LLC (Wave Broadband) and became the backbone of
>>> the Wave network. It's a totally different thing than the Charter
>>> service which is trademarked as as Spectrum.
>>> 
>>> https://www.peeringdb.com/asn/11404
>>> 
>>> The logo in the right side bubble there shouldn't be the
>>> Charter/Spectrum trademarked font, but rather should be Wave, who
>>> built the dark fiber into the hotel and are providing the upstream.
>>> The last mile fiber into the hotel is Wave.
>>> 
>>> 
>>> -Eric
>>> 
>>> 
>> 

Re: Templating/automating configuration

[Oliver Elliott]

I echo Ansible. I'm using it with NAPALM and jinja2 templates to push and
verify config on switches.

Oli

On 6 June 2017 at 14:27, Pui Edylie  wrote:

> Hi,
>
> Take a look at Ansible
>
> https://www.ansible.com/
>
> Our whole infra is automated using it and it is great!
>
> Regards,
> Edy
>
>
>
> On 6/6/2017 9:22 PM, Graham Johnston wrote:
>
>> Short of complete SDN, for those of you that have some degree of
>> configuration templating and/or automation tools what is it that you run?
>> I'm envisioning some sort of tool that let's me define template snippets of
>> configuration and aids in their deployment to devices. I'm okay doing the
>> heaving lifting in defining everything, I'm just looking for the tool that
>> stitches it together and hopefully makes things a little less error prone
>> for those who aren't as adept.
>>
>> Graham Johnston
>> Network Planner
>> Westman Communications Group
>> 204.717.2829
>> johnst...@westmancom.com
>>
>>
>>
>
>


-- 
Oliver Elliott
Senior Network Specialist
IT Services, University of Bristol
t: 0117 39 (41131)

Re: IPv4 Hijacking For Idiots

[Scott Christopher]

Hank Nussbacher wrote: 

> 2.  Create a domain called acme-corp.com and a user called peering

Or one could register aсme.com

(If the reader can't tell the difference between acme.com and aсme.com ,
the reader is using one of the multitude of email clients and/or fonts
that presents Unicode poorly.)

> 3.  Contact an IX, preferably not one in a Westernized, clueful area:
> https://en.wikipedia.org/wiki/List_of_Internet_exchange_points

I don't think the ordinary Westernized IX is immune to this. Any system
requiring human scrutiny is only as secure as the laziest human employed
by it. Don't underestimate the "too busy to check this crap"
attitude and its potential for serious problems.

-- 
Regards,
  S.C.

Proxying NetFlow traffic correctly

[Sami via NANOG]

Hello,
I have been searching for a solution that collects/duplicates NetFlow traffic 
properly for a while but i couldn't find any.
Do you know any good unix alternative to ntopng, flowd, flow-tools?

nprobe of netflow seems to be the closest one to fit my needs but i want to see 
if there are any other solution.

My goal is to centralize NetFlow traffic into a single machine and then proxy 
some flows to other destinations for further analysis

Best Regards,
Sami

Re: NANOG70 tee shirt mystery

[Niels Bakker]

* David Barak [Mon 05 Jun 2017, 02:09 CEST]:

https://en.m.wikipedia.org/wiki/Ten_(Pearl_Jam_album)

Pearl Jam are from Seattle...


I only knew the CD version, which looks cropped from the LP edition: 
https://www.discogs.com/Pearl-Jam-Ten/release/376650#images/3899643



-- Niels.

Re: Proxying NetFlow traffic correctly

[Tim Raphael]

nProbe is what you want, it’s another product from NTop.

http://www.ntop.org/products/netflow/nprobe/ 


- Tim


> On 7 Jun 2017, at 7:43 am, Sami via NANOG  wrote:
> 
> Hello,
> I have been searching for a solution that collects/duplicates NetFlow traffic 
> properly for a while but i couldn't find any.
> Do you know any good unix alternative to ntopng, flowd, flow-tools?
> 
> nprobe of netflow seems to be the closest one to fit my needs but i want to 
> see if there are any other solution.
> 
> My goal is to centralize NetFlow traffic into a single machine and then proxy 
> some flows to other destinations for further analysis
> 
> Best Regards,
> Sami

Re: Proxying NetFlow traffic correctly

[Hugo Slabbert]

On Tue 2017-Jun-06 17:43:46 -0400, Sami via NANOG  wrote:


Hello,
I have been searching for a solution that collects/duplicates NetFlow traffic 
properly for a while but i couldn't find any.
Do you know any good unix alternative to ntopng, flowd, flow-tools?

nprobe of netflow seems to be the closest one to fit my needs but i want to see 
if there are any other solution.

My goal is to centralize NetFlow traffic into a single machine and then proxy 
some flows to other destinations for further analysis

Best Regards,
Sami


Flexible: pmacct[1][2]
Simple and does what you ask: samplicate[3]

--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal

[1] http://pmacct.net/
[2] https://github.com/pmacct/pmacct
[3] https://github.com/sleinen/samplicator


signature.asc
Description: Digital signature

Re: Templating/automating configuration

[Vincent Bernat]

 ❦  6 juin 2017 14:30 +0100, Oliver Elliott  :

> I echo Ansible. I'm using it with NAPALM and jinja2 templates to push and
> verify config on switches.

Why not using the builtin ability of ansible for most vendors? (genuine
question)

 http://docs.ansible.com/ansible/list_of_network_modules.html
-- 
Make it clear before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Proxying NetFlow traffic correctly

[Hugo Slabbert]

On Tue 2017-Jun-06 16:39:16 -0700, Hugo Slabbert  wrote:



On Tue 2017-Jun-06 17:43:46 -0400, Sami via NANOG  wrote:


Hello,
I have been searching for a solution that collects/duplicates NetFlow traffic 
properly for a while but i couldn't find any.
Do you know any good unix alternative to ntopng, flowd, flow-tools?

nprobe of netflow seems to be the closest one to fit my needs but i want to see 
if there are any other solution.

My goal is to centralize NetFlow traffic into a single machine and then proxy 
some flows to other destinations for further analysis

Best Regards,
Sami


Flexible: pmacct[1][2]
Simple and does what you ask: samplicate[3]


Actually: samplicate is more all-or-nothing as far as I'm aware.  So it 
could proxy a full set of flows, but the "some flows" part of your request 
I'm not so sure about.




--
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal

[1] http://pmacct.net/
[2] https://github.com/pmacct/pmacct
[3] https://github.com/sleinen/samplicator





signature.asc
Description: Digital signature

Re: IPv4 Hijacking For Idiots

[Mark Andrews]

In message 
<1496754899.2014592.1000384072.3e553...@webmail.messagingengine.com>, Scott 
Christopher writes:
> Hank Nussbacher wrote:
>
> > 2.  Create a domain called acme-corp.com and a user called peering
>
> Or one could register aсme.com
>
> (If the reader can't tell the difference between acme.com and aсme.com ,
> the reader is using one of the multitude of email clients and/or fonts
> that presents Unicode poorly.)
>
> > 3.  Contact an IX, preferably not one in a Westernized, clueful area:
> > https://en.wikipedia.org/wiki/List_of_Internet_exchange_points
>
> I don't think the ordinary Westernized IX is immune to this. Any system
> requiring human scrutiny is only as secure as the laziest human employed
> by it. Don't underestimate the "too busy to check this crap"
> attitude and its potential for serious problems.
>
> --
> Regards,
>   S.C.

Route hijacking is theoretically preventable.  You have machines
verify the bonifides.  This does require that people take the time
to get the bonifides machines can process but we do have the tech
to do this.

Now we could continue discussing how easy it is to hijack addresses
of we could spend the time addressing the problem.  All it takes is
a couple of transit providers to no longer accept word-of-mouth and
the world will transition overnight.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: IPv4 Hijacking For Idiots

[Bryan Fields]

On 6/6/17 9:13 PM, Mark Andrews wrote:
> Getting to that stage requires several companies to simultaneously
> say "we will no longer accept  as valid mechanisms to verify
> routes announcements.  You need to use X or else we won't accept
> the announcement".  Yes, this requires guts to do.

And what of legacy address holders?  ARIN will not permit RPKI use of their
blocks.

-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

Re: Proxying NetFlow traffic correctly

[Dobbins, Roland]

On Jun 7, 2017, at 06:32, Sami via NANOG 
> wrote:

My goal is to centralize NetFlow traffic into a single machine and then proxy 
some flows to other destinations for further analysis



Or nprobe, as was already mentioned.

---
Roland Dobbins >

Re: Proxying NetFlow traffic correctly

[Selphie Keller]

samplicate is very good, been using it for 6 years for netflow duplication
using botth the spoofing and non, depending on the sensor's needs if it
needs to retain the source ip or not.



On 6 June 2017 at 20:39, Dobbins, Roland  wrote:

>
>
> On Jun 7, 2017, at 06:32, Sami via NANOG  nanog.org>> wrote:
>
> My goal is to centralize NetFlow traffic into a single machine and then
> proxy some flows to other destinations for further analysis
>
> 
>
> Or nprobe, as was already mentioned.
>
> ---
> Roland Dobbins >
>

Templating/automating configuration

[Graham Johnston]

Short of complete SDN, for those of you that have some degree of configuration 
templating and/or automation tools what is it that you run? I'm envisioning 
some sort of tool that let's me define template snippets of configuration and 
aids in their deployment to devices. I'm okay doing the heaving lifting in 
defining everything, I'm just looking for the tool that stitches it together 
and hopefully makes things a little less error prone for those who aren't as 
adept.

Graham Johnston
Network Planner
Westman Communications Group
204.717.2829
johnst...@westmancom.com

Re: Templating/automating configuration

[Pui Edylie]

Hi,

Take a look at Ansible

https://www.ansible.com/

Our whole infra is automated using it and it is great!

Regards,
Edy


On 6/6/2017 9:22 PM, Graham Johnston wrote:

Short of complete SDN, for those of you that have some degree of configuration 
templating and/or automation tools what is it that you run? I'm envisioning 
some sort of tool that let's me define template snippets of configuration and 
aids in their deployment to devices. I'm okay doing the heaving lifting in 
defining everything, I'm just looking for the tool that stitches it together 
and hopefully makes things a little less error prone for those who aren't as 
adept.

Graham Johnston
Network Planner
Westman Communications Group
204.717.2829
johnst...@westmancom.com

Re: IP Hijacking For Dummies

[Rich Kulawiec]

On Mon, Jun 05, 2017 at 04:46:04PM -0700, Ronald F. Guilmette wrote:
> It did also strike me as passing strange that this company has apparently
> elected to not actually put its own web server, name servers, or mail
> server anywhere within its own duly allocated IPv4 blocks.

Out of curiosity, I ran a DNS scan against all of the /24's that you
enumerated (thank you, by the way).  I am also perplexed that a hosting
company which has "sold out" of virtual servers seems to have precious
few servers -- of any type -- represented in its DNS records.  To save
everyone else the trouble, I'm appending below all the results (1023)
that did not result in NXDOMAIN or SERVFAIL (5121).  Note in re the
last dozen on the list: I believe "correo" translates to "post", in
the sense of "mail", so those may well be (customer?) mail servers.

---rsk

168.176.194.11  palmi19411.palmira.unal.edu.co
168.176.194.12  palmi19412.palmira.unal.edu.co
168.176.194.13  palmi19413.palmira.unal.edu.co
168.176.194.14  palmi19414.palmira.unal.edu.co
168.176.194.15  palmi19415.palmira.unal.edu.co
168.176.194.16  palmi19416.palmira.unal.edu.co
168.176.194.17  palmi19417.palmira.unal.edu.co
168.176.194.18  palmi19418.palmira.unal.edu.co
168.176.194.19  palmi19419.palmira.unal.edu.co
168.176.194.20  palmi19420.palmira.unal.edu.co
168.176.194.21  palmi19421.palmira.unal.edu.co
168.176.194.22  palmi19422.palmira.unal.edu.co
168.176.194.23  palmi19423.palmira.unal.edu.co
168.176.194.24  palmi19424.palmira.unal.edu.co
168.176.194.25  palmi19425.palmira.unal.edu.co
168.176.194.26  palmi19426.palmira.unal.edu.co
168.176.194.27  palmi19427.palmira.unal.edu.co
168.176.194.28  palmi19428.palmira.unal.edu.co
168.176.194.29  palmi19429.palmira.unal.edu.co
168.176.194.30  palmi19430.palmira.unal.edu.co
168.176.194.31  palmi19431.palmira.unal.edu.co
168.176.194.32  palmi19432.palmira.unal.edu.co
168.176.194.33  palmi19433.palmira.unal.edu.co
168.176.194.34  palmi19434.palmira.unal.edu.co
168.176.194.35  palmi19435.palmira.unal.edu.co
168.176.194.36  palmi19436.palmira.unal.edu.co
168.176.194.37  palmi19437.palmira.unal.edu.co
168.176.194.38  palmi19438.palmira.unal.edu.co
168.176.194.39  palmi19439.palmira.unal.edu.co
168.176.194.40  palmi19440.palmira.unal.edu.co
168.176.194.41  palmi19441.palmira.unal.edu.co
168.176.194.42  palmi19442.palmira.unal.edu.co
168.176.194.43  palmi19443.palmira.unal.edu.co
168.176.194.44  palmi19444.palmira.unal.edu.co
168.176.194.45  palmi19445.palmira.unal.edu.co
168.176.194.46  palmi19446.palmira.unal.edu.co
168.176.194.47  palmi19447.palmira.unal.edu.co
168.176.194.48  palmi19448.palmira.unal.edu.co
168.176.194.49  palmi19449.palmira.unal.edu.co
168.176.194.50  palmi19450.palmira.unal.edu.co
168.176.194.51  palmi19451.palmira.unal.edu.co
168.176.194.52  palmi19452.palmira.unal.edu.co
168.176.194.53  palmi19453.palmira.unal.edu.co
168.176.194.54  palmi19454.palmira.unal.edu.co
168.176.194.55  palmi19455.palmira.unal.edu.co
168.176.194.56  palmi19456.palmira.unal.edu.co
168.176.194.57  palmi19457.palmira.unal.edu.co
168.176.194.58  palmi19458.palmira.unal.edu.co
168.176.194.59  palmi19459.palmira.unal.edu.co
168.176.194.60  palmi19460.palmira.unal.edu.co
168.176.194.61  palmi19461.palmira.unal.edu.co
168.176.194.62  palmi19462.palmira.unal.edu.co
168.176.194.63  palmi19463.palmira.unal.edu.co
168.176.194.64  palmi19464.palmira.unal.edu.co
168.176.194.65  palmi19465.palmira.unal.edu.co
168.176.194.66  palmi19466.palmira.unal.edu.co
168.176.194.67  palmi19467.palmira.unal.edu.co
168.176.194.68  palmi19468.palmira.unal.edu.co
168.176.194.69  palmi19469.palmira.unal.edu.co
168.176.194.70  palmi19470.palmira.unal.edu.co
168.176.194.71  palmi19471.palmira.unal.edu.co
168.176.194.72  palmi19472.palmira.unal.edu.co
168.176.194.73  palmi19473.palmira.unal.edu.co
168.176.194.74  palmi19474.palmira.unal.edu.co
168.176.194.75  palmi19475.palmira.unal.edu.co
168.176.194.76  palmi19476.palmira.unal.edu.co
168.176.194.77  palmi19477.palmira.unal.edu.co
168.176.194.78  palmi19478.palmira.unal.edu.co
168.176.194.79  palmi19479.palmira.unal.edu.co
168.176.194.80  palmi19480.palmira.unal.edu.co
168.176.194.81  palmi19481.palmira.unal.edu.co
168.176.194.82  palmi19482.palmira.unal.edu.co
168.176.194.83  palmi19483.palmira.unal.edu.co
168.176.194.84  palmi19484.palmira.unal.edu.co
168.176.194.85  palmi19485.palmira.unal.edu.co
168.176.194.86  palmi19486.palmira.unal.edu.co
168.176.194.87  palmi19487.palmira.unal.edu.co
168.176.194.88  palmi19488.palmira.unal.edu.co
168.176.194.89  palmi19489.palmira.unal.edu.co
168.176.194.90  palmi19490.palmira.unal.edu.co
168.176.194.91  palmi19491.palmira.unal.edu.co
168.176.194.92  palmi19492.palmira.unal.edu.co
168.176.194.93  palmi19493.palmira.unal.edu.co
168.176.194.94  palmi19494.palmira.unal.edu.co
168.176.194.95  palmi19495.palmira.unal.edu.co
168.176.194.96  palmi19496.palmira.unal.edu.co
168.176.194.97  palmi19497.palmira.unal.edu.co
168.176.194.98  palmi19498.palmira.unal.edu.co
168.176.194.99  

Re: Templating/automating configuration

[Christopher Morrow]

https://youtu.be/ltqXgtLWXFo

and the assocaited pdf
https://www.nanog.org/meetings/nanog44/presentations/Monday/Gill_programatic_N44.pdf

On Tue, Jun 6, 2017 at 10:09 AM, Nick Hilliard  wrote:

> Graham Johnston wrote:
> > Short of complete SDN, for those of you that have some degree of
> > configuration templating and/or automation tools what is it that you
> > run? I'm envisioning some sort of tool that let's me define template
> > snippets of configuration and aids in their deployment to devices.
> > I'm okay doing the heaving lifting in defining everything, I'm just
> > looking for the tool that stitches it together and hopefully makes
> > things a little less error prone for those who aren't as adept.
>
> you would probably want to look at napalm for something like this.  It
> will back-end into ansible or more recently, salt stack.
>
> Nick
>

Re: Templating/automating configuration

[Job Snijders]

Hi,

Here are some extra pointers:

https://youtube.com/watch?v=C7pkab8n7ys

https://www.nanog.org/sites/default/files/dosdontsnetworkautomation.pdf

https://github.com/coloclue/kees

Kind regards,

Job


On Tue, 6 Jun 2017 at 13:49, Brian Knight  wrote:

> Because we had different sources of truth which were written in-house, we
> wound up rolling our own template engine in Python. It took about 3 weeks
> to write the engine and adapt existing templates.  Given a circuit ID, it
> generates the full config for copy and paste into a terminal session.  It
> also hooks into a configuration parser tool, written in-house, that tracks
> configured interfaces, so it is easy to see whether the template would
> overwrite an existing interface.
>
>
>
> I used the Jinja2 template engine, along with pyodbc/unixODBC/FreeTDS for
> access to a Microsoft SQL backend.
>
>
>
> The keys for us are:
>
>
>
> * extracting information from a source of truth
>
> * validating the information for correctness
>
> * making sure you don't overwrite existing config
>
> * outputting the right templates for the circuit features
>
>
>
> It made more sense to write a tool than it did to try to adapt something
> for our environment.
>
>
>
> If I had a free hand and unlimited budget, I would find a single app that
> functions as a source of truth for all circuits and products, which
> includes a templating engine that hooks in easily.
>
>
>
> -Brian
>
>
>
>
>
>  On Tue, 06 Jun 2017 08:22:59 -0500 Graham Johnston &
> lt;johnst...@westmancom.com wrote 
>
>
>
>
>
>
>
>
>
>
>
> Short of complete SDN, for those of you that have some degree of
> configuration templating and/or automation tools what is it that you run?
> I'm envisioning some sort of tool that let's me define template snippets of
> configuration and aids in their deployment to devices. I'm okay doing the
> heaving lifting in defining everything, I'm just looking for the tool that
> stitches it together and hopefully makes things a little less error prone
> for those who aren't as adept.
>
>
>
> Graham Johnston
>
> Network Planner
>
> Westman Communications Group
>
> 204.717.2829
>
> johnst...@westmancom.commailto:johnst...@westmancom.com;
>
>
>
>
>
>

Re: Templating/automating configuration

[Brian Knight]

Because we had different sources of truth which were written in-house, we wound 
up rolling our own template engine in Python. It took about 3 weeks to write 
the engine and adapt existing templates.  Given a circuit ID, it generates the 
full config for copy and paste into a terminal session.  It also hooks into a 
configuration parser tool, written in-house, that tracks configured interfaces, 
so it is easy to see whether the template would overwrite an existing interface.



I used the Jinja2 template engine, along with pyodbc/unixODBC/FreeTDS for 
access to a Microsoft SQL backend.



The keys for us are:



* extracting information from a source of truth

* validating the information for correctness

* making sure you don't overwrite existing config

* outputting the right templates for the circuit features



It made more sense to write a tool than it did to try to adapt something for 
our environment.



If I had a free hand and unlimited budget, I would find a single app that 
functions as a source of truth for all circuits and products, which includes a 
templating engine that hooks in easily.



-Brian





 On Tue, 06 Jun 2017 08:22:59 -0500 Graham Johnston 
johnst...@westmancom.com wrote 











Short of complete SDN, for those of you that have some degree of configuration 
templating and/or automation tools what is it that you run? I'm envisioning 
some sort of tool that let's me define template snippets of configuration and 
aids in their deployment to devices. I'm okay doing the heaving lifting in 
defining everything, I'm just looking for the tool that stitches it together 
and hopefully makes things a little less error prone for those who aren't as 
adept. 



Graham Johnston 

Network Planner 

Westman Communications Group 

204.717.2829 

johnst...@westmancom.commailto:johnst...@westmancom.com; 

RE: Looking for Cisco ASR9000v feedback

[Sean Pedersen]

Yeah - look for bundles if possible. I know it cut about 3/4 of the cost off of 
an NCS5K that we were looking at in a ASR9K satellite config.

Also, if you're doing satellite on the 9000V, I believe support for that 
feature is going away in a future version of IOS-XR. Double-check w/ your 
account team.

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Tom Hill
Sent: Tuesday, June 6, 2017 7:53 AM
To: nanog@nanog.org
Subject: Re: Looking for Cisco ASR9000v feedback

On 06/06/17 15:34, Erik Sundberg wrote:
> Looking for the pro's, con's, and the gotcha's of moving our 1G ports to the 
> 9000V.

The nV licenses for one. Talk about printing money.

-- 
Tom