Re: Open Souce Network Operating Systems

[i mawsog via NANOG]

 I would second Peter's  advise.  Colton, for  you I would recommended you 
visit Cumulus' web site and follow their tutorials.  That should provide you 
with enough insights  for your next step. 


On Saturday, January 20, 2018, 11:27:38 AM PST, Colton Conor 
 wrote:  
 
 Peter,

Thanks for the information. Do you have a recommendation of which
distribution of Linux to use for this? Is there one that is more network
centric than another?

On Sat, Jan 20, 2018 at 1:11 PM, Peter Phaal  wrote:

> On Sat, Jan 20, 2018 at 9:32 AM, Colton Conor 
> wrote:
>>
>> My understanding if Free Range Routing is a package of software that runs
>> in linux, but not a full and true NOS right?
>>
>
> Why not consider Linux a NOS? Installing Free Range Routing adds control
> plane protocols: BGP, OSPF, ISIS, etc.
>
>
>> I looked into Cumulus Linux, but it seems to only run on the supported
>> hardware which is while box switches. Can you run Cumulus Linux on a X86
>> server with intel NICs? Can you run Cumulus on a raspberry pi?
>>
>
> Cumulus Linux is basically Ubuntu with Free Range Routing pre-installed
> along with a daemon that offloads forwarding from the Linux kernel to an
> ASIC. CumulusVX is a free Cumulus Linux virtual machine that is useful for
> staging / testing configurations since it has the same behavior as the
> hardware switch.
>
> On X86 servers with Intel NICs, just run Linux. Cumulus Host Pack can be
> installed to add Free Range Routing and other Cumulus tools on the server.
> Alternatively, you can choose any Linux control plane, automation, or
> monitoring tools and install them on the hosts and Cumulus Linux switches
> to unify management and control, e.g. Bird, collectd, telegraf, Puppet,
> Chef, Ansible, etc.
>
> Linux distros (including Ubuntu) are available for non-X86 hardware like
> Raspberry Pi etc.
>
>
>>
>> Ideally I think I am looking to a Linux operating system that can run on
>> multiple CPU architectures, has device support for Broadcom and other
>> Merchant silicon switching and wifi adapters.
>
>
> If you consider Linux as the NOS then it already meets these requirements.
>
  

Re: Best way to San Jose Fairmont from SFO?

[i mawsog via NANOG]

Google SFO SJC 

  From: Julien Goodwin 
 To: nanog@nanog.org 
 Sent: Thursday, September 28, 2017 11:09 PM
 Subject: Re: Best way to San Jose Fairmont from SFO?
   
On 29/09/17 06:47, Bob Evans wrote:
> Train and Bus travel is not worth considering. However, there are airport
> shuttle van services like supershuttle 4-5 passengers being dropped off on
> your way south.

I'm arriving on Sunday morning, so have plenty of time, and will take
Caltrain down (BART to Millbrae, then Caltrain), sure it'll take 2h, but
any van service wouldn't be much faster.

During the week, or out of daylight hours it's a much less sensible idea.


   

Re: Protocol 17 floods from Vietnam & Mexico?

[i mawsog via NANOG]

The port info is in the first  fragmented packet as was mentioned elsewhere.  
My guess is someone fragmenting large packets ( the mtu is set to  1464 or so). 
and  the host is receiving those fragment, but it not  reconstructing the 
packets.  If  it is possible to do a tcpdump/wireshark etc , then the content 
of the packets can be very easily observed .  
18:04:32.391082 IP 138-122-97-251.internet.static.ientc.mx > 
umbrellix.net: ip-proto-17
18:04:32.391088 IP 138-122-97-251.internet.static.ientc.mx > 
umbrellix.net: ip-proto-17
18:04:32.391110 IP 115.75.50.106.35180 > umbrellix.net.10454: UDP, bad 
length 65500 > 1464
18:04:32.391145 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391152 IP 115.75.50.106 > umbrellix.net: ip-proto-17
18:04:32.391158 IP 115.75.50.106 > umbrellix.net: ip-proto-17



  From: Christopher Morrow 
 To: Krunal Shah  
Cc: "nanog@nanog.org" 
 Sent: Wednesday, September 13, 2017 7:59 AM
 Subject: Re: Protocol 17 floods from Vietnam & Mexico?
   
On Wed, Sep 13, 2017 at 9:59 AM, Krunal Shah  wrote:

> It might be spoofed source IPs
>
>
if you are seeing large fragmented udp packets.. it's almost always not
spoofed.
or historically speaking anyway it's not been spoofed.

There are cases with dns reflection that include spoofing, but by the time
you see the large packet .. that's not spoofed it's coming from the dns
server talking to you, why it's talking to you is due to spoofing, but
that's outside (most times) your span of control.


>
> Krunal Shah
>
>
>
>
>
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mark Andrews
> Sent: Tuesday, September 12, 2017 10:45 PM
> To: Large Hadron Collider
> Cc: nanog@nanog.org
> Subject: Re: Protocol 17 floods from Vietnam & Mexico?
>
>
> In message <08ed2903-c81c-aa2e-cd04-4fa117840...@gmx.com>, Large Hadron
> Collider writes:
> > Yes, I'm being UDP flooded. I worked that out by grepping /etc/protocols.
> >
> >
> > On 12/09/2017 18:24, Matt Harris wrote:
> > > Protocol 17 is UDP.  UDP is pretty common on the internet. Not sure
> > > why source and destination ports aren't being shown by your tool
> > > there, might be malformed UDP packets designed to obscure themselves
> > > from or otherwise evade some intrusion detection or firewall systems.
>
> No ports are listed because they are not the initial fragment of the UDP
> packet.  Only the initial fragment that contains the UDP header has the
> ports reported.
>
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                INTERNET: ma...@isc.org
>
>
>
> 
> This electronic message contains information from Primus Management ULC
> ("PRIMUS") , which may be legally privileged and confidential. The
> information is intended to be for the use of the individual(s) or entity
> named above. If you are not the intended recipient, be aware that any
> disclosure, copying, distribution or use of the contents of this
> information is prohibited. If you have received this electronic message in
> error, please notify us by telephone or e-mail (to the number or address
> above) immediately. Any views, opinions or advice expressed in this
> electronic message are not necessarily the views, opinions or advice of
> PRIMUS. It is the responsibility of the recipient to ensure that any
> attachments are virus free and PRIMUS bears no responsibility for any loss
> or damage arising in any way from the use thereof.The term "PRIMUS"
> includes its affiliates.
> 
> Pour la version en français de ce message, veuillez voir
> http://www.primustel.ca/fr/legal/cs.htm
>
>

   

Re: Google DNS --- Figuring out which DNS Cluster you are using

[i mawsog via NANOG]

This is great.  Thanks for sharing . 

Sent from Yahoo Mail on Android 
 
  On Wed, Aug 23, 2017 at 1:11 PM, Erik Sundberg wrote: 
  I sent this out on the outage list, with a lots of good feedback sent to me. 
So I figured it would be useful to share the information on nanog as well.


A couple months ago had to troubleshoot a google DNS issue with Google’s NOC. 
Below is some helpful information on how to determine which DNS Cluster you are 
going to.

Let’s remember that Google runs DNS Anycast for DNS queries to 8.8.8.8 and 
8.8.4.4. Anycast routes your DNS queries to the closes DNS cluster based on the 
best route / lowest metric to 8.8.8.8/8.8.4.4.  Google has deployed multiple 
DNS clusters across the world and each DNS Cluster has multiple servers.

So a DNS query in Chicago will go to a different DNS clusters than queries from 
a device in Atlanta or New York.


How to get a list of google DNS Cluster’s.
dig -t TXT +short locations.publicdns.goog. @8.8.8.8

How to print this list in a table format. Script from: 
https://developers.google.com/speed/public-dns/faq
---
#!/bin/bash
IFS="\"$IFS"
for LOC in $(dig -t TXT +short locations.publicdns.goog. @8.8.8.8)
do
  case $LOC in
    '') : ;;
    *.*|*:*) printf '%s ' ${LOC} ;;
    *) printf '%s\n' ${LOC} ;;
  esac
done
---

Which will give you a list like below. This is all of the IP network’s that 
google uses for their DNS Clusters and their associated locations.

74.125.18.0/26 iad
74.125.18.64/26 iad
74.125.18.128/26 syd
74.125.18.192/26 lhr
74.125.19.0/24 mrn
74.125.41.0/24 tpe
74.125.42.0/24 atl
74.125.44.0/24 mrn
74.125.45.0/24 tul
74.125.46.0/24 lpp
74.125.47.0/24 bru
74.125.72.0/24 cbf
74.125.73.0/24 bru
74.125.74.0/24 lpp
74.125.75.0/24 chs
74.125.76.0/24 cbf
74.125.77.0/24 chs
74.125.79.0/24 lpp
74.125.80.0/24 dls
74.125.81.0/24 dub
74.125.92.0/24 mrn
74.125.93.0/24 cbf
74.125.112.0/24 lpp
74.125.113.0/24 cbf
74.125.115.0/24 tul
74.125.176.0/24 mrn
74.125.177.0/24 atl
74.125.179.0/24 cbf
74.125.181.0/24 bru
74.125.182.0/24 cbf
74.125.183.0/24 cbf
74.125.184.0/24 chs
74.125.186.0/24 dls
74.125.187.0/24 dls
74.125.190.0/24 sin
74.125.191.0/24 tul
172.217.32.0/26 lhr
172.217.32.64/26 lhr
172.217.32.128/26 sin
172.217.33.0/26 syd
172.217.33.64/26 syd
172.217.33.128/26 fra
172.217.33.192/26 fra
172.217.34.0/26 fra
172.217.34.64/26 bom
172.217.34.192/26 bom
172.217.35.0/24 gru
172.217.36.0/24 atl
172.217.37.0/24 gru
173.194.90.0/24 cbf
173.194.91.0/24 scl
173.194.93.0/24 tpe
173.194.94.0/24 cbf
173.194.95.0/24 tul
173.194.97.0/24 chs
173.194.98.0/24 lpp
173.194.99.0/24 tul
173.194.100.0/24 mrn
173.194.101.0/24 tul
173.194.102.0/24 atl
173.194.103.0/24 cbf
173.194.168.0/26 nrt
173.194.168.64/26 nrt
173.194.168.128/26 nrt
173.194.168.192/26 iad
173.194.169.0/24 grq
173.194.170.0/24 grq
173.194.171.0/24 tpe
2404:6800:4000::/48 bom
2404:6800:4003::/48 sin
2404:6800:4006::/48 syd
2404:6800:4008::/48 tpe
2404:6800:400b::/48 nrt
2607:f8b0:4001::/48 cbf
2607:f8b0:4002::/48 atl
2607:f8b0:4003::/48 tul
2607:f8b0:4004::/48 iad
2607:f8b0:400c::/48 chs
2607:f8b0:400d::/48 mrn
2607:f8b0:400e::/48 dls
2800:3f0:4001::/48 gru
2800:3f0:4003::/48 scl
2a00:1450:4001::/48 fra
2a00:1450:4009::/48 lhr
2a00:1450:400b::/48 dub
2a00:1450:400c::/48 bru
2a00:1450:4010::/48 lpp
2a00:1450:4013::/48 grq

There are
IPv4 Networks: 68
IPv6 Networks: 20
DNS Cluster’s Identified by POP Code’s: 20

DNS Clusters identified by POP Code to City, State, or Country. Not all of 
these are Google’s Core Datacenters, some of them are Edge Points of Presences 
(POPs). https://peering.google.com/#/infrastructure and 
https://www.google.com/about/datacenters/inside/locations/

Most of these are airport codes, it did my best to get the location correct.
iad          Washington, DC
syd        Sydney, Australia
lhr          London, UK
mrn        Lenoir, NC
tpe        Taiwan
atl          Altanta, GA
tul          Tulsa, OK
lpp          Findland
bru        Brussels, Belgium
cbf        Council Bluffs, IA
chs        Charleston, SC
dls          The Dalles, Oregon
dub        Dublin, Ireland
sin          Singapore
fra          Frankfort, Germany
bom      Mumbai, India
gru        Sao Paulo, Brazil
scl          Santiago, Chile
nrt          Tokyo, Japan
grq        Groningen, Netherlans



Which Google DNS Server Cluster am I using. I am testing this from Chicago, IL

# dig o-o.myaddr.l.google.com -t txt +short @8.8.8.8
"173.194.94.135"                    <

test - ignore

[i mawsog via NANOG]

test - ignore

Re: Vendors spamming NANOG attendees

[i mawsog via NANOG]

Agree, this thread has generated more "spam" or noise for all of us 
collectively. 
Some amount of relevant "spam"  has to be tolerated for vendor to continue 
supporting NANOG. Also relevant "spam" or sales call is a good way to find out 
about new technologies , that one may not have heard about otherwise.  
Another tip, just ignore,  the "spammer" will go away eventually.  


Sent from Yahoo Mail on Android 
 
  On Wed, Jun 14, 2017 at 6:45 AM, Rodney Joffe wrote:   
I guess that explains why so many newcomers are confused about what spam is. 

> On Jun 14, 2017, at 5:33 AM, Ge Dupin  wrote:
> 
> It looks like there are more spams coming from these discussions than from 
> the original Scams/Spams..
> Ge
> 
>>> Le 14 juin 2017 à 14:26, Rodney Joffe  a écrit :
>>> 
>>> 
>>> 
>>> On Jun 13, 2017, at 10:28 PM, Mel Beckman  wrote:
>>> 
>>> But as I said, harvesting emails is not illegal under can spam. And the 
>>> requirement to not send you UCE to harvested emails is pointless, because 
>>> how do you prove that someone did that?
>>> 
>> Because he said so?
>> 
>> The spammer had the balls to say, in his email:
>> 
>>> 
>>> We do not know each other. I'm leveraging the attendee list for NANOG 
>>> to reach out and raise awareness of the value of OCS (Optical Circuit 
>>> Switching) in the data center and in particular, the Carrier Neutral 
>>> Hotel where we've been active with next generation MeetMeRoom 
>>> discussions.
>> 
>> 
>   

Troubleshooting most encountered BGP issues

[i mawsog via NANOG]

Trying  to make a  check list  for  troubleshooting  common BGP issues .  The 
list is as follows. 
Configuration issues :
1.  Incorrect MD52.  Incorrect peer ASN, IP 

Runtime issues :
1.  Path flap 2.  Path hijack 

Would like to grow this  list with appropriate pointers and details.  Or, if 
anyone is aware of  such such a list's existence , would be glad to added to 
that . 





   

Top 5 BGP issues

[i mawsog via NANOG]

Wondering what are the top 5  BGP issues that folks on this list faces ?  Any 
comments welcome. 

Re: vFlow :: IPFIX, sFlow and Netflow collector

[i mawsog via NANOG]

A few questions and  comments. 
1. Is there any  good  open repository of netwflow data ?     
2. How about open repository of raw packet capture ? 3. There are many 
companies that help collect  raw packet -  Gigamon, BigSwitch, ... .  Do folks 
on this list have any experiences  with these vendors ? 3. xFLows are  
apparently the only   detailed metric collected on a wider scale.  I heard even 
that is often considered a nuisance for the value it  provides .  What are the 
experiences of the the folks on this list  ?   Where and how netflow is usually 
collected ? 
SG

  From: Mehrdad Arshad Rad 
 To: Vitaly Nikolaev  
Cc: nanog@nanog.org
 Sent: Wednesday, May 17, 2017 7:01 AM
 Subject: Re: vFlow :: IPFIX, sFlow and Netflow collector
   
I tried w/ standalone MemSQL w/ 100K IPFIX samples per second and it works.
if you pay MemSQL license you can have more than one node (cluster).
another solution is ClickHouse https://clickhouse.yandex/ but I'm gonna to
test it soon :-)
The MemSQL's nice feature is it has built in Kafka consumer w/ transform
feature.

On Tue, May 16, 2017 at 8:04 AM, Vitaly Nikolaev  wrote:

> Hello,
>
> Interesting, what receives and where do you keep flows at the other end of
> messaging bus ?
>
>
> PS: in my case I am talking about hundreds of kilo flows/s that I would
> like to keep for at least few weeks, so MemSQL or any other SQLs are out of
> the picture.
>
> Thank you
>
>
> On Mon, May 15, 2017 at 2:31 PM, Mehrdad Arshad Rad 
> wrote:
>
>> Hi all,
>>
>> I just wanted to share the vFlow - IPFIX, sFlow and Netflow collector,
>> it's
>> scalable and reliable, written by pure Golang!
>> It doesn't have any library dependency and works w/ Kafka and NSQ (you can
>> write your own MQ plugin).
>>
>> https://github.com/VerizonDigital/vflow
>>
>> For more information
>> https://www.linkedin.com/pulse/high-performance-scalable-
>> reliable-ipfix-sflow-open-arshad-rad
>>
>> It can be able to integrate w/ MemSQL easy and you can have kind of below
>> SQL query:
>>
>> memsql> select * from samples order by bytes desc limit 20;
>> ++-+-+--
>> --++---+-+-+--++
>> -+
>> | device        | src            | dst            | srcASN | dstASN
>> | proto | srcPort | dstPort | tcpFlags | bytes  | datetime
>> |
>> ++-+-+--
>> --++---+-+-+--++
>> -+
>> | 192.129.230.0  | 87.11.81.121    | 61.231.215.18  | 131780 |  21773
>> |    6 |      80 |  64670 | 0x10    | 342000 | 2017-04-27 22:05:55
>> |
>> | 52.20.79.116  | 87.11.81.100    | 216.38.140.154  |  41171 |  7994
>> |    6 |    443 |  26798 | 0x18    | 283364 | 2017-04-27 22:06:00
>> |
>> | 52.20.79.116  | 192.229.211.70  | 50.240.197.150  |  41171 |  33651
>> |    6 |      80 |  23397 | 0x10    | 216000 | 2017-04-27 22:05:55
>> |
>> | 108.161.249.16 | 152.125.33.113  | 74.121.78.10    |  13768 |  9551
>> |    6 |      80 |  49217 | 0x18    | 196500 | 2017-04-27 22:05:59
>> |
>> | 192.229.130.0  | 87.21.81.254    | 94.56.54.135    | 132780 |  21773
>> |    6 |      80 |  52853 | 0x18    | 165000 | 2017-04-27 22:05:55
>> |
>> | 108.161.229.96 | 93.184.215.169  | 152.157.32.200  |  12768 |  11430
>> |    6 |    443 |  50488 | 0x18    |  86400 | 2017-04-27 22:06:01
>> |
>> | 52.22.49.106  | 122.229.210.189 | 99.31.208.183  |  22171 |  8018
>> |    6 |    443 |  33059 | 0x18    |  73500 | 2017-04-27 22:05:55
>> |
>> | 52.22.49.126  | 81.21.81.131    | 66.215.169.120  |  22171 |  20115
>> |    6 |      80 |  57468 | 0x10    |  66000 | 2017-04-27 22:05:59
>> |
>> | 108.160.149.96 | 94.184.215.151  | 123.90.233.120  |  16768 |  14476
>> |    6 |      80 |  63905 | 0x18    |  65540 | 2017-04-27 22:05:57
>> |
>> | 52.22.79.116  | 162.129.210.181 | 60.180.253.156  |  21271 |  31651
>> |    6 |    443 |  59652 | 0x18    |  64805 | 2017-04-27 22:06:00
>> |
>> | 108.161.149.90 | 93.184.215.169  | 80.96.58.146    |  13868 |  22394
>> |    6 |    443 |    1151 | 0x18    |  59976 | 2017-04-27 22:05:54
>> |
>> | 102.232.179.20 | 111.18.232.131  | 121.62.44.149  |  24658 |  4771
>> |    6 |      80 |  61076 | 0x10    |  59532 | 2017-04-27 22:05:54
>> |
>> | 102.232.179.20 | 192.129.145.6  | 110.49.221.232  |  24658 |  4804
>> |    6 |    443 |  50002 | 0x10    |  58500 | 2017-04-27 22:05:55
>> |
>> | 102.232.179.20 | 192.129.232.112 | 124.132.217.101 |  24658 |  43124
>> |    6 |    443 |  37686 | 0x10    |  57000 | 2017-04-27 22:06:00
>> |
>> | 192.229.230.0  | 87.11.81.253    | 219.147.144.22  | 132380 |  2900
>> |    6 |      80 |  25202 | 0x18    |  56120 | 2017-04-27 22:05:58
>> |
>> | 192.129.130.0  | 87.21.11.200    | 180.239.187.151 | 132380 |  8151
>> |    6 |    443 |  55062 | 0x18    |  52220 | 2017-04-27 22:05:59
>> |
>> | 52.12.79.126  |