Re: Interconnection Track
Scheduling question: I assume this is the slot on the agenda that say: "NANOG 70 Peering Coordination Forum" I'm not seeing it on the schedule. Has a lot been assigned? John Kemp On 4/17/17 6:03 AM, Bevan Slattery wrote: > Hi! Love the interconnection track. Great stuff. But I can't help but > think limiting interconnection to the peering/IXP view seems to be looking at > interconnection from the rear view mirror. > > I just think that changing the track name from peering/IXP to > "Interconnection" has the optionality to be a bit more looking forward. > Interconnection in the network world is becoming more sophisticated and > important than just old school peering (hearing the gasps of horror from the > Nanog peering cabal at that statement) ;) > > Cheers > > [b] > >> On 17 Apr 2017, at 9:52 pm, Mehmet Akcin <meh...@akcin.net> wrote: >> >> Thank you very much for sending privately and publicly an overwhelming >> number of suggestions. I do appreciate you taking time and writing things >> up in detail. I am doing my best with help of Greg H from PC to put these >> thoughts on paper. >> >> It looks like there is a great interest to make this track focusing on >> tooling and automation as well as introductions of new game changing ixps. >> >> I would like to invite all new IXPs to come and talk about what they offer >> (ie denver-ix) >> >> I also would like to invite any existing IXPs to announce price discounts >> to their services. This is the only update we will have time in this >> interconnection track. Unfortunately no graphs, other updates. >> >> Few questions, Seattle is beautiful in summer and I hope to have many of >> you in person in beautiful washington state, but for those who can't >> travel, should we record / live stream this session? (Historically we did >> keep peering track off the grid... i believe) >> >> Would it be interesting to focus on peering challenges globally or strictly >> focus on north america? >> >> Last but not least, If you have a tool you want to talk about in >> interconnection track that is directly involved with peering setup, etc. >> please do contact me offlist. >> >> Cheers! Looking forward to it. >> >>> On Sat, Apr 1, 2017 at 1:36 PM Mehmet Akcin <meh...@akcin.net> wrote: >>> >>> Hello, >>> >>> As promised few months ago publically I have volunteered to bring together >>> content to have Peering Track back to agenda. Now called "Interconnection >>> Track" >>> >>> I would like to ask those who will attend, have attended in person in the >>> past or those who have organized similar events to chime in and help >>> suggest topics to cover in this 90 min session. >>> >>> I must say, Interconnection Track has been a major part if NANOG for many >>> years. We have watched those who we consider as legends to discuss very >>> important topics there. >>> >>> Please try to make your suggestion in order of importance for you as well >>> as from community. >>> >>> I can try to do my best with help of few folks to bring this track back >>> but you can help make it even better so please take a moment and send me >>> your suggestions. >>> >>> Thanks in advance! >>> >>> Mehmet >>>
Re: Peering BOF/Peering social @NANOG69?
I would like to see the session continue in some form. Social was close to good. The peering presentations weren't as useful to me personally. They sometimes made the time for actual peering conversations too short. The extra food and drinks were not important to me personally. ... Perhaps an "extended break" 45 minutes, with typical break food, and no presentations. Or if you want, a *silent* rolling slide show on a screen, with 1-slide per submitter, for peering news items or general peering requests... Cheaper... quieter... shorter... But having all the people in the same room at the same time for the same purpose, usually pretty useful. 2 cents, John Kemp On 2/6/17 9:17 PM, Dave Temkin wrote: > Hi Bob, > > This was inadvertent and we will bring this back for NANOG 70. > > Regards, > > -Dave > > On Feb 6, 2017, 6:58 PM -0500, Bob Evans <b...@fiberinternetcenter.com>, > wrote: >> I suggest in the future NOT to get rid of something because a new method >> is attempted. I.E nanog had a nice method of identifying potential and >> existing peers with a simple green dot at registration to indicate an >> individual was involved with BGP in their company. That went away and >> today there is nothing. Cost of implementation was less than 5 dollars at >> any office supply retailer. >> >> Just a thought. >> >> Thank You >> Bob Evans >> CTO >> >> >> >> >>> The Peering Personals has been shelved while we try to figure out a better >>> option. >>> >>> There was no peering content submitted to the Program Committee that >>> justified a separate track, and so they chose to include the content in >>> the general session throughout the program. >>> >>> Regards, >>> >>> -Dave >>> >>> On Feb 6, 2017, 8:12 AM -0500, Matthew Petach <mpet...@netflight.com>, >>> wrote: >>>> I'm squinting at the Guidebook for NANOG69, >>>> and I don't seem to see any peering BOF or >>>> peering social this time around. Am I being >>>> blind again, and it's on the agenda somewhere >>>> but I'm just overlooking it? >>>> Pointers in the right direction would be appreciated. >>>> >>>> Thanks! :) >>>> >>>> Matt >>> >> >>
Re: Routeviews
It's back/renewed as of... Domain Name: ROUTEVIEWS.ORG Domain ID: D48496876-LROR WHOIS Server: Referral URL: http://www.networksolutions.com Updated Date: 2016-12-16T18:41:42Z Creation Date: 2000-12-14T23:05:47Z John Kemp On 12/16/16 9:44 AM, John Kemp wrote: > > We're looking at it now. Thanks. > > John Kemp > > On 12/16/16 9:21 AM, Marty Strong via NANOG wrote: >> Looks like somebody didn’t renew the domain >> >> $ whois routeviews.org >> Domain Name: ROUTEVIEWS.ORG >> Domain ID: D48496876-LROR >> WHOIS Server: >> Referral URL: http://www.networksolutions.com >> Updated Date: 2016-12-16T10:30:46Z >> Creation Date: 2000-12-14T23:05:47Z >> Registry Expiry Date: 2017-12-14T23:05:47Z >> Sponsoring Registrar: Network Solutions, LLC >> Sponsoring Registrar IANA ID: 2 >> Domain Status: clientTransferProhibited >> https://icann.org/epp#clientTransferProhibited >> Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod >> Registrant ID: C11717-NS >> Registrant Name: Perfect Privacy, LLC >> Registrant Organization: Network Solutions LLC >> Registrant Street: 12808 Gran Bay Parkway West >> Registrant Street: care of Network Solutions (DOMAIN-RESALE) >> Registrant Street: FL >> Registrant City: Jacksonville >> Registrant State/Province: FL >> Registrant Postal Code: 32217 >> Registrant Country: US >> Registrant Phone: +1.5707088780 >> Registrant Phone Ext: >> Registrant Fax: +1.5707088780 >> Registrant Fax Ext: >> Registrant Email: pendingrenewalordelet...@networksolutions.com >> Admin ID: C11717-NS >> Admin Name: Perfect Privacy, LLC >> Admin Organization: Network Solutions LLC >> Admin Street: 12808 Gran Bay Parkway West >> Admin Street: care of Network Solutions (DOMAIN-RESALE) >> Admin Street: FL >> Admin City: Jacksonville >> Admin State/Province: FL >> Admin Postal Code: 32217 >> Admin Country: US >> Admin Phone: +1.5707088780 >> Admin Phone Ext: >> Admin Fax: +1.5707088780 >> Admin Fax Ext: >> Admin Email: pendingrenewalordelet...@networksolutions.com >> Tech ID: C11717-NS >> Tech Name: Perfect Privacy, LLC >> Tech Organization: Network Solutions LLC >> Tech Street: 12808 Gran Bay Parkway West >> Tech Street: care of Network Solutions (DOMAIN-RESALE) >> Tech Street: FL >> Tech City: Jacksonville >> Tech State/Province: FL >> Tech Postal Code: 32217 >> Tech Country: US >> Tech Phone: +1.5707088780 >> Tech Phone Ext: >> Tech Fax: +1.5707088780 >> Tech Fax Ext: >> Tech Email: pendingrenewalordelet...@networksolutions.com >> Name Server: NS1.PENDINGRENEWALDELETION.COM >> Name Server: NS2.PENDINGRENEWALDELETION.COM >> DNSSEC: unsigned >>>>> Last update of WHOIS database: 2016-12-16T17:19:44Z <<< >> >> For more information on Whois status codes, please visit >> https://icann.org/epp >> >> Access to Public Interest Registry WHOIS information is provided to assist >> persons in determining the contents of a domain name registration record in >> the Public Interest Registry registry database. The data in this record is >> provided by Public Interest Registry for informational purposes only, and >> Public Interest Registry does not guarantee its accuracy. This service is >> intended only for query-based access. You agree that you will use this data >> only for lawful purposes and that, under no circumstances will you use this >> data to(a) allow, enable, or otherwise support the transmission by e-mail, >> telephone, or facsimile of mass unsolicited, commercial advertising or >> solicitations to entities other than the data recipient's own existing >> customers; or (b) enable high volume, automate >> >> Regards, >> Marty Strong >> -- >> Cloudflare - AS13335 >> Network Engineer >> ma...@cloudflare.com >> +44 7584 906 055 >> smartflare (Skype) >> >> https://www.peeringdb.com/asn/13335 >>
Re: Routeviews
We're looking at it now. Thanks. John Kemp On 12/16/16 9:21 AM, Marty Strong via NANOG wrote: > Looks like somebody didn’t renew the domain > > $ whois routeviews.org > Domain Name: ROUTEVIEWS.ORG > Domain ID: D48496876-LROR > WHOIS Server: > Referral URL: http://www.networksolutions.com > Updated Date: 2016-12-16T10:30:46Z > Creation Date: 2000-12-14T23:05:47Z > Registry Expiry Date: 2017-12-14T23:05:47Z > Sponsoring Registrar: Network Solutions, LLC > Sponsoring Registrar IANA ID: 2 > Domain Status: clientTransferProhibited > https://icann.org/epp#clientTransferProhibited > Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod > Registrant ID: C11717-NS > Registrant Name: Perfect Privacy, LLC > Registrant Organization: Network Solutions LLC > Registrant Street: 12808 Gran Bay Parkway West > Registrant Street: care of Network Solutions (DOMAIN-RESALE) > Registrant Street: FL > Registrant City: Jacksonville > Registrant State/Province: FL > Registrant Postal Code: 32217 > Registrant Country: US > Registrant Phone: +1.5707088780 > Registrant Phone Ext: > Registrant Fax: +1.5707088780 > Registrant Fax Ext: > Registrant Email: pendingrenewalordelet...@networksolutions.com > Admin ID: C11717-NS > Admin Name: Perfect Privacy, LLC > Admin Organization: Network Solutions LLC > Admin Street: 12808 Gran Bay Parkway West > Admin Street: care of Network Solutions (DOMAIN-RESALE) > Admin Street: FL > Admin City: Jacksonville > Admin State/Province: FL > Admin Postal Code: 32217 > Admin Country: US > Admin Phone: +1.5707088780 > Admin Phone Ext: > Admin Fax: +1.5707088780 > Admin Fax Ext: > Admin Email: pendingrenewalordelet...@networksolutions.com > Tech ID: C11717-NS > Tech Name: Perfect Privacy, LLC > Tech Organization: Network Solutions LLC > Tech Street: 12808 Gran Bay Parkway West > Tech Street: care of Network Solutions (DOMAIN-RESALE) > Tech Street: FL > Tech City: Jacksonville > Tech State/Province: FL > Tech Postal Code: 32217 > Tech Country: US > Tech Phone: +1.5707088780 > Tech Phone Ext: > Tech Fax: +1.5707088780 > Tech Fax Ext: > Tech Email: pendingrenewalordelet...@networksolutions.com > Name Server: NS1.PENDINGRENEWALDELETION.COM > Name Server: NS2.PENDINGRENEWALDELETION.COM > DNSSEC: unsigned >>>> Last update of WHOIS database: 2016-12-16T17:19:44Z <<< > > For more information on Whois status codes, please visit https://icann.org/epp > > Access to Public Interest Registry WHOIS information is provided to assist > persons in determining the contents of a domain name registration record in > the Public Interest Registry registry database. The data in this record is > provided by Public Interest Registry for informational purposes only, and > Public Interest Registry does not guarantee its accuracy. This service is > intended only for query-based access. You agree that you will use this data > only for lawful purposes and that, under no circumstances will you use this > data to(a) allow, enable, or otherwise support the transmission by e-mail, > telephone, or facsimile of mass unsolicited, commercial advertising or > solicitations to entities other than the data recipient's own existing > customers; or (b) enable high volume, automate > > Regards, > Marty Strong > -- > Cloudflare - AS13335 > Network Engineer > ma...@cloudflare.com > +44 7584 906 055 > smartflare (Skype) > > https://www.peeringdb.com/asn/13335 >
Re: IPv6 dumps on Oregon route views
We don't save from the hardware router, i.e. route-views.routeviews.org.
We had done that for quite some time, I think up until 2008. But the
load on
doing full dumps from the command-line was too much, and interfered with
normal users. So at that point, we switched the ASCII dumps to
route-views2.
Easiest way to look at V6 is just use route-views6.routeviews.org. That's
a dedicated V6 box. You can libbgpdump bgpdump command to decode.
{rsync,ftp,http}://archive.routeviews.org/route-views6/bgpdata/
That's multi-hop. If you want an exchange collector for V6, then you might
want paix, sydney, linx, eqix, saopaulo, sg... instead.
John Kemp
h...@routeviews.org
On 11/24/2016 06:46 AM, Anurag Bhatia wrote:
> Hello everyone
>
>
>
> Was wondering if anyone is aware of mrt dump link for IPv6 dumps of Oregon
> route views?
>
> I see on the website it links to http://archive.routeviews.org/ipv6/ which
> gives a list of various collectors except for Oregon. The default "bgpdata"
> directory inside has dumps which are empty.
>
>
>
>
> On the Oregon route-views route-views.routeviews.org CLI:
>
>
> route-views> sh bgp ipv6 unicast summary
> BGP router identifier 128.223.51.103, local AS number 6447
> BGP table version is 46628425, main routing table version 46628425
> 36322 network entries using 9879584 bytes of memory
> 700439 path entries using 100863216 bytes of memory
> 331618/17259 BGP path/bestpath attribute entries using 82241264 bytes of
> memory
> 3607348 BGP AS-PATH entries using 175182046 bytes of memory
> 111346 BGP community entries using 11638354 bytes of memory
> 793 BGP extended community entries using 34044 bytes of memory
> 0 BGP route-map cache entries using 0 bytes of memory
> 0 BGP filter-list cache entries using 0 bytes of memory
> BGP using 379838508 total bytes of memory
> BGP activity 8323321/7623230 prefixes, 545522618/517975111 paths, scan
> interval 60 secs
>
> NeighborV AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
> State/PfxRcd
> 2001:388:1::13 4 7575 0 0100 never
> Active
> 2001:388:1::16 4 7575 573441861 4662830200 14:12:16
>34047
> 2001:418:0:1000::F016
> 4 2914 1481297618 4662830200 2d10h
> 32871
> 2001:470:0:1A::1
> 4 6939 14390766 202805 4662830200 18w2d
> 32990
> 2001:590::451F:6FF4
> 4 4436 0 0100 never
> Active
> 2001:668:0:3::0:ADCD:39EA
> 453364 1255881 57104 4662830200 5w1d
>33142
> 2001:918:0:5::1 4 3303 611233849 4662830200 2d10h
> 32994
>
>
> and much more.
>
>
>
> I am trying to look for mrt dump of this specific collector.
>
>
>
>
> Thanks.
>
route-views.chicago.routeviews.org
As mentioned at the peering personals...
route-views.chicago.routeviews.org is now up and running.
New peers are welcomed. We request full
tables if possible. We send zero back in your direction.
Peers should minimally filter default/null/rfc1918 from
their view. Our side is:
AS6447
206.223.119.187
2001:504:0:4::6447:1
telnet://route-views.chicago.routeviews.org
{http/ftp/rsync}://archive.routeviews.org/route-views.chicago
A huge thanks to our host, CTS Telecom. Those guys really
made it happen. And as always, a huge thanks to Equinix. We
could not make this all happen without the help of our hosts
and the exchanges, so thanks to all.
--
John Kemp
RouteViews Network Engineer
h...@routeviews.org
Re: Need BGP route check
Just to note, the route-views4 collector has a pretty diverse set of global multi-hop views. telnet://route-views4.routeviews.org/ http://www.routeviews.org/peers/peering-status.html http://www.routeviews.org/peers/route-views4.routeviews.org.txt John Kemp On 5/20/16 8:46 AM, Matthew Huff wrote: > Thanks, but I had checked a number of public looking glasses and only one had > the 46887 path (HE.net), wanted a more global check. A number of responses > are seeing only one or the other paths. The 14607 pre-pend is due to > depref'ing 46887 earlier today when we had the instability. > > > Matthew Huff | 1 Manhattanville Rd > Director of Operations | Purchase, NY 10577 > OTA Management LLC | Phone: 914-460-4039 > aim: matthewbhuff| Fax: 914-694-5669 > > >> -Original Message- >> From: Ken Chase [mailto:k...@sizone.org] >> Sent: Friday, May 20, 2016 11:39 AM >> To: Matthew Huff <mh...@ox.com> >> Cc: nanog@nanog.org >> Subject: Re: Need BGP route check >> >> $ telnet route-views.oregon-ix.net >> Username: rviews >> >> $ show ip bgp paths 14607 >> >> might help >> >> /kc >> >> >> On Fri, May 20, 2016 at 03:31:48PM +, Matthew Huff said: >> >One of our upstreams is apparently having problems, although they >> don't appear to know about it. I've seen an alert at BGPmon.net about >> our prefixes being withdrawn, and I can't locate our prefixes through >> that provider on any routeviews. Can someone check to see what ASPATHS >> you are seeing for our prefixes? >> > >> >129.77.0.0/16 >> >2620:0:2810::/48 >> > >> >We should be advertised via AS6128 and AS46887 >> > >> > >> >Matthew Huff | 1 Manhattanville Rd >> >Director of Operations???| Purchase, NY 10577 >> >OTA Management LLC?? | Phone: 914-460-4039 >> >aim: matthewbhuff??? | Fax:?? 914-694-5669 >> > >> > >> >> -- >> Ken Chase - k...@sizone.org Guelph Canada
Re: trout views
That's the normal Monday morning maint window for UO, when they all too frequently make us disappear... :( /jgk On 4/25/16 5:03 AM, Randy Bush wrote: > nfs0.dfw.rg.net:/root# ping 128.223.51.20 > PING 128.223.51.20 (128.223.51.20) 56(84) bytes of data. > From 4.69.145.11 icmp_seq=1 Time to live exceeded > From 4.69.145.11 icmp_seq=2 Time to live exceeded > ^C > --- 128.223.51.20 ping statistics --- > 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1001ms > > nfs0.dfw.rg.net:/root# traceroute 128.223.51.20 > traceroute to 128.223.51.20 (128.223.51.20), 30 hops max, 60 byte packets > 1 r0.dfw.rg.net (198.180.152.3) 1.571 ms 1.559 ms 1.597 ms > 2 r1.dfw.rg.net (198.180.152.2) 0.558 ms 0.551 ms 0.640 ms > 3 ge-102-0-0-29-53.r08.dllstx09.us.bb.gin.ntt.net (157.238.224.205) 1.562 > ms 1.598 ms 1.716 ms > 4 ae-12.r07.dllstx09.us.bb.gin.ntt.net (129.250.3.107) 0.488 ms 0.538 ms > 0.582 ms > 5 * * * > 6 * * * > 7 ae-65-65.csw1.Dallas1.Level3.net (4.69.206.133) 0.514 ms 0.555 ms > ae-95-95.csw4.Dallas1.Level3.net (4.69.206.145) 0.525 ms > 8 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.627 ms 0.769 ms > ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.633 ms > 9 vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 0.517 ms > vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.589 ms 0.676 ms > 10 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.519 ms > ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.632 ms > ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 13.412 ms > 11 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 13.264 ms 0.604 ms > vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.530 ms > 12 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.633 ms 0.519 ms 0.513 > ms > 13 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.540 ms > vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 13.318 ms > vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 0.554 ms > 14 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.723 ms > ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 12.793 ms > ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.494 ms > 15 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.554 ms > vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 0.541 ms > vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 2.040 ms > 16 ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 12.294 ms > ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.896 ms 0.790 ms > 17 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.590 ms > vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 0.610 ms > vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.932 ms > 18 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.522 ms > ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 11.423 ms > ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.747 ms > 19 vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 0.673 ms > vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.803 ms > vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 0.638 ms > 20 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.525 ms > ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.826 ms 0.876 ms > 21 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 0.635 ms 9.840 ms 9.404 ms > 22 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.622 ms 0.604 ms > ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 8.751 ms > 23 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.671 ms 0.817 ms 0.687 > ms > 24 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.785 ms 0.754 ms > ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 4.774 ms > 25 vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 0.633 ms 0.683 ms 0.795 > ms > 26 ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.659 ms > ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.758 ms 0.907 ms > 27 vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 0.776 ms > vlan90.csw4.Dallas1.Level3.net (4.69.145.254) 0.721 ms > vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 0.705 ms > 28 ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 15.057 ms 14.660 ms > ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.871 ms > 29 vlan80.csw3.Dallas1.Level3.net (4.69.145.190) 0.864 ms > vlan60.csw1.Dallas1.Level3.net (4.69.145.62) 0.752 ms 0.747 ms > 30 ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139) 0.877 ms > ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11) 0.721 ms > ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203) 14.302 ms > > and, of course, email does not work
Re: Is RouteViews dead? Is there any alternatives?
The problem being discussed here relates to: route-views.saopaulo.routeviews.org We do have a lot of outstanding requests for that collector. But there are some issues there that we need to discuss with the exchange. We'll work on getting that moving forward. Apologies for the lack of response. John Kemp h...@routeviews.org On 12/8/15 8:24 AM, Kurt Kraut via NANOG wrote: > Hi, > > > For the past couple of months I've been attempting to add new Autonomous > Systems to the RouteViews project and got no response. Talking to other AS > in my area, I wasn't able to find no new BGP operator that got a response > from them since July. > > Is RouteViews dead? If the answer is yes, it is sad. It is the most used > resource about the internet routing for multiple perspectives. > > Is there any other similar project that I could colaborate providing the > point of view of my routers have of the internet? > > > Best regards, > > > Kurt Kraut >
route-views.sfmix.routeviews.org is online
Just started on SFMIX. (We're also working on getting into PHLIX, FLIX, and CoreSite...) -- John Kemp RouteViews Engineer NOC: n...@routeviews.org MAIL: h...@routeviews.org WWW: http://www.routeviews.org
Re: Low BW between Mountain View and OR -- why?
You are probably testing with different sites in Oregon. La Grande is different than Portland/Salem/Corvallis, etc. I would expect traffic to eastern Oregon to be slow. /jgk On 2/16/2015 11:06 PM, Eygene Ryabinkin wrote: Tue, Feb 17, 2015 at 11:47:04AM +0530, Glen Kent wrote: I have a server in Mountain View and i am doing a speedtest with a server in Oregon. I see that the upload/download BW that i am getting is low -- around 10.0Mbps and 5.0Mbps. gkent@ubuntu:~/ics$ speedtest-cli --server 4082 Retrieving speedtest.net configuration... Retrieving speedtest.net server list... Testing from Comcast Cable (50.250.251.210)... Hosted by Eastern Oregon Net, Inc. (La Grande, OR) [913.33 km]: 120.959 ms Testing download speed Download: 5.08 Mbits/s Testing upload speed.. Upload: 10.89 Mbits/s When i check my connectivity with a server in NYC, its much better, though the server is much further away. gkent@ubuntu:~/ics$ speedtest-cli --server 2947 Retrieving speedtest.net configuration... Retrieving speedtest.net server list... Testing from Comcast Cable (50.250.251.210)... Hosted by Atlantic Metro (New York City, NY) [4129.02 km]: 307.568 ms Testing download speed Download: 38.52 Mbits/s Testing upload speed.. Upload: 10.62 Mbits/s I am trying to understand why this is so? I would wager that NYC being further away would give me a worse throughput than OR, but the speedtest tells me otherwise. Packet loss or just congestion on the path (resulting in packet loss again) that makes your TCP windows to shrink and not letting you to get close to either your allocated BW on the channel to OR or your maximal throughput per TCP stream that is governed by the maximal size of the TCP buffer? There could be some shaping as well, but this might be not your case, since it fluctuates. However, many interesting things could happen. iperf in UDP mode should give you fairly good overview of what't happening with bandwidth and packet loss. And iperf in TCP mode with varying number of streams (and obtained scaling of throughput or lack of it) should give you some hints on what's possibly going on. I also assume that you're talking about TCP and your bandwidth-delay product is used to tune TCP buffer sizes. If not, I'd recommend checking http://www.psc.edu/index.php/networking/641-tcp-tune The 2nd and more puzzling observation is that while OR is giving a download of around 5.08Mbps, it will improve and become much better later in the day. There are times when i see it going up as high as 48Mbps. Sometimes while a transfer is in progress i see that my download suddenly goes down from 48Mbps to 2Mbps. Varying routing during the day, fluctuating congestion and many other things could happen. Probably here something like smokeping will give you an overview of the RTT (if it varies) and loss on the ICMP. ICMP loss isn't neccessarily coupled to UDP/TCP due to the QoS and other stuff that can happen on WAN, so it will provide just additional hints, not the complete answer. Can somebody here tell me why such a drastic fluctuation is seen? No answers here, sorry, just some hints and possibilities.
Re: real-time traffic engineering/management solutions
I believe ThousandEyes would be another example. /jgk On 6/4/14 10:39 AM, Paul S. wrote: Two 'established' options are, 0. Noction IRP (As mentioned) 1. Internap FCP Everyone appears to either be using one of these, or have gone full custom. On 6/4/2014 午後 10:52, Tassos Chatzithomaoglou wrote: I'm having a look at real-time traffic engineering/management solutions that include visibility/analysis/control and offer the following basic characteristics: 1) take into account * links utilization/threshold/deviation * link price * packet delay/loss * physical/logical topology 2) and offer real-time automatic ingress/egress traffic adjustment using * netconf bgp to change localpref/med/aspath/community attributes (mandatory) * SDN/Openflow/I2RS/PCEP technologies (optional) 3) considering only IP traffic (MPLS can be optional), especially on external links used for peering and transit by tier-1/2 providers. Do you have any personal experience regarding the above features? From my personal search Cisco offers Quantum/WAE (inc MATE) which seem very limited in real-time functionality and Huawei offers RR+ which seems interesting but unknown to many people (and maybe not compatible with all vendor routers). Any other idea or commercial option? Offline answers would be good too. -- Tassos
new RouteViews collector at NWAX: route-views.nwax.routeviews.org
Just brought online Details at: http://www.routeviews.org/nwax.html We would welcome a few more NWAX peers at this point. Thanks to NWAX and IOVATION, -- John Kemp RouteViews Engineer NOC: n...@routeviews.org MAIL: h...@routeviews.org WWW: http://www.routeviews.org
cert's routeviews mirror
Someone asked me for the link... http://routeviews-mirror.cert.org/ John Kemp h...@routeviews.org
routeviews+BGPmon resources
The NANOG60 Talk:
https://www.nanog.org/sites/default/files/monday.general.olschanowsky.routeviews.33.pdf
BGPmon Homepage
http://bgpmon.netsec.colostate.edu/
BGPmon Mailing List
http://www.netsec.colostate.edu/mailman/listinfo/bgpmon
BGPmon v7.3.3 Download
http://bgpmon.netsec.colostate.edu/index.php/download
BGPmon CPAN Modules e.g.
http://www.cpan.org/authors/id/B/BG/BGPMON/
BGPmon-core
BGPmon-Archiver
BGPmon-AnalyticsDB
BGPmon-CPM
RouteViews BGPmon Dedicated Instances
(rv2) livebgp-route-views2.routeviews.org
(rv3) livebgp-route-views3.routeviews.org
(rv6) livebgp-route-views6.routeviews.org
(paix) livebgp-paix.routeviews.org
(linx) livebgp-linx.routeviews.org
RouteViews BGPmon Consolidating Instances
(rv2+3+6) livebgp.routeviews.org
(paix+linx) livebgpix.routeviews.org
RouteViews MRT Archives
{http,ftp}://archive.routeviews.org/
rsync –list-only archive.routeviews.org::routeviews
rsync –av archive.routeviews.org::routeviews/bgpdata .
If you plan on utilizing one of the BGPmon live feeds for
an extended period, we would appreciate an e-mail. Please
let us know your intended usage and the subnet you will
be coming in from. For the RouteViews Instances, mail to
h...@routeviews.org. For general BGPmon questions,
bgp...@netsec.colostate.edu.
The RouteViews Instances are considered a test platform.
So while we do monitor, we are still debugging and doing
updates. Feel free to ask if you have questions or comments.
John Kemp
RouteViews Network Engineer
h...@routeviews.org
Re: Network topology [Solved]
I know Carlos did a bunch of work to build this into Netdot, i.e. discover L2, draw usable graphs. Here's a link to the last NANOG presentation: http://www.nanog.org/meetings/nanog49/presentations/Tuesday/Vicente-netdot-presentation-nanog49.pdf John Kemp On 10/15/08 7:18 PM, Dale W. Carder wrote: On Oct 15, 2008, at 1:35 PM, Colin Alston wrote: On 2008/10/15 06:29 PM Colin Alston wrote: Is there any kind of cunning trick to detect standard layer2 switches along a path without stuff like STP? Apparently there isn't. Lots of people mentioned other tools, the problem there is they have one thing in common which is polling SNMP. I think it scales badly in general. What is your reasoning behind this claim? I would claim quite the opposite compared to CLI or TL1. Maybe there should be something (I mean like, someone should come up with a standard :P) to trace switches in a path I've written a cruddy script that given a seed bridge, scrapes L2 information obtained via CDP (I guess it could do LLDP, too) and does a breadth-first search through a network. Then I just dump that into gnuplot format. Getting the data is easy compared to visualization. A coworker of mine has written script to ask Rapid-STP speaking switches about their current topology and builds a graph again in gnuplot format. A more challenging approach would be to scrape the mac forwarding tables and stitch things together. This would have to be done per-vlan. I think this approach (or similar) might be done by Openview's L2 featureset. Dale -- Dale W. Carder - Network Engineer University of Wisconsin / WiscNet http://net.doit.wisc.edu/~dwcarder
Re: Network topology [Solved]
Ah, sorry. Resurrected an old one there... ;-/ /jgk On 11/15/13 2:41 PM, John Kemp wrote: I know Carlos did a bunch of work to build this into Netdot, i.e. discover L2, draw usable graphs. Here's a link to the last NANOG presentation: http://www.nanog.org/meetings/nanog49/presentations/Tuesday/Vicente-netdot-presentation-nanog49.pdf John Kemp On 10/15/08 7:18 PM, Dale W. Carder wrote: On Oct 15, 2008, at 1:35 PM, Colin Alston wrote: On 2008/10/15 06:29 PM Colin Alston wrote: Is there any kind of cunning trick to detect standard layer2 switches along a path without stuff like STP? Apparently there isn't. Lots of people mentioned other tools, the problem there is they have one thing in common which is polling SNMP. I think it scales badly in general. What is your reasoning behind this claim? I would claim quite the opposite compared to CLI or TL1. Maybe there should be something (I mean like, someone should come up with a standard :P) to trace switches in a path I've written a cruddy script that given a seed bridge, scrapes L2 information obtained via CDP (I guess it could do LLDP, too) and does a breadth-first search through a network. Then I just dump that into gnuplot format. Getting the data is easy compared to visualization. A coworker of mine has written script to ask Rapid-STP speaking switches about their current topology and builds a graph again in gnuplot format. A more challenging approach would be to scrape the mac forwarding tables and stitch things together. This would have to be done per-vlan. I think this approach (or similar) might be done by Openview's L2 featureset. Dale -- Dale W. Carder - Network Engineer University of Wisconsin / WiscNet http://net.doit.wisc.edu/~dwcarder
new collector: route-views.soxrs.routeviews.org
Not much there yet, but we are operational and would love to get a few more peers. Serbian Open eXchange http://www.routeviews.org/soxrs.html Thanks, -- John Kemp (k...@routeviews.org) RouteViews Engineer NOC: n...@routeviews.org MAIL: h...@routeviews.org WWW: http://www.routeviews.org
route-views3 resource update
Subject: route-views3 resource update
* route-views3.routeviews.org *
route-views3 was, until yesterday, a Cisco 7206VXR (NPE-G2) 1GB.
route-views3 is now a Redhat 6 box running Quagga 0.99.22.3.
This change was made due to memory exhaustion on the older hardware.
Quagga provides a similar but less powerful CLI.
The new platform has allowed us to resume data collection on
route-views3. The data format is the same as
most of our other collectors. route-views3 is a multi-hop
ebgp collector located at the University of Oregon.
The resources available are:
CLI -- telnet://route-views3.routeviews.org
PEERS -- http://www.routeviews.org/peers/route-views3.routeviews.org.txt
DATA -- {http,ftp,rsync}://archive.routeviews.org/route-views3/bgpdata/
ex. rsync --list-only archive.routeviews.org::routeviews
ex. rsync -av archive.routeviews.org::routeviews/route-views3/bgpdata .
ex. rsync -av archive2.routeviews.org::routeviews/route-views3/bgpdata .
Please be aware that the older route-views3 data still resides at
the higher level within that data directory. New data is being
stored in the bgpdata directory. The older data was captured using
the Cisco hardware and expect session scripts.
Questions and comments are welcome. We do intend to retain
the Cisco CLI on the original route-views router for the
forseeable future.
---
John Kemp (k...@routeviews.org)
RouteViews Network Engineer
h...@routeviews.org
Re: route for linx.net in Level3?
Yeah, you wouldn't think that one should fall out. It is possible that my 195.66.241.146 really should be something sitting within: 195.66.232.0/22. I'll have to talk with some of the LINX folks to understand whether they are intending that 195.66.240.0/22 and 195.66.232.0/22 are treated differently. If that's the case, I may need to move off of 195.66.240.0/22. Thanks, John Kemp (k...@routeviews.org) On 4/3/13 4:20 PM, Yang Yu wrote: I noticed it too this morning from a AS3549 customer. Level 3 LG shows no route for 195.66.232.0/22 on North American sites. On Wed, Apr 3, 2013 at 6:52 PM, John Kemp k...@network-services.uoregon.edu wrote: Having trouble reaching route-views.linx.routeviews.org from AS3582. I'm assuming that some folks stopped carrying this particular linx.net address prefix as of this morning. ?!? $ whois -h whois.cymru.com -v 195.66.241.146 AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name 5459| 195.66.241.146 | 195.66.240.0/22 | GB | ripencc | 1997-12-01 | LINX-AS London Internet Exchange Ltd. $ dig +short 146.241.66.195.peer.asn.cymru.com TXT 1299 2914 3257 10310 | 195.66.240.0/22 | GB | ripencc | 1997-12-01 -- John Kemp (k...@routeviews.org) RouteViews Engineer NOC: n...@routeviews.org MAIL: h...@routeviews.org WWW: http://www.routeviews.org
route for linx.net in Level3?
Having trouble reaching route-views.linx.routeviews.org from AS3582. I'm assuming that some folks stopped carrying this particular linx.net address prefix as of this morning. ?!? $ whois -h whois.cymru.com -v 195.66.241.146 AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name 5459| 195.66.241.146 | 195.66.240.0/22 | GB | ripencc | 1997-12-01 | LINX-AS London Internet Exchange Ltd. $ dig +short 146.241.66.195.peer.asn.cymru.com TXT 1299 2914 3257 10310 | 195.66.240.0/22 | GB | ripencc | 1997-12-01 -- John Kemp (k...@routeviews.org) RouteViews Engineer NOC: n...@routeviews.org MAIL: h...@routeviews.org WWW: http://www.routeviews.org
Re: BGP RIB Collection
I'll chime in with what we are doing with quagga and bgpmon. The question though would be for how many peers? If it is for the sake of discussion, less than 20, something like this might work. http://bgpmon.netsec.colostate.edu/download/src/bgpmon-7.2.4.tar.gz http://rmcwic.ucar.edu/sites/default/files/posters/csuconf-final19.pdf We do some of this. The pure BGPmon way is to have neighbors peer directly with a BGPmon server. We've extended this a bit and we can stream quagga MRT update files into a bgpmon server as well. Then the BGPmon server internally constructs RIBs per session. Output format is XML, and the paper linked above describes some of the perl tools there are to look at xml streams. So you can get a RIB stream or an UPDATE stream from the BGPmon server. At some scale, this might give you what you need. I think the BMP solution looks pretty nice as well, since you are as close to your true platform as you can get. So I would also be interested in hearing if you find existing client code to parse the BMP. John Kemp (k...@routeviews.org) project is still in its infancy. BMP seems to be a good solution but I've not found a working client implementation yet. I see that you can actually configure this on some Juniper gear but I can't seem to locate a client to ingest the data the router produces. Can you provide a list of the clients that you have tried? It would save people the effort of going through them and finding out the same things as you did. Nick
Re: bird rib dump
Uh,
I'm looking at this in the source below in sysdep/unix/log.c
and it looks like it is there. I assume you want mrtdump protocols
messages
The manual for Global options it says this:
mrtdump filename
Set MRTdump file name. This option must be specified to allow MRTdump
feature. Default: no dump file.
mrtdump protocols all|off|{ states, messages }
Set global defaults of MRTdump options. See mrtdump in the following
section. Default: off.
/jgk
359 void
360 mrt_dump_message(struct proto *p, u16 type, u16 subtype, byte
*buf, u32 len)
361 {
362 /* Prepare header */
363 put_u32(buf+0, now_real);
364 put_u16(buf+4, type);
365 put_u16(buf+6, subtype);
366 put_u32(buf+8, len - MRTDUMP_HDR_LENGTH);
367
368 if (p-cf-global-mrtdump_file != -1)
369 write(p-cf-global-mrtdump_file, buf, len);
370 }
On 2/21/13 5:18 PM, Eiichiro Watanabe wrote:
bird supposedly doesn't support rib dumps at this time.
Randy Bush wrote (2013/02/22 7:11):
a friend trying to see if bird will be better than quagga for bgp
recording can not see how to get rib dumps, as opposed to just updates.
what are we missing?
randy
Re: bird rib dump
Ah, you said rib. Did look at the code a bit more.
It looks like there is a dump routes command. Might
try that.
Here it says birdc can do some stuff...
http://bird.network.cz/?get_docf=bird-4.html
dump resources|sockets|interfaces|neighbors|attributes|routes|protocols
and
show route [[for] prefix|IP] [table sym] [filter f|where c]
[(export|preexport) p] [protocol p] [options]
/jgk
On 2/22/13 12:56 AM, John Kemp wrote:
Uh,
I'm looking at this in the source below in sysdep/unix/log.c
and it looks like it is there. I assume you want mrtdump protocols
messages
The manual for Global options it says this:
mrtdump filename
Set MRTdump file name. This option must be specified to allow MRTdump
feature. Default: no dump file.
mrtdump protocols all|off|{ states, messages }
Set global defaults of MRTdump options. See mrtdump in the following
section. Default: off.
/jgk
359 void
360 mrt_dump_message(struct proto *p, u16 type, u16 subtype, byte
*buf, u32 len)
361 {
362 /* Prepare header */
363 put_u32(buf+0, now_real);
364 put_u16(buf+4, type);
365 put_u16(buf+6, subtype);
366 put_u32(buf+8, len - MRTDUMP_HDR_LENGTH);
367
368 if (p-cf-global-mrtdump_file != -1)
369 write(p-cf-global-mrtdump_file, buf, len);
370 }
On 2/21/13 5:18 PM, Eiichiro Watanabe wrote:
bird supposedly doesn't support rib dumps at this time.
Randy Bush wrote (2013/02/22 7:11):
a friend trying to see if bird will be better than quagga for bgp
recording can not see how to get rib dumps, as opposed to just updates.
what are we missing?
randy
Re: IPV6 in enterprise best practices/white papaers
Not sure if anyone mentioned Aaron's presentation on this topic from way back... Here's the link: http://www.nanog.org/meetings/nanog47/presentations/Wednesday/Hughes_Kosters_fundamentals_N47_Wed.pdf John Kemp (k...@routeviews.org) On 1/26/13 1:26 AM, Pavel Dimow wrote: Hi, I have read many of those ipv6 documents and they are great but I still luck to find something like real word scenario. What I mean is that for example I want to start implementation of ipv6 in my enterprise according to mu knowledge so far my first step is to create address plan, then implement security on routers/switches then on hosts, and after that I can start to create record and PTR recors in DNS and after that I should configure my dhcp servers and after all has been done I can test ipv6 in LAN and after that I can start configure bgp with ISP. Is this correct procedure? Any thoughts? If all is correct I have a few questions.. Regarding DNS, if I give a /64 to host using SLAAC or DHCP how do I maintain PTR for this /64? I should use DDNS? What do you use in your enterprise SLAAC or DHCP? If SLAAC why not DHCP? Any other hints/tips?
Re: looking glass for Level 3
Session is up on telnet:route-views.routeviews.org username rviews John Kemp (k...@routeviews.org) On 12/28/2012 2:23 AM, Peter Ehiwe wrote: I normally use the 3rd one you mentioned but they seem to be down at the moment. Rgds Peter, Sent from my Asus Transformer Pad On Dec 28, 2012 1:51 AM, Tassos Chatzithomaoglou ach...@forthnetgroup.gr wrote: Anyone have any looking glass for Level 3? The following seem not to be working http://www.level3.com/LookingGlass/ http://lg.level3.net/bgp/bgp.cgi http://lookingglass.level3.net/ -- Tassos
Re: 32-bit ASes at routeviews
On 12/16/12 2:48 PM, Iljitsch van Beijnum wrote: Looking for 32-bit AS numbers, I get some strange results from routeviews: route-viewssh ip bgp regexp _23456_ BGP table version is 2393809200, local router ID is 128.223.51.103 Status codes: s suppressed, d damped, h history, * valid, best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next HopMetric LocPrf Weight Path * 31.177.16.0/22 128.223.253.10 0 3582 3701 3356 23456 3.1043 i * 46.29.72.0/21129.250.0.11 285 0 2914 12389 12389 12389 12389 23456 3.627 i * 46.243.96.0/21 154.11.11.1130 0 852 174 39704 39704 23456 3.787 i * 91.208.62.0/24 154.11.11.1130 0 852 174 39704 39704 23456 3.787 i * 91.217.87.0/24 194.85.40.15 0 3267 174 23456 3.661 i * 91.230.169.0/24 208.51.134.254 13905 0 3549 29152 29152 29152 29152 23456 23456 23456 23456 3.1426 i * 91.238.8.0/24194.85.40.15 0 3267 8220 23456 3.2040 i * 111.235.148.0/22 194.85.40.15 0 3267 9498 9730 23456 i * 141.0.176.0/21 129.250.0.11 285 0 2914 12389 12389 12389 12389 23456 3.627 i Unless I missed something, AS 23456 is supposed to show up as a stand-in for 32-bit ASNs on 16-bit BGP implementations, not in _addition_ to 32-bit ASNs. So the penultimate line would make sense if the other lines weren't there and the others don't make sense period. Maybe a bug in the IOS they're running? route-viewssh ver Cisco IOS Software, 7200 Software (C7200P-ADVENTERPRISEK9-M), Version 12.4(24)T2, RELEASE SOFTWARE (fc2) Or is something else going on? Off topic, this reminds me I would rather have ASPLAIN again. We switched a couple of years ago on a particular user request. If there is no objection, I would love to switch back ASAP. This would be on route-views, and on route-views3. Just asking if others concur? -- John Kemp (k...@routeviews.org) RouteViews Engineer NOC: n...@routeviews.org MAIL: h...@routeviews.org WWW: http://www.routeviews.org
route-views.eqix DC METRO AREA IX RENUMBERING
We have the renumber interface enabled and configured for any known peers to make the transition for the RouteViews EQUINIX ASHBURN route collector. OLD PEERING ADDRESS: 206.223.115.142 NEW PEERING ADDRESS: 206.126.236.142 Current v4 peer list looks like below. If you need to check, telnet to route-views.eqix.routeviews.org Thanks, John Kemp (k...@routeviews.org) NeighborVAS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 206.126.236.10 4 4589 0 0000 never Active 206.126.236.12 4 2914 0 0000 never Active 206.126.236.19 4 3257 0 0000 never Active 206.126.236.24 4 11666 0 0000 never Active 206.126.236.25 4 6079 0 0000 never Active 206.126.236.26 4 16559 0 0000 never Active 206.126.236.37 4 6939 0 0000 never Active 206.126.236.47 4 19151 0 0000 never Active 206.126.236.52 4 4565 0 0000 never Active 206.126.236.58 4 32098 0 0000 never Active 206.126.236.60 4 4436 0 0000 never Active 206.126.236.61 4 4436 0 0000 never Active 206.126.236.76 4 5769 0 0000 never Active 206.126.236.81 4 6453 0 0000 never Active 206.126.236.109 4 19166 0 0000 never Active 206.126.236.120 4 41095 0 0000 never Active 206.126.236.156 4 7795 0 0000 never Active 206.126.236.181 4 8781 0 0000 never Active 206.223.115.10 4 4589 1680861454000 1d00h12m 428226 206.223.115.12 4 2914 3355701454000 1d00h12m 422014 206.223.115.19 4 3257 3064792886000 1d00h12m 421751 206.223.115.24 4 11666 3500482886000 1d00h12m 427034 206.223.115.25 4 6079 1275391454000 1d00h12m 421048 206.223.115.26 4 16559 1508341454000 1d00h12m 422475 206.223.115.37 4 6939 2805141454000 1d00h12m 426934 206.223.115.47 4 19151 1791331454000 1d00h12m 424028 206.223.115.52 4 456530612886000 1d00h12m 2058 206.223.115.58 4 3209858551454000 1d00h12m 957 206.223.115.60 4 4436 2358662886000 1d00h12m 422375 206.223.115.61 4 4436 2372592886000 1d00h12m 422375 206.223.115.76 4 5769 2053241454000 1d00h12m 422482 206.223.115.81 4 6453 0 0000 never Active 206.223.115.109 4 19166 0 0000 never Active 206.223.115.120 4 41095 1666041454000 1d00h12m 422118 206.223.115.156 4 779531761454000 1d00h12m 191 206.223.115.181 4 878161571454000 1d00h12m 764 -- John Kemp (k...@routeviews.org) RouteViews Engineer NOC: n...@routeviews.org MAIL: h...@routeviews.org WWW: http://www.routeviews.org
Re: IMPLEMENTING A SOFTWARE BASED ROUTE SERVER
On 09/20/2012 12:34 AM, John Kemp wrote: On 9/19/12 5:29 AM, Phil Regnauld wrote: Joseph M. Owino (jpmuga) writes: Hi, Hope you are all well. I work at an exchange point and was seeking any assistance on how to implement a software based route server as currently we are using a Cisco Router for that purpose. Any form of assistance will be highly appreciated. Hello Joseph, You could do this in a number of ways, running Quagga or BIRD (or even BGPD) on a Linux or BSD server. Quagga documentation even has a chapter on this: http://www.nongnu.org/quagga/docs/quagga.html#SEC115 I'm sure several people on this list have experience with this and will contribute. Also, it might be send this inquiry to the AfNOG list as well (afnog.org). Finally (plug) we have some resources that may be of interest to you here: https://nsrc.org/route-bgp-ixp.html Cheers, Phil Thought I would add some more links (Bird related...). Seems like the genesis has been from a single-rib on the RS to RIBs-per-client. And more recently to using the IRRs for additional filtering options. AMS-IX for example: https://www.ams-ix.net/technical/specifications-descriptions/ams-ix-route-servers Here's that BIRD stuff... http://www.peering-forum.eu/epf3/presentations/day1/inex-epf-dublin-2008-09-15-01.pdf https://git.nic.cz/redmine/projects/bird/wiki/Route_server_with_community_based_filtering http://www.mail-archive.com/bird-users@atrey.karlin.mff.cuni.cz/msg00505.html ) A few more comments on this ... At the recent RIPE meeting Ondrej Filip has a new feature called secondary that may be a work-around to get away from RIB-per-client. Presentation is here: https://ripe65.ripe.net/presentations/191-BIRD-20120926-OF-RIPE-EIX.pdf There was also a decent talk about a proposed draft for best current practices for BGP security at the IXP. Worth a read. https://ripe65.ripe.net/presentations/256-draft-jdurand-bgp-security-02-RIPE65-02.pdf John Kemp (k...@routeviews.org)
Re: IMPLEMENTING A SOFTWARE BASED ROUTE SERVER
On 9/19/12 5:29 AM, Phil Regnauld wrote: Joseph M. Owino (jpmuga) writes: Hi, Hope you are all well. I work at an exchange point and was seeking any assistance on how to implement a software based route server as currently we are using a Cisco Router for that purpose. Any form of assistance will be highly appreciated. Hello Joseph, You could do this in a number of ways, running Quagga or BIRD (or even BGPD) on a Linux or BSD server. Quagga documentation even has a chapter on this: http://www.nongnu.org/quagga/docs/quagga.html#SEC115 I'm sure several people on this list have experience with this and will contribute. Also, it might be send this inquiry to the AfNOG list as well (afnog.org). Finally (plug) we have some resources that may be of interest to you here: https://nsrc.org/route-bgp-ixp.html Cheers, Phil Thought I would add some more links (Bird related...). Seems like the genesis has been from a single-rib on the RS to RIBs-per-client. And more recently to using the IRRs for additional filtering options. AMS-IX for example: https://www.ams-ix.net/technical/specifications-descriptions/ams-ix-route-servers Here's that BIRD stuff... http://www.peering-forum.eu/epf3/presentations/day1/inex-epf-dublin-2008-09-15-01.pdf https://git.nic.cz/redmine/projects/bird/wiki/Route_server_with_community_based_filtering http://www.mail-archive.com/bird-users@atrey.karlin.mff.cuni.cz/msg00505.html John Kemp (k...@routeviews.org)
Re: BGP Play broken?
OK. I think we have something going at http://bgplay.routeviews.org/ again. Thought I would change things up a bit since we were having problems with some of the route-views2 collector data. So the setup now defaults to the data from the collectors: route-views.paix.routeviews.org, route-views.eqix.routeviews.org, route-views.saopaulo.routeviews.org, and route-views.sydney.routeviews.org. There is 30-days of data up at the moment. We'll try to make that extend out further if we can. It updates at 15 minute intervals. Again thanks to Roma Tre for allowing us to continue to run this service. I would also add that I'm happy to see the historical BGPLAY at RIPE offered as a service. Nice work there. We will continue make a solid effort to support our instance of bgplay. -- John Kemp (k...@routeviews.org) RouteViews Engineer NOC: n...@routeviews.org MAIL: h...@routeviews.org WWW: http://www.routeviews.org On 8/15/12 3:11 PM, Anurag Bhatia wrote: Hi Frank On Wed, Aug 15, 2012 at 5:03 PM, Frank Bulk frnk...@iname.com wrote: Here's another option: http://sga.ripe.net/hbgplay/ This one looks good though I linked visible ASNs in BGPlay then blicking ones here (even Show/Hide AS button somehow fails for me). Thanks anyways. Will look forward for such other interesting analysis tools. -Original Message- From: joel jaeggli [mailto:joe...@bogus.com] Sent: Wednesday, August 15, 2012 12:52 PM To: Robert Glover Cc: NANOG Mailing List Subject: Re: BGP Play broken? On 8/15/12 10:28 AM, Robert Glover wrote: On 08/15/2012 10:16 AM, Anurag Bhatia wrote: Seems like BGP Play - http://bgplay.routeviews.org/ does not works anymore? It is not accepting prefixes and gives error to check if prefix is announced globally or not. I sent an email to the contacts listed on the BGPlay feedback page back on July 20 letting them know it was broken. I never received a response, so it has likely been broken since then. bgpplay has in my understanding had several issues... the one on july was addressed by migrating it to a higher capacity server. the more recent incident started a couple of days ago and I belive people are working on it. -Robert
Re: HELP IN SETTING UP iBGPlay
On 7/10/2012 5:04 AM, Joseph M. Owino wrote: hi, Anyone out there who can help in setting up iBGP looking glass for an IXP. We currently are running 2 route servers and and 2 switches, they all are Cisco equipment. We also have a working web server running on FreeBSD 8.0. Any help is highly appreciated. regards, Muga Happy to help you if you get stuck.The work flow looks very similar to what is in BGPlay, so once you have the MRT file that contains desired data, you are most of the way there. I suspect the issue you will hit is that you already have existing route servers, and when you specify the route servers as the source route-reflector-clients, then you will see the route servers as the routers in your views rather than your peer routers. If on the other hand you have control over your peer routers, and you can reflect directly to the iBGPlay routerserver, that appears to be the model they show in their setup documents. John Kemp (k...@routeviews.org)
Re: Why not to use RPKI (Was Re: Argus: a hijacking alarm system)
On 1/23/2012 7:28 AM, Christopher Morrow wrote: On Mon, Jan 23, 2012 at 10:19 AM, Yang Xiang xiang...@csnet1.cs.tsinghua.edu.cn wrote: Hi chris, 2012/1/23 Christopher Morrow morrowc.li...@gmail.com On Fri, Jan 20, 2012 at 8:08 AM, Yang Xiang xiang...@csnet1.cs.tsinghua.edu.cn wrote: 2012/1/20 Arturo Servin aser...@lacnic.net while Argus can discover potential hijackings caused by anomalous AS path. reading the preceding section (III.B) you check 3 things in the AMM (anomaly monitoring module) 1) proper origin (based on what?) 2) anomalous neighbour (based on what?) 3) policy anomaly (where did you determine the policy?) later text seems to imply you track some history (1 months worth) and use that as a baseline, for at least the neighbour and origin data. The policy data isn't clearly outlined though, where did that come from? (there's a note about use of whois, which could cover some of this, but certainly not all) yes, we use history as a baseline for both the origin, neighbor and policy data. origin data: a history of prefix, origin_AS mappings, neighbor data: a history of every adjacent two ASes in all AS paths received from BGPmon, policy data: a history of every adjacent three ASes (AS triple) in all AS paths. origin and neighbor data is intuitive. for policy data, we do not gather the exact routing policies, since they are usually private. In Argus, we use all adjacent three ASes in all AS paths as the policy data. this is because: 1), AS triples reflect the import/export routing policies; 2), while monitoring BGP updates, we only need to discover 'possible’ hijackings, but not 'exact' hijackings. after figure out a possible hijacking, the hijacking identification process will be launched and make the final judgement. ok, that seems squirrelly still :( The data plane testing you propose is from the public route-servers (eyes), which don't import the path you want, well routeviews I think doesn't import routes to it's FIB (or maybe I'm mistaken...) but point being with more than one peer on the routeserver it's not clear you would be taking the path you actually want to test anyway, is it? yes, each route-server usually has several route to the target prefix. In Argus, we use the commands (i.e., show route exact active-path”) to get the 'best routes' of the prefix, and consider it as the route in FIB: so, take routeviews for example, they peer almost exclusively ebgp-multi-hop, so any 'best path' you see there isn't actually usable by the route-server... all traffic has to take the local transport out of the routeviews system, off to the internet and beyond. So, your blackhole testing isn't actually testing what you want, I think :( -chris Minor correction there. If you are talking about our IX collectors (LINX, PAIX, EQIX Ashburn, SYDNEY, etc.) those are at exchanges and peering directly. The collectors at Univ of Oregon (rv,rv2,rv3,rv4, rv6), yeah, those are multi-hop. Doesn't detract from your point, but I think it helps if people are aware of whether they are on the exchange or on a multihop when using routeviews collectors. Only other thing to add, I don't think anyone mentioned Cyclops in this thread. Just as another data point, see also: http://cyclops.6watch.net or http://cyclops.cs.ucla.edu John Kemp (k...@routeviews.org)
Re: routeviews.org domain registration
On 12/20/11 4:09 AM, Andy Davidson wrote: On 20 Dec 2011, at 12:02, Stephen Strowes wrote: I pinged John Kemp at uoregon.edu, but unsure if he is the correct contact for this. I beeped Dave Meyer, who acknowledged, so I think someone is on it. Andy Dave jumped on it and got it taken care of. Thanks to all the kind folks who notified us of the issue. -- John Kemp (k...@network-services.uoregon.edu) RouteViews Engineer
livebgp.routeviews.org
We enabled an additional client BGPMON node. The sources are local collectors and the collectors peering at the Colorado State BGPMON site. Output is XML formatted UPDATE and RIB messages. ex. telnet livebgp.routeviews.org 50001 ex. telnet lievbgp.routeviews.org 50002 See also: http://bgpmon.netsec.colostate.edu/index.php/documentation --- John Kemp (k...@routeviews.org) RouteViews Engineer NOC: h...@routeviews.org http://www.routeviews.org
bgplay.routeviews.org online again (finally)
See: http://bgplay.routeviews.org/ It's up again, and actively updating. We ran into a space crunch on the previous machine. We now have the DB living on one of our stable RAID6 arrays. Currently the data is from January 26, 2011 to present. (it's finishing the data for 08/03/2011 right now...) The data source is the route-views2 collector. Data downloads of routing updates happen at :10 after each hour. --- John Kemp (k...@routeviews.org) RouteViews Engineer NOC: h...@routeviews.org http://www.routeviews.org
Re: website in ipv6
On 6/26/11 5:34 PM, Mark Andrews wrote: In message 20110627002625.4c8531137...@drugs.dv.isc.org, Mark Andrews writes : In message banlktikzmcshaxffwq2pidfpkxctqtr...@mail.gmail.com, Deric Kwok wr ites: Hi all I am trying to configure website for testing ipv6 Just wander how internet users eg: DSL users can visit this website and any people can access this website over the world Thank you About 10-6% of the net is dual stack capable, there is a working IPv6 path from the brower to the server. About 0.4% of the net prefers IPv6 over IPv4. It was higher but changes to depreference using 2002::/16 (6to4) as a source address have been pushed in various OS updates. http://www.potaroo.net/stats/1x1/sitec/v6hosts.png I meant to post the aggregate graph. http://www.potaroo.net/stats/1x1/v6hosts.png This is updated daily. APNIC/Geoff could use more test data sources. http://labs.apnic.net/index.shtml Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org The more optimistic number was that something like 20% - 30% of clients could retrieve an IPV6-Only Literal URL. So yeah, still sad, but there is some potential there. --- John Kemp (k...@routeviews.org) RouteViews Engineer NOC: h...@routeviews.org http://www.routeviews.org
route-views.saopaulo.routeviews.org is up and running
We announced on the PTTMetro list yesterday. http://www.routeviews.org/saopaulo.html If there is anyone else on PTTMetro who can share full tables, we would love to work with you on that. [ Also reminders: route-views.sydney.routeviews.org is running at EQIX SYD1. And we have the V6 interface available now at PAIX. Interface specifics at: http://www.peeringdb.com/view.php?asn=6447 ] Thanks, --- John Kemp (k...@routeviews.org) RouteViews Engineer NOC: h...@routeviews.org http://www.routeviews.org
[outage] archive.routeviews.org under maintenance
We are experiencing some unanticipated hardware issues with the machine archive.routeviews.org. This machine serves as the front-end to our primary data archive. It also hosts http://www.routeviews.org/ and is answering for route-views6.routeviews.org. We are currently working to deploy a replacement for this piece of hardware. NOTE: this outage will not affect the other routeviews collectors, or the data archive. Your patience during this time is appreciated. -- John Kemp RouteViews Engineer k...@network-services.uoregon.edu 541-346-1714
