Re: [SPAM] Re: OSPF vs ISIS - Which do you prefer & why?

[Mark Tinka]

On 11/Nov/16 21:34, Florian Weimer wrote:

>
> Has the name been a problem for you?  Asking vendors about support
> must be a bit awkward these days.

Why do you reckon?

Mark.

Re: USDA IT Contacts?

[Josh Reynolds]

They have a lot more at N.I.T.C. though.

https://www.ocio.usda.gov/about-ocio/data-center-operations-dco

On Fri, Nov 11, 2016 at 1:54 PM, Owen DeLong  wrote:
> USDA has a LOT of their IT in Ft. Collins, so that’s not irrational.
>
> Owen
>
>> On Nov 11, 2016, at 11:27 , rw...@ropeguru.com wrote:
>>
>> The very last POC was updated in 2015, but also out of Fort Collins.
>>
>> On Fri, 11 Nov 2016 12:59:16 -0600
>> Josh Reynolds  wrote:
>>> Just looking at that info... hasn't been updated since 2005 and is
>>> listed as being at Ft Collins.
>>>
>>> So I'll be complaining to some people on Monday :)
>>>
>>> On Fri, Nov 11, 2016 at 8:23 AM, Herriage, James L.  
>>> wrote:
 POCs here:
 uda.gov = 162.79.29.12
 https://whois.arin.net/rest/net/NET-162-79-0-0-1/pft?s=162.79.29.12


 Thanks,
 Lee

 -Original Message-
 From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Charles Gagnon
 Sent: Thursday, November 10, 2016 4:20 PM
 To: nanog@nanog.org
 Subject: USDA IT Contacts?

 *EXTERNAL EMAIL: EVALUATE*

 Would anyone have information about IT contacts within the US Government?
 Some of our IP ranges seem to be blocked from access to some government 
 web servers (discovered on http://www.usda.gov - we get a odd "access 
 denied"
 page there - traces point to the same IP at akamaitechnologies.com).

 I have NO idea who to discuss this with. I could not even find a "Contact 
 Us" to use on their website.

 Regards,

 --
 Charles Gagnon
 http://unixrealm.com
>

Re: USDA IT Contacts?

[Owen DeLong]

USDA has a LOT of their IT in Ft. Collins, so that’s not irrational.

Owen

> On Nov 11, 2016, at 11:27 , rw...@ropeguru.com wrote:
> 
> The very last POC was updated in 2015, but also out of Fort Collins.
> 
> On Fri, 11 Nov 2016 12:59:16 -0600
> Josh Reynolds  wrote:
>> Just looking at that info... hasn't been updated since 2005 and is
>> listed as being at Ft Collins.
>> 
>> So I'll be complaining to some people on Monday :)
>> 
>> On Fri, Nov 11, 2016 at 8:23 AM, Herriage, James L.  
>> wrote:
>>> POCs here:
>>> uda.gov = 162.79.29.12
>>> https://whois.arin.net/rest/net/NET-162-79-0-0-1/pft?s=162.79.29.12
>>> 
>>> 
>>> Thanks,
>>> Lee
>>> 
>>> -Original Message-
>>> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Charles Gagnon
>>> Sent: Thursday, November 10, 2016 4:20 PM
>>> To: nanog@nanog.org
>>> Subject: USDA IT Contacts?
>>> 
>>> *EXTERNAL EMAIL: EVALUATE*
>>> 
>>> Would anyone have information about IT contacts within the US Government?
>>> Some of our IP ranges seem to be blocked from access to some government web 
>>> servers (discovered on http://www.usda.gov - we get a odd "access denied"
>>> page there - traces point to the same IP at akamaitechnologies.com).
>>> 
>>> I have NO idea who to discuss this with. I could not even find a "Contact 
>>> Us" to use on their website.
>>> 
>>> Regards,
>>> 
>>> --
>>> Charles Gagnon
>>> http://unixrealm.com

Re: OSPF vs ISIS - Which do you prefer & why?

[Florian Weimer]

* Mark Tinka:

> I've given a talk about this a couple of times since 2008. But our
> reasons are to choosing IS-IS are:

Has the name been a problem for you?  Asking vendors about support
must be a bit awkward these days.

Re: USDA IT Contacts?

[rwebb]

The very last POC was updated in 2015, but also out of Fort Collins.

On Fri, 11 Nov 2016 12:59:16 -0600
 Josh Reynolds  wrote:

Just looking at that info... hasn't been updated since 2005 and is
listed as being at Ft Collins.

So I'll be complaining to some people on Monday :)

On Fri, Nov 11, 2016 at 8:23 AM, Herriage, James L.  wrote:

POCs here:
uda.gov = 162.79.29.12
https://whois.arin.net/rest/net/NET-162-79-0-0-1/pft?s=162.79.29.12


Thanks,
Lee

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Charles Gagnon
Sent: Thursday, November 10, 2016 4:20 PM
To: nanog@nanog.org
Subject: USDA IT Contacts?

*EXTERNAL EMAIL: EVALUATE*

Would anyone have information about IT contacts within the US Government?
Some of our IP ranges seem to be blocked from access to some government web servers 
(discovered on http://www.usda.gov - we get a odd "access denied"
page there - traces point to the same IP at akamaitechnologies.com).

I have NO idea who to discuss this with. I could not even find a "Contact Us" 
to use on their website.

Regards,

--
Charles Gagnon
http://unixrealm.com

Re: USDA IT Contacts?

[Josh Reynolds]

Just looking at that info... hasn't been updated since 2005 and is
listed as being at Ft Collins.

So I'll be complaining to some people on Monday :)

On Fri, Nov 11, 2016 at 8:23 AM, Herriage, James L.  wrote:
> POCs here:
> uda.gov = 162.79.29.12
> https://whois.arin.net/rest/net/NET-162-79-0-0-1/pft?s=162.79.29.12
>
>
> Thanks,
> Lee
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Charles Gagnon
> Sent: Thursday, November 10, 2016 4:20 PM
> To: nanog@nanog.org
> Subject: USDA IT Contacts?
>
> *EXTERNAL EMAIL: EVALUATE*
>
> Would anyone have information about IT contacts within the US Government?
> Some of our IP ranges seem to be blocked from access to some government web 
> servers (discovered on http://www.usda.gov - we get a odd "access denied"
> page there - traces point to the same IP at akamaitechnologies.com).
>
> I have NO idea who to discuss this with. I could not even find a "Contact Us" 
> to use on their website.
>
> Regards,
>
> --
> Charles Gagnon
> http://unixrealm.com

Weekly Routing Table Report

[Routing Analysis Role Account]

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,
SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 12 Nov, 2016

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  621131
Prefixes after maximum aggregation (per Origin AS):  220098
Deaggregation factor:  2.82
Unique aggregates announced (without unneeded subnets):  300375
Total ASes present in the Internet Routing Table: 55165
Prefixes per ASN: 11.26
Origin-only ASes present in the Internet Routing Table:   36323
Origin ASes announcing only one prefix:   15347
Transit ASes present in the Internet Routing Table:6538
Transit-only ASes present in the Internet Routing Table:166
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  36
Max AS path prepend of ASN ( 55644)  31
Prefixes from unregistered ASNs in the Routing Table:64
Unregistered ASNs in the Routing Table:  19
Number of 32-bit ASNs allocated by the RIRs:  16110
Number of 32-bit ASNs visible in the Routing Table:   12304
Prefixes from 32-bit ASNs in the Routing Table:   49851
Number of bogon 32-bit ASNs visible in the Routing Table:   343
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:430
Number of addresses announced to Internet:   2831675172
Equivalent to 168 /8s, 199 /16s and 239 /24s
Percentage of available address space announced:   76.5
Percentage of allocated address space announced:   76.5
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   98.3
Total number of prefixes smaller than registry allocations:  204046

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   157302
Total APNIC prefixes after maximum aggregation:   42681
APNIC Deaggregation factor:3.69
Prefixes being announced from the APNIC address blocks:  171205
Unique aggregates announced from the APNIC address blocks:70250
APNIC Region origin ASes present in the Internet Routing Table:5174
APNIC Prefixes per ASN:   33.09
APNIC Region origin ASes announcing only one prefix:   1146
APNIC Region transit ASes present in the Internet Routing Table:947
Average APNIC Region AS path length visible:4.3
Max APNIC Region AS path length visible: 35
Number of APNIC region 32-bit ASNs visible in the Routing Table:   2463
Number of APNIC addresses announced to Internet:  759799108
Equivalent to 45 /8s, 73 /16s and 157 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-137529
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:187791
Total ARIN prefixes after maximum aggregation:88833
ARIN Deaggregation factor: 2.11
Prefixes being announced from the ARIN address blocks:   194070
Unique aggregates announced from the ARIN address blocks: 87887
ARIN Region origin ASes present in the Internet Routing Table:16152
ARIN Prefixes per ASN:12.02
ARIN Region origin 

Re: Spitballing IoT Security

[Eliot Lear]

Moving offlist on this. For those who are interested, send ping.


On 11/11/16 4:42 PM, Marcel Plug wrote:
> On Fri, Nov 11, 2016 at 1:55 AM, Eliot Lear  > wrote:
>
> It is worth asking what protections are necessary for a device that
> regulates insulin.  
>
>
> Insulin pumps are an example of devices that have been over-regulated
> to the point where any and all innovation has been stifled.  There
> have been hardly any changes in the last 10+ years, during a time when
> all other technology has advanced quite a bit.  Its off-topic for
> Nanog, but i promise you this is very frustrating and annoying topic
> that hits me close to home.
>
> There has to be a middle ground.  I guarantee we do not want home
> firewalls, and all the IoT devices to be regulated like insulin pumps
> and other medical devices.  I think I'm starting to agree with those
> that want to keep government regulation out of this arena...
>
> Marcel
>  
>
> Eliot
>
>
> On 11/8/16 6:05 AM, Ronald F. Guilmette wrote:
> > In message <20161108035148.2904b5970...@rock.dv.isc.org
> >,
> > Mark Andrews mailto:ma...@isc.org>> wrote:
> >
> >> * Deploying regulation in one country means that it is less likely
> >>  to be a source of bad traffic.  Manufactures are lazy.  With
> >>  sensible regulation in single country everyone else benefits as
> >>  manufactures will use a single code base when they can.
> > I said that too, although not as concisely.
> >
> >> * Automated updates do reduce the numbers of vulnerable machines
> >>  to known issues.  There are risks but they are nowhere as bad as
> >>  not doing automated updating.
> > I still maintain, based upon the abundant evidence, that
> generallized
> > hopes that timely and effective updates for all manner of
> devices will
> > be available throughout the practical lifetime of any such IoT
> thingies
> > is a mirage.  We will just never be there, in practice.  And thus,
> > manufacturers should be encouraged, by force of law if necessary, to
> > design software with a belt-and-suspenders margin of safety built in
> > from the first day of shipping.
> >
> > You don't send out a spacecraft, or a medical radiation machine,
> without
> > such addtional constraints built in from day one.  You don't
> send out
> > such things and say "Oh, we can always send out of firmware
> update later
> > on if there is an issue."
> >
> > From a software perspective, building extra layers of
> constraints is not
> > that hard to do, and people have been doing this kind of thing
> already
> > for decades.  It's called engineering.  The problem isn't in
> anybody's
> > ability or inability to do safety engineering in the firmware of IoT
> > things.  The only problem is providing the proper motivation to
> cause
> > it to happen.
> >
> >
> > Regards,
> > rfg
> >
>
>
>



signature.asc
Description: OpenPGP digital signature

Re: Spitballing IoT Security

[Marcel Plug]

On Fri, Nov 11, 2016 at 1:55 AM, Eliot Lear 
wrote:

> It is worth asking what protections are necessary for a device that
> regulates insulin.


Insulin pumps are an example of devices that have been over-regulated to
the point where any and all innovation has been stifled.  There have been
hardly any changes in the last 10+ years, during a time when all other
technology has advanced quite a bit.  Its off-topic for Nanog, but i
promise you this is very frustrating and annoying topic that hits me close
to home.

There has to be a middle ground.  I guarantee we do not want home
firewalls, and all the IoT devices to be regulated like insulin pumps and
other medical devices.  I think I'm starting to agree with those that want
to keep government regulation out of this arena...

Marcel


> Eliot
>
>
> On 11/8/16 6:05 AM, Ronald F. Guilmette wrote:
> > In message <20161108035148.2904b5970...@rock.dv.isc.org>,
> > Mark Andrews  wrote:
> >
> >> * Deploying regulation in one country means that it is less likely
> >>  to be a source of bad traffic.  Manufactures are lazy.  With
> >>  sensible regulation in single country everyone else benefits as
> >>  manufactures will use a single code base when they can.
> > I said that too, although not as concisely.
> >
> >> * Automated updates do reduce the numbers of vulnerable machines
> >>  to known issues.  There are risks but they are nowhere as bad as
> >>  not doing automated updating.
> > I still maintain, based upon the abundant evidence, that generallized
> > hopes that timely and effective updates for all manner of devices will
> > be available throughout the practical lifetime of any such IoT thingies
> > is a mirage.  We will just never be there, in practice.  And thus,
> > manufacturers should be encouraged, by force of law if necessary, to
> > design software with a belt-and-suspenders margin of safety built in
> > from the first day of shipping.
> >
> > You don't send out a spacecraft, or a medical radiation machine, without
> > such addtional constraints built in from day one.  You don't send out
> > such things and say "Oh, we can always send out of firmware update later
> > on if there is an issue."
> >
> > From a software perspective, building extra layers of constraints is not
> > that hard to do, and people have been doing this kind of thing already
> > for decades.  It's called engineering.  The problem isn't in anybody's
> > ability or inability to do safety engineering in the firmware of IoT
> > things.  The only problem is providing the proper motivation to cause
> > it to happen.
> >
> >
> > Regards,
> > rfg
> >
>
>
>

RE: USDA IT Contacts?

[Herriage, James L.]

POCs here:
uda.gov = 162.79.29.12
https://whois.arin.net/rest/net/NET-162-79-0-0-1/pft?s=162.79.29.12


Thanks,
Lee

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Charles Gagnon
Sent: Thursday, November 10, 2016 4:20 PM
To: nanog@nanog.org
Subject: USDA IT Contacts?

*EXTERNAL EMAIL: EVALUATE*

Would anyone have information about IT contacts within the US Government?
Some of our IP ranges seem to be blocked from access to some government web 
servers (discovered on http://www.usda.gov - we get a odd "access denied"
page there - traces point to the same IP at akamaitechnologies.com).

I have NO idea who to discuss this with. I could not even find a "Contact Us" 
to use on their website.

Regards,

--
Charles Gagnon
http://unixrealm.com

Re: OSPF vs ISIS - Which do you prefer & why?

[Michael Hallgren]

Hi,

What IGP features do you need, and for what reason?

Cheers,
mh⁣​Le 10 nov. 2016, à 23:04, Josh Reynolds  a écrit:

I didn't "trash talk" a vendor. If I did, it would be a multi-thousand line
hate fueled rant with examples and enough colorful language to make
submarine crews blush.

Cisco has been pushing EIGRP and IS-IS as part of their "showing" for
decades. During that same time frame, the majority of the other vendors and
the open source daemons have been using OSPF as their IGP offering. In the
mean time, Cisco found a need to introduce more and more vendor specific
features into their IS-IS offering - no different than any other vendor
would do in their situation to promote the business case (better scaling,
vendor lock-in, other bits).

If you go looking for cross vendor compatibility with as many devices
(routers, switches, servers, etc) as possible, you're going to end up with
OSPF [or BGP, for the data center types that run it to edge nodes]. You
will find a handful, as some have mentioned, of vendors that have adopted
the open version of the protocol and have tried to add
comparable/compatible features to close the gap.

Since the last time I looked, I could not get the same feature sets running
IS-IS in a multi-vendor environment as I could running OSPF. This was my
experience at the time, based on my research and discussions with the
vendors.

On Nov 10, 2016 3:49 PM, "Nick Hilliard"  wrote:

Josh Reynolds wrote:

I'm sure a lot has changed with Juniper as of 2011 in regard to IS-IS
support, which was the last time *I* looked.

No, I do not have a list sitting ready, that catalogs in details
between product lines and specific firmware versions and subversions
between multiple vendors what one supports and what one does not as of
Nov 11, 2016.

What I can do is point you at the vendor list where you can make a
comparison of that vendor to others, for the features that you need in
your environment - as I'm not getting paid to maintain such lists, and
they are.


So what you're saying is that you can't even provide a single missing
feature to justify trash-talking a vendor the way you did? Not even one??

Nick

Le 10 nov. 2016 23:04, à 23:04, Josh Reynolds  a écrit:
>I didn't "trash talk" a vendor. If I did, it would be a multi-thousand
>line
>hate fueled rant with examples and enough colorful language to make
>submarine crews blush.
>
>Cisco has been pushing EIGRP and IS-IS as part of their "showing" for
>decades. During that same time frame, the majority of the other vendors
>and
>the open source daemons have been using OSPF as their IGP offering. In
>the
>mean time, Cisco found a need to introduce more and more vendor
>specific
>features into their IS-IS offering - no different than any other vendor
>would do in their situation to promote the business case (better
>scaling,
>vendor lock-in, other bits).
>
>If you go looking for cross vendor compatibility with as many devices
>(routers, switches, servers, etc) as possible, you're going to end up
>with
>OSPF [or BGP, for the data center types that run it to edge nodes]. You
>will find a handful, as some have mentioned, of vendors that have
>adopted
>the open version of the protocol and have tried to add
>comparable/compatible features to close the gap.
>
>Since the last time I looked, I could not get the same feature sets
>running
>IS-IS in a multi-vendor environment as I could running OSPF. This was
>my
>experience at the time, based on my research and discussions with the
>vendors.
>
>On Nov 10, 2016 3:49 PM, "Nick Hilliard"  wrote:
>
>> Josh Reynolds wrote:
>> > I'm sure a lot has changed with Juniper as of 2011 in regard to
>IS-IS
>> > support, which was the last time *I* looked.
>> >
>> > No, I do not have a list sitting ready, that catalogs in details
>> > between product lines and specific firmware versions and
>subversions
>> > between multiple vendors what one supports and what one does not as
>of
>> > Nov 11, 2016.
>> >
>> > What I can do is point you at the vendor list where you can make a
>> > comparison of that vendor to others, for the features that you need
>in
>> > your environment - as I'm not getting paid to maintain such lists,
>and
>> > they are.
>>
>> So what you're saying is that you can't even provide a single missing
>> feature to justify trash-talking a vendor the way you did?  Not even
>one??
>>
>> Nick
>>
>>

Re: USDA IT Contacts?

[Josh Reynolds]

Just a head's up, resolution may not happen today - it's veteran's day,
which of course is a federal holiday.

On Nov 11, 2016 8:17 AM, "Charles Gagnon"  wrote:

> Would anyone have information about IT contacts within the US Government?
> Some of our IP ranges seem to be blocked from access to some government web
> servers (discovered on http://www.usda.gov - we get a odd "access denied"
> page there - traces point to the same IP at akamaitechnologies.com).
>
> I have NO idea who to discuss this with. I could not even find a "Contact
> Us" to use on their website.
>
> Regards,
>
> --
> Charles Gagnon
> http://unixrealm.com
>

Re: USDA IT Contacts?

[Josh Reynolds]

*Cough*

I might know some people. Standby.

On Nov 11, 2016 8:17 AM, "Charles Gagnon"  wrote:

> Would anyone have information about IT contacts within the US Government?
> Some of our IP ranges seem to be blocked from access to some government web
> servers (discovered on http://www.usda.gov - we get a odd "access denied"
> page there - traces point to the same IP at akamaitechnologies.com).
>
> I have NO idea who to discuss this with. I could not even find a "Contact
> Us" to use on their website.
>
> Regards,
>
> --
> Charles Gagnon
> http://unixrealm.com
>

Re: OSPF vs ISIS - Which do you prefer & why?

[Josh Reynolds]

My first post:

On Nov 10, 2016 6:24 PM, "Charles van Niman"  wrote:

> Your original point was that a list of vendors "didn't get IS-IS" but
> provided no details about what you are talking about. As far as all
> the documentation I have read, and some of the documentation you
> linked to, it works just fine on quite a few vendors, and a few people
> on this list. Your original point mentions nothing about wider OSPF
> adoption, which you seem to have shifted to to deflect having to
> provide any actual details.
>
> Are we to assume that your original point was incorrect? As far as the
> landscape as a whole, I have seen quite a few networks that get by
> with either protocol just fine, the use-case for a given network is
> not such a broad landscape, so I think "use the right tool for the
> job" seems very apt, and that you can't just say that only two
> protocols are suitable for all jobs.
>
> /Charles
>
> On Thu, Nov 10, 2016 at 6:00 PM, Josh Reynolds 
> wrote:
> > As cute as your impotent white knighting of one vendor is (I very much
> like
> > Juniper BTW), you're absolutely ignoring my original premise and point
> > because you got your panties in a wad over a potential triviality of an
> > internet comment - where documentation exists, should one take the time
> to
> > go through it, to find discrepancies between them.
> >
> > So, if you'd like to prove your point and earn brownie points with
> $vendor,
> > on a feature by feature basis please take the time to consult
> documentation
> > of two vendors products (you can even pick the platform and subversion
> > release!) to refute my claim. This has nothing at all to do with the
> point
> > of my statement mind you, it's simply a sidetrack that has wasted enough
> > time already.
> >
> > That said, glance across the landscape as a whole of all of the routing
> > platforms out there. Hardware AND softwsre. Which ones support bare bones
> > IS-IS? Which ones have a decent subset of extensions? Are they comparable
> > or compatible with others? The end result is a *very mixed bag*, with far
> > more not supporting IS-IS at all, or only supporting the bare minimum to
> > even go by that name in a datasheet.
> >
> > Thus, my point stands. If you want as much flexibility in your
> environment
> > as you can have, you want OSPF or BGP as your IGP.
> >
> > On Nov 10, 2016 5:33 PM, "Nick Hilliard"  wrote:
> >
> >> Josh Reynolds wrote:
> >> > I didn't "trash talk" a vendor. If I did, it would be a multi-thousand
> >> > line hate fueled rant with examples and enough colorful language to
> make
> >> > submarine crews blush.
> >>
> >> I have no doubt it would be the best rant.  It would be a beautiful
> rant.
> >>
> >> Entertaining and all as hand-waving may be, please let us know if you
> >> manage to unearth any actual facts to support the claims that you made
> >> about junos's alleged feature deficits.
> >>
> >> Nick
> >>
> >>
>

USDA IT Contacts?

[Charles Gagnon]

Would anyone have information about IT contacts within the US Government?
Some of our IP ranges seem to be blocked from access to some government web
servers (discovered on http://www.usda.gov - we get a odd "access denied"
page there - traces point to the same IP at akamaitechnologies.com).

I have NO idea who to discuss this with. I could not even find a "Contact
Us" to use on their website.

Regards,

-- 
Charles Gagnon
http://unixrealm.com

Re: OSPF vs ISIS - Which do you prefer & why?

[Dragan Jovicic]

In my experience/personal opinion, compared to OSPF2/3, in a large ISP,
ISIS:

- has simpler and better, less bloated code. Think ISIS on Juniper. Think
FreeBSD vs Linux.
- is more modular to introduce new features.
- has certain knobs which makes it a bit more useful for ISP (LSP
lifetime/Max number of LSP fragments, etc).

This is for a large single L1/L2/backbone area. There are at least 2 design
options I would consider before switching to multi-area ISP design.

With that said I know of at least two of the largest ISPs tat use OSPF and
many use that favor ISIS so it really comes down to ISP's preference and
NOC willingness to learn new unfamiliar protocol.

BR




On Thu, Nov 10, 2016 at 3:35 PM, Mark Tinka  wrote:

>
>
> On 10/Nov/16 14:30, Joel M Snyder wrote:
>
> >
> >
> > In a world where you are doing well-controlled Cisco/Juniper/etc
> > networks with fairly homogeneous code bases, the engineers get to have
> > this discussion.  When you have to link in devices for which routing
> > is not their primary reason to exist, your options narrow very
> > quickly. It's not ideal; that's just the way it is.
>
> Quagga's IS-IS implementation is a great example.
>
> Mark.
>

AS37135, AS6560, AS32714, AS14029 - Squatted or not? You be the judge.

[Ronald F. Guilmette]

At least one person has now asserted to me in private email that
my suggestion that AS30186 was being squatted on was in fact accurate.
Thus, I now feel confident enough to provide here the rest of the story
which goes along with that.

In a nutshell, AS30186 and also two other ASNs, together appear to all
be parts of a single large multi-ASN squat.

In addition to what appears to be a squat on AS30186 (the former
Ross Technology Inc. of Austin, Texas, which even Wikipedia says
has been dead for lo these past 18 years) it appears to me, based
on the evidence, that the exact same large scale spamming company
is, at present, also usurping and squatting on two additional
AFRINIC ASNs, namely AS37135 and AS6560.  I provide here listings
of the current forward resolutions of a sizable number of snowshoe
spammer nonsense domain names (more than 1,400 in total) which are
currently associated with various portion of several apparently
illicitly appropriated AFRINIC /16 blocks:

AS37135:
  http://pastebin.com/raw/PkBagrpJ
AS6560
  http://pastebin.com/raw/zg9W2agN

The affected, and apparently long-orphaned AFRINIC IPv4 blocks involved
are as follows.  Note that these have each have their own AFRINIC block
registration records which indicate that they belong to, among others, a
chemicals & power company (155.237.0.0/16), a manufacturer of stainless
steel products (160.115.0.0/16), an international mining company
(163.197.0.0/16), a manufacturer of fertilizers and nitrogen compounds
(163.198.0.0/16), an agricultural chemicals company (164.155.0.0/16),
the Directorate of Information Services for the South African government
(165.25.0.0), a Seychelles Islands ISP (168.80.16.0/15), and a South
African outsourcing and business services company (196.9.0.0/16).
Despite these "official" IPv4 block registrations, based on the evidence
as shown in the above Pastebin reports, I am forced to conclude that
somehow, magically, all of these long-dormant African entities recently
began hosting parts of a large scale snowshoe spamming operation,
including even the Directorate of Information Services for the South
African government, as well as the South African Post Office (196.10.0.0./16),
both of which appear to be kindly lending a hand to these spammers also.

Here is the list of affected AFRINIC-allocatded IPv4 blocks:

152.108.0.0/16
155.159.0.0/16
155.235.0.0/16
155.237.0.0/16
160.115.0.0/16
160.116.0.0/16
160.122.0.0/16
163.197.0.0/16
163.198.0.0/16
164.155.0.0/16
165.25.0.0/16
168.76.0.0/16
168.80.16.0/15
196.9.0.0/16
196.10.0.0./16
196.16.0.0/14
196.15.64.0/18

Note that AS37135 and AS6560, which I contend are themselves being squatted
on, are currently announcing numerous discrete and discreet /20, /21, and
/19 blocks out of the above large blocks, perhaps with a view to the future
and to switching their announcements to other and different sub-blocks within
these same containing blocks, e.g. when they have so throughly sullied the
reputations of the blocks they are currently using so as to have caused
those blocks to be universally blacklisted everywhere.

In any case, here are the current announcements being made by AS37135
and AS6560, respectively.  Note that the set of announcements from these
ASNs has changed, and significantly, even just within the past 24 hours.
What you are seeing here is just the routes being announced by these
two suspicious ASNs as I write this.

AS37135:
152.108.0.0/19
155.235.80.0/20
155.235.128.0/19
155.235.224.0/19
155.237.128.0/21
155.237.128.0/19
160.115.32.0/20
160.115.48.0/20
160.115.64.0/20
160.115.80.0/20
160.115.96.0/20
160.115.112.0/20
160.116.112.0/20
160.116.160.0/20
160.116.192.0/20
160.122.0.0/19
160.122.128.0/21
160.122.240.0/21
163.198.0.0/20
163.198.64.0/20
168.76.128.0/20  -- Free State Education Department (not routed earlier today)
196.9.32.0/20
196.9.128.0/20

AS6560:
155.159.128.0/20
155.237.64.0/20
155.237.208.0/20
155.237.224.0/20
155.237.240.0/20
163.197.112.0/20
163.197.144.0/20
163.197.176.0/20
163.197.208.0/20
163.197.240.0/20
163.198.16.0/20
163.198.80.0/20
163.198.96.0/20
163.198.144.0/20
163.198.192.0/20
163.198.224.0/20
164.155.0.0/20
164.155.64.0/20
164.155.128.0/20
164.155.192.0/20
165.25.0.0/20
165.25.32.0/20
165.25.64.0/20
165.25.96.0/20
165.25.128.0/20
165.25.160.0/20
165.25.192.0/20
165.25.224.0/20
168.80.16.0/20
168.80.48.0/20
168.80.80.0/20
168.81.16.0/20
168.81.64.0/20
168.81.176.0/20
168.81.224.0/20
196.9.0.0/20
196.9.16.0/20
196.15.64.0/20
196.15.96.0/20

As I was preparing this post, two furter and additional dodgy looking
ASNs also came to my attention, and preliminary analysis suggests that
these two additional AFRINIC ASNs, AS32714, and AS14029, together with
all of the IP space they are announcing, may perhaps also be squatted on
at the present time.  Given below are the current announcements from
these two additional ASNs.  Note that AS32714 is currently announc

Re: OSPF vs ISIS - Which do you prefer & why?

[Mark Tinka]

On 11/Nov/16 12:07, Baldur Norddahl wrote:

> No filters. There are just no routes that will take a network packet that
> arrive on an interface in VRF internet and move it to an interface in VRF
> default without adding a MPLS header to mark the VRF. With the MPLS header
> the packet type is no longer IPv4 but MPLS.
>
> Therefore there is no way you from the internet or from a customer link can
> even attempt to inject packets that would be received by the OSPF process.
> Since we use 10.0.0.0/8 and our vrf internet has no such route, you would
> just get no route to host if you tried.

Good for you.

We don't run the whole "Internet in a VRF" architecture (too many moving
parts), so not having our IGP being exposed to IP helps :-).

Mark.

Re: OSPF vs ISIS - Which do you prefer & why?

[Baldur Norddahl]

Den 11. nov. 2016 06.41 skrev "Mark Tinka" :
>
>
>
> On 10/Nov/16 21:43, Baldur Norddahl wrote:
>
>>
>> And at the day work I also prefer OSPFv2 simply because I do not need
more protocols in the stack. We are running a MPLS network with the
internet service in a L3VPN. IPv6 is also in the L3VPN. This means the
underlying network is pure IPv4 and totally isolated from the internet. Why
make it more complicated by introducing something that is not IP based?
>
>
> I'd counter that "Why not make it less complicating by removing an
easily-reachable attack vector?"
>
> Sure, you can easily protect your OSPF domain from external attack, but
that's something your router CPU and/or data plane would have to deal with
it had to, and we've all seen situations where filters break in certain
code for various reasons. Or vendors change the way filtering works in
newer code without properly notifying customers about such changes.
>
> Mark.

No filters. There are just no routes that will take a network packet that
arrive on an interface in VRF internet and move it to an interface in VRF
default without adding a MPLS header to mark the VRF. With the MPLS header
the packet type is no longer IPv4 but MPLS.

Therefore there is no way you from the internet or from a customer link can
even attempt to inject packets that would be received by the OSPF process.
Since we use 10.0.0.0/8 and our vrf internet has no such route, you would
just get no route to host if you tried.

Regards

Baldur