Re: SNMP syslocation field for GPS coordinates, and use with automation tools
Since we all live on standards, I can suggest RFC7946, GeoJSON
(https://tools.ietf.org/html/rfc7946) for all of your location specification
needs:
{
"type" : "Point",
"coordinates" : [
-121.556359,
39.5137752
]
}
or one line (55 characters, no spaces, hopefully short enough):
{"type":"Point","coordinates":[-121.556359,39.5137752]}
GeoJSON supports "properties" which you can define how you like:
{
"type" : "Point",
"coordinates" : [
-121.556359,
39.5137752
],
"properties" : {
"address" : "121 Gigawatts Ave, Springfield, OH 45501
US",
"hardware" : "Cisco 2924",
"elevation" : "124m"
}
}
Note that many formats now list Longitude first, Latitude second.
http://www.macwright.org/lonlat/
I tend to try to offer/use machine-readable formats first, then human-readable,
because I live for automation. GeoJSON benefits from being both.
Beckman
On Fri, 9 Dec 2016, Eric Kuhnke wrote:
Yes, that's along the lines of what I was thinking. Pre-define a certain
number of columns of data that will fit in the snmp syslocation field in
most devices (some vendors have surprisingly short string length limits,
grr). And use something like a pipe delimited CSV format in that field,
so it has the comma separated decimal degrees lat/long in one column, and
human readable street address in another.
Also worth noting that many recent SNMP-enabled, high capacity point to
point microwave radios have built in GPS receivers for timing and location
purposes, which gather elevation data (in meters above MSL usually).
Perhaps a column for elevation in meters MSL. The sort of data that is
useful for a mobile network operator with thousands of point to point RF
links on rooftops and towers, for auditing and compliance purposes.
On Fri, Dec 9, 2016 at 2:09 PM, Alan Buxey wrote:
Yes. But don’t just put in coordinates... Put in other details and use a
standard separator 😊
alan
---
Peter Beckman Internet Guy
beck...@angryox.com http://www.angryox.com/
---
Re: SNMP syslocation field for GPS coordinates, and use with automation tools
This is an excellent suggestion and I'll do more research into use of the
geojson format from this RFC. Looks very similar to data that can be fed
through a small perl or python script to batch output google earth KML
format files, to give people a quick and easy GUI overview of an area. My
thought on the one line format is:
{"type":"Point","coordinates":[-121.556359,39.5137752]}
It may be better to just put the raw coordinates as
"-121.556359,39.5137752" in a specific pipe delimited place in the snmp
location string on the device, and have the python script running on the
system that is batch-querying all of the devices create the geojson on its
side after retrieving the coordinates, rather than putting the geojson
format in the device itself. This will hopefully allow for enough length to
put a full human readable street address in the syslocation field along
with the gps coordinates on even the most manufacturer-hobbled of devices.
As for the lat/long vs long/lat format question, that is a tough one...
Many users who've been using google maps or google earth are accustomed to
pasting in coordinates in a format like 39.5137,-121.5563 (lat/long), but
as that URL points out a large amount of GIS software does it the other way
around. I've seen a lot of other software not listed on that page which
operates in the format lat,long for human data entry of coordinates, or
when it uses two different fields for lat and long (in a GUI or its backend
storage), always places the lat field first and long second.
On Mon, Dec 12, 2016 at 9:36 AM, Peter Beckman wrote:
> Since we all live on standards, I can suggest RFC7946, GeoJSON
> (https://tools.ietf.org/html/rfc7946) for all of your location
> specification
> needs:
>
> {
> "type" : "Point",
> "coordinates" : [
> -121.556359,
> 39.5137752
> ]
> }
>
> or one line (55 characters, no spaces, hopefully short enough):
>
> {"type":"Point","coordinates":[-121.556359,39.5137752]}
>
> GeoJSON supports "properties" which you can define how you like:
>
> {
> "type" : "Point",
> "coordinates" : [
> -121.556359,
> 39.5137752
> ],
> "properties" : {
> "address" : "121 Gigawatts Ave, Springfield, OH
> 45501 US",
> "hardware" : "Cisco 2924",
> "elevation" : "124m"
> }
> }
>
> Note that many formats now list Longitude first, Latitude second.
> http://www.macwright.org/lonlat/
>
> I tend to try to offer/use machine-readable formats first, then
> human-readable,
> because I live for automation. GeoJSON benefits from being both.
>
> Beckman
>
>
> On Fri, 9 Dec 2016, Eric Kuhnke wrote:
>
> Yes, that's along the lines of what I was thinking. Pre-define a certain
>> number of columns of data that will fit in the snmp syslocation field in
>> most devices (some vendors have surprisingly short string length limits,
>> grr). And use something like a pipe delimited CSV format in that
>> field,
>> so it has the comma separated decimal degrees lat/long in one column, and
>> human readable street address in another.
>>
>> Also worth noting that many recent SNMP-enabled, high capacity point to
>> point microwave radios have built in GPS receivers for timing and location
>> purposes, which gather elevation data (in meters above MSL usually).
>> Perhaps a column for elevation in meters MSL. The sort of data that is
>> useful for a mobile network operator with thousands of point to point RF
>> links on rooftops and towers, for auditing and compliance purposes.
>>
>> On Fri, Dec 9, 2016 at 2:09 PM, Alan Buxey
>> wrote:
>>
>> Yes. But don’t just put in coordinates... Put in other details and use a
>>> standard separator 😊
>>>
>>>
>>>
>>>
>>>
>>> alan
>>>
>>>
>>
>
> ---
> Peter Beckman Internet Guy
> beck...@angryox.com
> http://www.angryox.com/
>
> ---
Build an anycast network on a shoestring
This is quite a nice write up by a colleague of mine: https://www.linkedin.com/pulse/build-your-own-anycast-network-9-steps-samir-jafferali
Re: Build an anycast network on a shoestring
@natmorris did something similar 18 months to 2 years or so ago too video below from uknof 30 .. https://youtu.be/itEtjsauwFQ Sent from Samsung Mobile on O2 Original message From: Franck Martin via NANOG Date: 12/12/2016 18:39 (GMT+00:00) To: NANOG Subject: Build an anycast network on a shoestring This is quite a nice write up by a colleague of mine: https://www.linkedin.com/pulse/build-your-own-anycast-network-9-steps-samir-jafferali
Re: Build an anycast network on a shoestring
Wow thanks for sharing both of these. Anycast can be "black magic" sometimes, and the more that is known about it by operators the better. I'm somewhat surprised that ECMP I've done a little poor-mans anycasting within a network by simply using OSPF and some /32's. Had IPv4 space not been at such a premium when I got into the game, I would have definitely attempted to get a larger block so that I could anycast a /24 of it. :-( Theodore Baschak - AS395089 - Hextet Systems https://ciscodude.net/ - https://hextet.systems/ http://mbix.ca/ On Mon, Dec 12, 2016 at 1:27 PM, chris wrote: > @natmorris did something similar 18 months to 2 years or so ago too > video below from uknof 30 .. > > https://youtu.be/itEtjsauwFQ > > > Sent from Samsung Mobile on O2 > Original message From: Franck Martin via NANOG < > nanog@nanog.org> Date: 12/12/2016 18:39 (GMT+00:00) To: NANOG < > nanog@nanog.org> Subject: Build an anycast network on a shoestring > This is quite a nice write up by a colleague of mine: > https://www.linkedin.com/pulse/build-your-own-anycast- > network-9-steps-samir-jafferali >
Re: Build an anycast network on a shoestring
> On Dec 12, 2016, at 1:59 PM, Theodore Baschak wrote: > > Wow thanks for sharing both of these. Anycast can be "black magic" > sometimes, and the more that is known about it by operators the better. Honestly, it’s not that difficult… Here are a few papers from quite a while ago, when some of the lessons were a little more recently-learned: https://www.pch.net/resources/Papers/anycast/ https://www.pch.net/resources/Papers/dns-service-architecture/dns-service-architecture-v11.pdf -Bill
Re: Build an anycast network on a shoestring
If you're doing ECMP w/i the DC, PMTUD does come to mind, though: https://blog.cloudflare.com/path-mtu-discovery-in-practice/ -- Hugo Slabbert | email, xmpp/jabber: h...@slabnet.com pgp key: B178313E | also on Signal On Mon 2016-Dec-12 15:59:29 -0600, Theodore Baschak wrote: Wow thanks for sharing both of these. Anycast can be "black magic" sometimes, and the more that is known about it by operators the better. I'm somewhat surprised that ECMP I've done a little poor-mans anycasting within a network by simply using OSPF and some /32's. Had IPv4 space not been at such a premium when I got into the game, I would have definitely attempted to get a larger block so that I could anycast a /24 of it. :-( Theodore Baschak - AS395089 - Hextet Systems https://ciscodude.net/ - https://hextet.systems/ http://mbix.ca/ On Mon, Dec 12, 2016 at 1:27 PM, chris wrote: @natmorris did something similar 18 months to 2 years or so ago too video below from uknof 30 .. https://youtu.be/itEtjsauwFQ Sent from Samsung Mobile on O2 Original message From: Franck Martin via NANOG < nanog@nanog.org> Date: 12/12/2016 18:39 (GMT+00:00) To: NANOG < nanog@nanog.org> Subject: Build an anycast network on a shoestring This is quite a nice write up by a colleague of mine: https://www.linkedin.com/pulse/build-your-own-anycast- network-9-steps-samir-jafferali signature.asc Description: Digital signature
