Re: External BGP Controller for L3 Switch BGP routing

[Vincent Bernat]

 ❦ 14 janvier 2017 05:24 GMT, Faisal Imtiaz  :

> A while back there was a discussion on how to do optimized (dynamic)
> BGP routing on a L3 switch which is only capable of handing a subset
> of BGP Routing table.
>
> Someone has pointed out that there was a project to do just that, and
> had posted a link to a presentation on a European operator (Ireland ?
> ) who had done some code to take Exabgp and create such a setup..

Maybe: https://github.com/dbarrosop/sir
-- 
The difference between the right word and the almost right word is the
difference between lightning and the lightning bug.
-- Mark Twain

Re: Apple Caching Server question

[Luke Guillory]

They sell transparent caching, works great and we've been using it for a few 
years. Not cheap on the CAPX side but it sure does work.

I deliver 50% of all Netflix traffic while never hitting my transit links, 
Apple is even higher and windows updates is are near the 97% number. The great 
thing outside of cutting down on transit traffic is the increase speeds from 
serving it from within my network.

The support folks rock and take care of everything, we haven't touched it since 
we racked it up. Simple 1u Dell server with 10g nics, we currently just port 
mirror to it and let it do its thing.

I can share more if needed as well.

Luke


Sent from my iPad

>

Luke Guillory
Network Operations Manager

Tel:985.536.1212
Fax:985.536.0300
Email:  lguill...@reservetele.com

Reserve Telecommunications
100 RTC Dr
Reserve, LA 70084

_

Disclaimer:
The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material which should not disseminate, distribute or be 
copied. Please notify Luke Guillory immediately by e-mail if you have received 
this e-mail by mistake and delete this e-mail from your system. E-mail 
transmission cannot be guaranteed to be secure or error-free as information 
could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or 
contain viruses. Luke Guillory therefore does not accept liability for any 
errors or omissions in the contents of this message, which arise as a result of 
e-mail transmission. .

On Jan 13, 2017, at 11:07 PM, Cody Grosskopf  wrote:
>
> Maybe you can help.sell the product because that website doesn't do much in
> terms of selling the product. What does it do and why would we use it?
>
>> On Fri, Jan 13, 2017, 8:29 PM Fred Hicks  wrote:
>>
>> We have been using this:
>>
>> http://qwilt.com/
>>
>> It does all the Apple and IOS caching and is built for the ISP level and
>> then some.
>>
>>
>>
>>> On Fri, Jan 13, 2017 at 12:25 PM, Blake Hudson  wrote:
>>>
>>> lane.pow...@swat.coop wrote on 1/13/2017 7:43 AM:
>>>
 I saw the apple caching server mentioned on an earlier thread. Is this
 appropriate/functional/scaleable enough to implement as an ISP? It is an
 intriguing idea. From the docs I could find, I couldn't tell if it was
>> only
 geared towards home / small business or if it could scale up to handle
>> ISP
 level traffic.

 thanks,
 Lane

>>>
>>> I have no experience with the Apple caching service specifically, but I
>>> have used Apple products (including some of their server software) for
>>> decades. Apple used to make mac mini models exclusively for server use.
>>> Their low power draw and relatively high density makes them an
>> interesting
>>> choice for those that don't mind using "desktop grade" hardware for a
>>> project. There are some folks that even make rack-mount solutions for the
>>> Mac mini and Mac pro (search for RackMac). That said, my experience with
>>> several mac minis is that you will have at least one fault that will put
>>> them out of production (dead PSU, faulty HDD, dead mainboard) in a 2-3
>> year
>>> period when ran 24/7.
>>>
>>> With Unix OS, a gigabit ethernet port, SSD, and i5 or i7, I would expect
>> a
>>> mac mini to be as fast or faster than most other network appliances one
>>> might purchase. If one wanted something beefier, a mac pro would probably
>>> offer some expandability (on board dual 1gbps NICs + six 20Gbps
>> thunderbolt
>>> 2 ports).
>>>
>>> I would see why one might be curious, especially if this could cache the
>>> IOS updates used for all those tablets and other iDevices folks purchase
>>> from Apple.
>>>
>>
>>
>>
>> --
>> [image: email-signature-logo] 
>> *Fred Hicks*
>> Director of Network Communications
>> Information Technology
>> hi...@adelphi.edu
>> T 516.877.3338
>>

Re: External BGP Controller for L3 Switch BGP routing

[Jeremy Austin]

Tore Anderson:

https://www.redpill-linpro.com/sysadvent/2016/12/09/slimming-routing-table.html

On Fri, Jan 13, 2017 at 8:24 PM, Faisal Imtiaz 
wrote:

> Hello,
>
> A while back there was a discussion on how to do optimized (dynamic) BGP
> routing on a L3 switch which is only capable of handing a subset of BGP
> Routing table.
>
> Someone has pointed out that there was a project to do just that, and had
> posted a link to a presentation on a European operator (Ireland ? ) who had
> done some code to take Exabgp and create such a setup..
>
> (I am going by memory... )... Needless to say I am trying to find that
> link, or name of that project.
>
> Anyone who can help in refreshing my memory with the link (my search skill
> are failing to find that presentation !)
> would be greatly appreciated.
>
> Many Thanks in Advance.
>
> Faisal Imtiaz
>



-- 
Jeremy Austin

(907) 895-2311
(907) 803-5422
jhaus...@gmail.com

Heritage NetWorks
Whitestone Power & Communications
Vertical Broadband, LLC

Schedule a meeting: http://doodle.com/jermudgeon

External BGP Controller for L3 Switch BGP routing

[Faisal Imtiaz]

Hello,

A while back there was a discussion on how to do optimized (dynamic) BGP 
routing on a L3 switch which is only capable of handing a subset of BGP Routing 
table.

Someone has pointed out that there was a project to do just that, and had 
posted a link to a presentation on a European operator (Ireland ? ) who had 
done some code to take Exabgp and create such a setup..

(I am going by memory... )... Needless to say I am trying to find that link, or 
name of that project.

Anyone who can help in refreshing my memory with the link (my search skill are 
failing to find that presentation !)
would be greatly appreciated.

Many Thanks in Advance.

Faisal Imtiaz

Re: Apple Caching Server question

[Cody Grosskopf]

Maybe you can help.sell the product because that website doesn't do much in
terms of selling the product. What does it do and why would we use it?

On Fri, Jan 13, 2017, 8:29 PM Fred Hicks  wrote:

> We have been using this:
>
> http://qwilt.com/
>
> It does all the Apple and IOS caching and is built for the ISP level and
> then some.
>
>
>
> On Fri, Jan 13, 2017 at 12:25 PM, Blake Hudson  wrote:
>
> > lane.pow...@swat.coop wrote on 1/13/2017 7:43 AM:
> >
> >> I saw the apple caching server mentioned on an earlier thread. Is this
> >> appropriate/functional/scaleable enough to implement as an ISP? It is an
> >> intriguing idea. From the docs I could find, I couldn't tell if it was
> only
> >> geared towards home / small business or if it could scale up to handle
> ISP
> >> level traffic.
> >>
> >> thanks,
> >> Lane
> >>
> >
> > I have no experience with the Apple caching service specifically, but I
> > have used Apple products (including some of their server software) for
> > decades. Apple used to make mac mini models exclusively for server use.
> > Their low power draw and relatively high density makes them an
> interesting
> > choice for those that don't mind using "desktop grade" hardware for a
> > project. There are some folks that even make rack-mount solutions for the
> > Mac mini and Mac pro (search for RackMac). That said, my experience with
> > several mac minis is that you will have at least one fault that will put
> > them out of production (dead PSU, faulty HDD, dead mainboard) in a 2-3
> year
> > period when ran 24/7.
> >
> > With Unix OS, a gigabit ethernet port, SSD, and i5 or i7, I would expect
> a
> > mac mini to be as fast or faster than most other network appliances one
> > might purchase. If one wanted something beefier, a mac pro would probably
> > offer some expandability (on board dual 1gbps NICs + six 20Gbps
> thunderbolt
> > 2 ports).
> >
> > I would see why one might be curious, especially if this could cache the
> > IOS updates used for all those tablets and other iDevices folks purchase
> > from Apple.
> >
>
>
>
> --
> [image: email-signature-logo] 
> *Fred Hicks*
> Director of Network Communications
> Information Technology
> hi...@adelphi.edu
> T 516.877.3338
>

Re: Apple Caching Server question

[Fred Hicks]

We have been using this:

http://qwilt.com/

It does all the Apple and IOS caching and is built for the ISP level and
then some.



On Fri, Jan 13, 2017 at 12:25 PM, Blake Hudson  wrote:

> lane.pow...@swat.coop wrote on 1/13/2017 7:43 AM:
>
>> I saw the apple caching server mentioned on an earlier thread. Is this
>> appropriate/functional/scaleable enough to implement as an ISP? It is an
>> intriguing idea. From the docs I could find, I couldn't tell if it was only
>> geared towards home / small business or if it could scale up to handle ISP
>> level traffic.
>>
>> thanks,
>> Lane
>>
>
> I have no experience with the Apple caching service specifically, but I
> have used Apple products (including some of their server software) for
> decades. Apple used to make mac mini models exclusively for server use.
> Their low power draw and relatively high density makes them an interesting
> choice for those that don't mind using "desktop grade" hardware for a
> project. There are some folks that even make rack-mount solutions for the
> Mac mini and Mac pro (search for RackMac). That said, my experience with
> several mac minis is that you will have at least one fault that will put
> them out of production (dead PSU, faulty HDD, dead mainboard) in a 2-3 year
> period when ran 24/7.
>
> With Unix OS, a gigabit ethernet port, SSD, and i5 or i7, I would expect a
> mac mini to be as fast or faster than most other network appliances one
> might purchase. If one wanted something beefier, a mac pro would probably
> offer some expandability (on board dual 1gbps NICs + six 20Gbps thunderbolt
> 2 ports).
>
> I would see why one might be curious, especially if this could cache the
> IOS updates used for all those tablets and other iDevices folks purchase
> from Apple.
>



-- 
[image: email-signature-logo] 
*Fred Hicks*
Director of Network Communications
Information Technology
hi...@adelphi.edu
T 516.877.3338

Re: BGP Route Reflector - Route Server, Router, etc

[Randy Bush]

> Scaling in this context is simply adding more and more routers and
> needing/wanting to avoid configuring full mesh iBGP due to the
> administrative burden of maintaining the growing size of full mesh
> topology. In one particular network in question, I have 11 routers
> fully meshed and need to add several more over the coming 6-12 months,
> possibly adding as many as 10 more routers in that time span. I'd
> prefer not to continue doing full mesh.

if those numbers were x 10 or more, 'scaling' becomes a concern.

the way to add to an ibgp mesh or any other topology, including those
with rrs, is automation.

> As for 7206VXR with NPE-G1 or G2 cards, we have many sitting in a
> decommissioned state on shelves

i suspect there is a reason.

randy

Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)

[Valdis . Kletnieks]

On Sat, 14 Jan 2017 09:58:21 +1100, Mark Andrews said:
> In message , Fernando 
> Gont writes:
> > Disagree. Microsoft "reinvented" ping-o-death in IPv6, there have been
> > several one-packet crashes disclosed for Cisco's (an the list continues).
>
> And they would have issued fixes for them.  Machines get attacked
> from inside firewalls.  Only idiots do not apply security fixes.

Evidence suggests that our industry is highly overstocked with idiots.


pgpRjl32KdUaS.pgp
Description: PGP signature

Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)

[Mark Andrews]

In message <954a2fbd-580a-044b-07e7-63a0bf1bb...@si6networks.com>, Fernando 
Gont writes:
> On 01/12/2017 11:14 PM, Mark Andrews wrote:
> > In message 
> > 

Re: Apple Caching Server question

[Mike Hammett]

There are far more ISPs with less than 10G of total traffic than ISPs with more 
than 10G of traffic. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "joel jaeggli"  
To: "lane powers" , nanog@nanog.org 
Sent: Friday, January 13, 2017 10:45:08 AM 
Subject: Re: Apple Caching Server question 

On 1/13/17 5:43 AM, lane.pow...@swat.coop wrote: 
> I saw the apple caching server mentioned on an earlier thread. Is this 
> appropriate/functional/scaleable enough to implement as an ISP? It is an 
> intriguing idea. From the docs I could find, I couldn't tell if it was only 
> geared towards home / small business or if it could scale up to handle ISP 
> level traffic. 

It's a feature of macos server. You do get to register prefix with 
apple, but I don't imagine colocating a mac mini is isp level traffic. 

That said as714 peers extensively 

https://www.peeringdb.com/net/3554 

so picking them up works too. 

> thanks, 
> Lane 
> 

Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)

[Mark Andrews]

In message , Fernando 
Gont writes:
> On 01/12/2017 11:07 PM, Mark Andrews wrote:
> > In message 
> > 
> > , Fernando Gont writes:
> >> El 12/1/2017 16:28, "Mark Andrews"  escribi=C3=B3:
> >>
> >>> In message <11ff128d-2fba-7c26-4a9c-5611433d8...@si6networks.com>, 
> >>> Fernando Gont writes:
>  Hi, Saku,
> 
>  On 01/12/2017 11:43 AM, Saku Ytti wrote:
> > On 12 January 2017 at 13:19, Fernando Gont 
> >>> wrote:
> >
> > Hey,
> >
> >> I'm curious about whether folks are normally filtering ICMPv6 PTB<1280
> >> and/or IPv6 fragments targeted to BGP routers (off-list datapoints are
> >> welcome).
> >
> > Generally may be understood differently by different people. If
> > generally is defined as single most typical behaviour/configuration,
> > then generally people don't protect their infrastructure in any way at
> > all, but fully rely vendor doing something reasonable.
> >
> > I would argue BCP is to have 'strict' CoPP. Where you specifically
> > allow what you must then have ultimate rule to deny everything. If you
> > have such CoPP, then this attack won't work, as you clearly didn't
> > allow any fragments at all (as you didn't expect to receive BGP
> > fragments from your neighbours).
> 
>  That's the point: If you don't allow fragments, but your peer honors
>  ICMPv6 PTB<1280, then dropping fragments creates the attack vector.
> >>>
> >>> And fragments are a *normal* part of IP for both IPv4 and IPv6.
> >>> This obsession with dropping all fragments (and yes it is a obsession)
> >>> is breaking the internet.
> >>
> >> Vendors got the frag reassembly code wrong so many times , that I
> >> understand the folk that decides to drop them if deemed unnecessary.
> > 
> > Most of them literally decades ago. 
> 
> Disagree. Microsoft "reinvented" ping-o-death in IPv6, there have been
> several one-packet crashes disclosed for Cisco's (an the list continues).

And they would have issued fixes for them.  Machines get attacked
from inside firewalls.  Only idiots do not apply security fixes.

> > 20+ years ago while you waited
> > for you vendor to fix the bug it made some sense as most of your
> > boxes were vulnerable.  It was a new threat back then.  It doesn't
> > make sense today.
> 
> Let's face it: The quality of many IPv6 implementations is that of IPv4
> implementations in the '90s. Sad, but true.

Not really.  For most of them the two stacks are in basically similar
states.  Most of the code is shared.

> > Packet bigger than 1500 are a part of todays internet.  Have a look
> > a the stats for dropped fragments.  They aren't for the most part
> > attack traffic.  Its legitmate reply traffic that has been requested.
> 
> I don't disagree with you wrt the need for fragmentation in some
> scenarios. I'm just saying that when you only employ TCP-based services,
> it may make sense to drop fragments targeted *at you*.
> 
> Fragmentation is only needed for non-TCP services. and if your system
> does not use non-tcp services, it may be a sensible thing to drop
> fragments targetted at you.

Firstly framentation happens with TCP and IPv6 today.  Just set
IPV6_USE_MIN_MTU on the socket.  It shouldn't happen as TCP is
supposed to use the MTU information on the socket but it doesn't
in many implementations.

Secondly there is no site that doesn't use protocols that send
fragmentent packets.  They will all be using DNS and DNS sends
fragmented UDP in its replies.  This has been the case since the
late 1990's.

Mark

> Thanks,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail: fg...@si6networks.com
> PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Bandwidth Savings

[Fearghas Mckay]

Keenan

> On 11 Jan 2017, at 15:10, Luke Guillory  wrote:
> 
> Netflix won’t even begin talks for their cache if you're not doing a minimum 
> of 5Gbps.

Outside of the US I believe it is less based on presentations I have seen in 
Africa.

> They also require massive uploads to the cache often, these are things are 
> 200TB now if I recall and they send everything unlike the transparent who 
> only grab what's already being consumed.

Talk to their inter-connect team, the ones I know are very approachable.

f

Re: BGP Route Reflector - Route Server, Router, etc

[Brandon Ewing]

On Thu, Jan 12, 2017 at 08:32:44PM +, Justin Krejci wrote:
> What are the pros and cons of one design over another? On list or private off 
> list replies would be great; I'd welcome real world experiences (especially 
> any big gotchas or caveats people learned the hard way) as well as just links 
> to previous discussions, PDFs, slideshows, etc. Heck even a good book 
> suggestion that covers this topic would be appreciated.
> 

One important thing to remember when migrating from full mesh to a RR design
is that you are reducing information available to the routers in the ASN.
When you had a full mesh, each router could select the best path from all
available paths, according to its position in the IGP.  In a RR environment,
by default, routers only have available to them the best routes from the
RR's position in the IGP, which can lead to suboptimal exits being selected.

Work is being done to allow RRs to compute metrics from the client's
position in the IGP: See
https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-13
for more information

-- 
Brandon Ewing (nicot...@warningg.com)


pgpdsA85bd0XI.pgp
Description: PGP signature

RE: BGP Route Reflector - Route Server, Router, etc

[Justin Krejci]

Thanks for all of the replies (on and off list). It is appreciated.

Scaling in this context is simply adding more and more routers and 
needing/wanting to avoid configuring full mesh iBGP due to the administrative 
burden of maintaining the growing size of full mesh topology. In one particular 
network in question, I have 11 routers fully meshed and need to add several 
more over the coming 6-12 months, possibly adding as many as 10 more routers in 
that time span. I'd prefer not to continue doing full mesh.

As for 7206VXR with NPE-G1 or G2 cards, we have many sitting in a 
decommissioned state on shelves as well as a few still alive serving a handful 
of T-1 lines and various other legacy connections of that sort. These little 
7200's sit and run, forever near as I can tell. As many routers in this network 
do contain full route eBGP connections I will strongly consider your suggestion 
of avoiding using the 7200's due to potential memory constraints and 
CPU/convergence time capabilities. I don't think I have done any full table 
feeds on a 7200 in many years (days of 200k-300k table size days)

This fits in with the kind of feedback I was hoping for, Thanks!



From: NANOG [nanog-boun...@nanog.org] on behalf of Leo Bicknell 
[bickn...@ufp.org]
Sent: Friday, January 13, 2017 7:23 AM
To: nanog@nanog.org
Subject: Re: BGP Route Reflector - Route Server, Router, etc

In a message written on Thu, Jan 12, 2017 at 08:32:44PM +, Justin Krejci 
wrote:
> I am working on some network designs and am adding some additional routers to 
> a BGP network. I'd like to build a plan of changing all of the existing 
> routers over from full iBGP mesh to something more scalable (ie route 
> reflection).

You might want to better define "scalable".  I don't know your
background or network so I can't guess.  I can say I've seen
the inner workings of some large ISP networks with a lot of hosts
in iBGP that work fine, and then people with 5 routers try and
tell me they have a scaling problem.

What is your actual problem?  Memory usage?  Convergence time?
Configuring the sessions?  Staff understanding of how it works?

> I am wondering if people can point me in the direction to some good resource 
> material on how to select a good BGP route reflector design. Should I just 
> dust off some 7206VXR routers to act as route reflectors?

This is a red flag to me, relative to the questions above.

The 7206VXR, even with an NPE-G2, is a 1.5Ghz Power PC with a paltry
2GB of DRAM.  It was not speedy when new, being roughly equivilent
to the PowerPC G4 processors in Apple Laptops at the time.  It is
approximately 8 times slower than a current iPhone.  Seriously.

If convergence time is anything you care about, a 7206VXR is a very
bad choice.  It may also run out of memory if you have a lot of
edges with full tables.

So what's the actual "scaling" problem?

--
Leo Bicknell - bickn...@ufp.org
PGP keys at http://www.ufp.org/~bicknell/

Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)

[Fernando Gont]

On 01/12/2017 11:14 PM, Mark Andrews wrote:
> In message 
> 

Re: ICMPv6 PTBs and IPv6 frag filtering (particularly at BGP peers)

[Fernando Gont]

On 01/12/2017 11:07 PM, Mark Andrews wrote:
> In message 
> 
> , Fernando Gont writes:
>> El 12/1/2017 16:28, "Mark Andrews"  escribi=C3=B3:
>>
>>> In message <11ff128d-2fba-7c26-4a9c-5611433d8...@si6networks.com>, Fernando 
>>> Gont writes:
 Hi, Saku,

 On 01/12/2017 11:43 AM, Saku Ytti wrote:
> On 12 January 2017 at 13:19, Fernando Gont 
>>> wrote:
>
> Hey,
>
>> I'm curious about whether folks are normally filtering ICMPv6 PTB<1280
>> and/or IPv6 fragments targeted to BGP routers (off-list datapoints are
>> welcome).
>
> Generally may be understood differently by different people. If
> generally is defined as single most typical behaviour/configuration,
> then generally people don't protect their infrastructure in any way at
> all, but fully rely vendor doing something reasonable.
>
> I would argue BCP is to have 'strict' CoPP. Where you specifically
> allow what you must then have ultimate rule to deny everything. If you
> have such CoPP, then this attack won't work, as you clearly didn't
> allow any fragments at all (as you didn't expect to receive BGP
> fragments from your neighbours).

 That's the point: If you don't allow fragments, but your peer honors
 ICMPv6 PTB<1280, then dropping fragments creates the attack vector.
>>>
>>> And fragments are a *normal* part of IP for both IPv4 and IPv6.
>>> This obsession with dropping all fragments (and yes it is a obsession)
>>> is breaking the internet.
>>
>> Vendors got the frag reassembly code wrong so many times , that I
>> understand the folk that decides to drop them if deemed unnecessary.
> 
> Most of them literally decades ago. 

Disagree. Microsoft "reinvented" ping-o-death in IPv6, there have been
several one-packet crashes disclosed for Cisco's (an the list continues).



> 20+ years ago while you waited
> for you vendor to fix the bug it made some sense as most of your
> boxes were vulnerable.  It was a new threat back then.  It doesn't
> make sense today.

Let's face it: The quality of many IPv6 implementations is that of IPv4
implementations in the '90s. Sad, but true.



> Packet bigger than 1500 are a part of todays internet.  Have a look
> a the stats for dropped fragments.  They aren't for the most part
> attack traffic.  Its legitmate reply traffic that has been requested.

I don't disagree with you wrt the need for fragmentation in some
scenarios. I'm just saying that when you only employ TCP-based services,
it may make sense to drop fragments targeted *at you*.

Fragmentation is only needed for non-TCP services. and if your system
does not use non-tcp services, it may be a sensible thing to drop
fragments targetted at you.


Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

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 14 Jan, 2017

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

Analysis Summary


BGP routing table entries examined:  628138
Prefixes after maximum aggregation (per Origin AS):  221607
Deaggregation factor:  2.83
Unique aggregates announced (without unneeded subnets):  304580
Total ASes present in the Internet Routing Table: 55581
Prefixes per ASN: 11.30
Origin-only ASes present in the Internet Routing Table:   36240
Origin ASes announcing only one prefix:   15211
Transit ASes present in the Internet Routing Table:6557
Transit-only ASes present in the Internet Routing Table:170
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  55
Max AS path prepend of ASN ( 55644)  51
Prefixes from unregistered ASNs in the Routing Table:51
Unregistered ASNs in the Routing Table:  16
Number of 32-bit ASNs allocated by the RIRs:  16861
Number of 32-bit ASNs visible in the Routing Table:   12784
Prefixes from 32-bit ASNs in the Routing Table:   52671
Number of bogon 32-bit ASNs visible in the Routing Table:   725
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:381
Number of addresses announced to Internet:   2832873956
Equivalent to 168 /8s, 218 /16s and 57 /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.4
Total number of prefixes smaller than registry allocations:  208158

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   156458
Total APNIC prefixes after maximum aggregation:   43125
APNIC Deaggregation factor:3.63
Prefixes being announced from the APNIC address blocks:  171200
Unique aggregates announced from the APNIC address blocks:70946
APNIC Region origin ASes present in the Internet Routing Table:5188
APNIC Prefixes per ASN:   33.00
APNIC Region origin ASes announcing only one prefix:   1135
APNIC Region transit ASes present in the Internet Routing Table:941
Average APNIC Region AS path length visible:4.4
Max APNIC Region AS path length visible: 55
Number of APNIC region 32-bit ASNs visible in the Routing Table:   2610
Number of APNIC addresses announced to Internet:  761620356
Equivalent to 45 /8s, 101 /16s and 103 /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:188178
Total ARIN prefixes after maximum aggregation:89286
ARIN Deaggregation factor: 2.11
Prefixes being announced from the ARIN address blocks:   195218
Unique aggregates announced from the ARIN address blocks: 89636
ARIN Region origin ASes present in the Internet Routing Table:16064
ARIN Prefixes per ASN:12.15

Re: Apple Caching Server question

[Blake Hudson]

lane.pow...@swat.coop wrote on 1/13/2017 7:43 AM:

I saw the apple caching server mentioned on an earlier thread. Is this 
appropriate/functional/scaleable enough to implement as an ISP? It is an 
intriguing idea. From the docs I could find, I couldn't tell if it was only 
geared towards home / small business or if it could scale up to handle ISP 
level traffic.

thanks,
Lane


I have no experience with the Apple caching service specifically, but I 
have used Apple products (including some of their server software) for 
decades. Apple used to make mac mini models exclusively for server use. 
Their low power draw and relatively high density makes them an 
interesting choice for those that don't mind using "desktop grade" 
hardware for a project. There are some folks that even make rack-mount 
solutions for the Mac mini and Mac pro (search for RackMac). That said, 
my experience with several mac minis is that you will have at least one 
fault that will put them out of production (dead PSU, faulty HDD, dead 
mainboard) in a 2-3 year period when ran 24/7.


With Unix OS, a gigabit ethernet port, SSD, and i5 or i7, I would expect 
a mac mini to be as fast or faster than most other network appliances 
one might purchase. If one wanted something beefier, a mac pro would 
probably offer some expandability (on board dual 1gbps NICs + six 20Gbps 
thunderbolt 2 ports).


I would see why one might be curious, especially if this could cache the 
IOS updates used for all those tablets and other iDevices folks purchase 
from Apple.

Re: Apple Caching Server question

[joel jaeggli]

On 1/13/17 5:43 AM, lane.pow...@swat.coop wrote:
> I saw the apple caching server mentioned on an earlier thread. Is this 
> appropriate/functional/scaleable enough to implement as an ISP? It is an 
> intriguing idea. From the docs I could find, I couldn't tell if it was only 
> geared towards home / small business or if it could scale up to handle ISP 
> level traffic. 

It's a feature of macos server. You do get to register prefix with
apple, but I don't imagine colocating a mac mini is isp level traffic.

That said as714 peers extensively

https://www.peeringdb.com/net/3554

so picking them up works too.

> thanks, 
> Lane 
> 




signature.asc
Description: OpenPGP digital signature

You're invited to St. Louis Regional Internet Exchange - Preview (Jan 19, 2017)

[St. Louis Regional Internet Exchange]

The St. Louis region to benefit from improved digital capacity and Smart City 
infrastructure capability.

To help address the demands of data oriented businesses and startups, the 
Internet of Things (IoT) and the Smart City, a team of industry recognized 
experts has developed the St. Louis Regional Internet Exchange or STL-RIX.

The St Louis Regional Internet Exchange is a not for profit corporation, in a 
collaborative partnership with the Smart City Internet Exchange (SCIX), 
theMidWest Internet Exchange and the St. Louis region.

When operational in February, this capability will provide an unprecedented 
opportunity for business collaboration, and Smart City economic development, 
for the St. Louis region.

Lightning Round Agenda:
10:30 AM Welcome - Owen Graham - Netrality Properties
Keynote - Jerry Cox CEO Blendics and Founder of SLIAC
Smart City St. Louis- Jim Highfill and David Sandel - Founders of 
Innovation Neighborhoods
Business Structure - Andrew Ruben -PAULE, CAMAZINE  BLUMENTHAL, P.C
Brief Tech and Ops Description - Mike Hammett and Justin Wilson (MIX), Nathan 
Schrenk (STL-RIX, SCIX)
Market Perspective - Moderator: Noted Technical Writer David Strom,Ken 
Owens Cisco CTO Cloud Platforms and Services Group, Joe Wojtal VP SP Solutions 
WWT, Ken Harrington BayBerry Group, Richard Schreier Canadian Internet 
Registration Authority
11:40 AM Panel and Press- General QA
Official Press Release

Share this event on Facebook and Twitter We hope you can make it!Cheers,St. 
Louis Regional Internet Exchange

--
Event Summary:
--

Event: St. Louis Regional Internet Exchange - Preview
Date: Thursday, January 19, 2017 from 10:30 AM to 12:00 PM (CST)
Location: bCIC - The Havana Room/bbr /4240 Duncan 
Avenue br /St. Louis, MO 63110br /

--
Event Details:
--

The St. Louis region to benefit from improved digital capacity and Smart City 
infrastructure capability.
To help address the demands of data oriented businesses and startups, the 
Internet of Things (IoT) and the Smart City, a team of industry recognized 
experts has developed the St. Louis Regional Internet Exchange or STL-RIX.
The St Louis Regional Internet Exchange is a not for profit corporation, in a 
collaborative partnership with the Smart City Internet Exchange (SCIX), the 
MidWest Internet Exchange and the St. Louis region.
When operational in February, this capability will provide an unprecedented 
opportunity for business collaboration, and Smart City economic development, 
for the St. Louis region.
Lightning Round Agenda:
10:30 AM Welcome - Owen Graham - Netrality Properties
Keynote - Jerry Cox CEO Blendics and Founder of SLIAC
Smart City St. Louis - Jim Highfill and David Sandel - Founders of Innovation 
Neighborhoods
Business Structure - Andrew Ruben - PAULE, CAMAZINE & BLUMENTHAL, P.C
Brief Tech and Ops Description - Mike Hammett and Justin Wilson (MIX), Nathan 
Schrenk (STL-RIX, SCIX)
Market Perspective - Moderator: Noted Technical Writer David Strom, Ken Owens 
Cisco CTO Cloud Platforms and Services Group, Joe Wojtal VP SP Solutions WWT, 
Ken Harrington BayBerry Group, Richard Schreier Canadian Internet Registration 
Authority
11:40 AM Panel and Press - General Q
Official Press Release


--
Hosted By:
--
St. Louis Regional Internet Exchange
The St Louis Regional Internet Exchange (STL-RIX), is a not-for-profit 
corporation in a collaborative partnership with the Midwest Internet Exchange 
(MIX), and Smart City Internet Exchange (SCIX). STL-RIX offers both traditional 
IX services as well as an additional switch fabric for the provisioning of 
Smart City and (IoT) services.

--
Register Online:
--

More information and online registration are available here:
https://www.eventbrite.com/e/st-louis-regional-internet-exchange-preview-tickets-30329718003?ref=enivtefor001=MTEzNDMwMjUvbmFub2dAbmFub2cub3JnLzA%3D

--

Collect event fees online with Eventbrite
http://www.eventbrite.com

Re: Apple Caching Server question

[lane . powers]

I saw the apple caching server mentioned on an earlier thread. Is this 
appropriate/functional/scaleable enough to implement as an ISP? It is an 
intriguing idea. From the docs I could find, I couldn't tell if it was only 
geared towards home / small business or if it could scale up to handle ISP 
level traffic. 

thanks, 
Lane 

Re: BGP Route Reflector - Route Server, Router, etc

[Leo Bicknell]

In a message written on Thu, Jan 12, 2017 at 08:32:44PM +, Justin Krejci 
wrote:
> I am working on some network designs and am adding some additional routers to 
> a BGP network. I'd like to build a plan of changing all of the existing 
> routers over from full iBGP mesh to something more scalable (ie route 
> reflection).

You might want to better define "scalable".  I don't know your
background or network so I can't guess.  I can say I've seen
the inner workings of some large ISP networks with a lot of hosts
in iBGP that work fine, and then people with 5 routers try and
tell me they have a scaling problem.

What is your actual problem?  Memory usage?  Convergence time?
Configuring the sessions?  Staff understanding of how it works?

> I am wondering if people can point me in the direction to some good resource 
> material on how to select a good BGP route reflector design. Should I just 
> dust off some 7206VXR routers to act as route reflectors?

This is a red flag to me, relative to the questions above.

The 7206VXR, even with an NPE-G2, is a 1.5Ghz Power PC with a paltry
2GB of DRAM.  It was not speedy when new, being roughly equivilent
to the PowerPC G4 processors in Apple Laptops at the time.  It is
approximately 8 times slower than a current iPhone.  Seriously.

If convergence time is anything you care about, a 7206VXR is a very
bad choice.  It may also run out of memory if you have a lot of
edges with full tables.

So what's the actual "scaling" problem?

-- 
Leo Bicknell - bickn...@ufp.org
PGP keys at http://www.ufp.org/~bicknell/


signature.asc
Description: PGP signature

Re: BGP Route Reflector - Route Server, Router, etc

[Robert Blayzor]

On Jan 12, 2017, at 5:59 PM, James Bensley  wrote:
> 
> The CSR1000v (IOS-XE),IOS-XRv and vMX are production ready. People are
> deploying these in production and its increasing in popularity.


+1 here on the CSR1000v, works very well.

However, I’d have to give another +1 to XRv because RPL is more flexible and 
easier to manage than route-maps in IOS.


--
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP Key: 78BEDCE1 @ pgp.mit.edu

Re: BGP Route Reflector - Route Server, Router, etc

[Phil Bedard]

The vRR image and the vMX have always been separate.  The vRR image is what 
Juniper sells as a solution for control-plane only applications like vRR.  It’s 
also the image they run as part of their Northstar controller to speak BGP-LS 
to the network.   It’s very lightweight, you can run a bunch of them in very 
little memory space, for instance if you want to do a vRR per AFI/SAFI, or 
service.  I’ve tested it against the vMX in applications like vRR and the 
performance is pretty much identical with much less memory/cpu use.  

Cisco makes a distinction between IOS-XRv which is their simulation/test 
version of XR like you would find in VIRL/CML and the XRv-9000 which is 
optimized for higher throughput.  They sell a vRR-specific version of the 
XRv-9000 that is very reasonably priced.   XRv-9000 is a bit more cpu/memory 
intensive in my experience.  

Nokia also has a vRR version of their SR-OS virtual router.  It has a 
lightweight cpu/memory footprint and is very fast.  But really all of the 
virtual vRR solutions are fast and scale very high, little performance 
difference between them.  I would recommend one based on the vendors you are 
most comfortable with and support for the AFI/SAFIs you are interested in.  

Phil 

-Original Message-
From: NANOG  on behalf of James Bensley 

Date: Friday, January 13, 2017 at 06:04
To: "NANOG ‎[nanog@nanog.org]‎" 
Subject: Re: BGP Route Reflector - Route Server, Router, etc

On 13 January 2017 at 04:02, Hugo Slabbert  wrote:
>
> On Thu 2017-Jan-12 22:59:21 +, James Bensley 
> wrote:
>
>> On 12 January 2017 at 20:32, Justin Krejci  
wrote:
>>>
>>> . I have not found many resources discussing using a non-router box as a
>>> route reflector (ie a device not necessarily in the forwarding path of 
the
>>> through traffic). I am thinking things like OpenBGPd and BIRD could 
make a
>>> good route reflector though they are most often discussed in the 
context of
>>> IXPs (ie eBGP sessions).
>>
>>
>> The CSR1000v (IOS-XE),IOS-XRv and vMX are production ready. People are
>> deploying these in production and its increasing in popularity.
>
>
> Any thoughts on vRR vs. vMX for this use case?  I see Mark called out vRR 
as
> having morphed into vMX, but AFAIK vRR is just vMX minus the forwarding
> plane, is targeted as an out-of-path reflector, and coexists with vMX as a
> different deployment option rather than having been replaced by it.  I 
would
> assume that vRR should come in a few bucks lower than the vMX as a result,
> but I've only previously gotten quotes on vRR not vMX.
>
>
>> Mark Tinka gave a good preso at a recent Nanog:
>>
>> 
https://www.nanog.org/sites/default/files/2_Tinka_21st_Century_iBGP_Route_Reflection.pdf
>>
>> 
https://www.youtube.com/watch?v=wLEjOj2fyp8=PLO8DR5ZGla8hcpeEDSBNPE5OrZf70iXZg=21
>>
>> Cheers,
>> James.
>
>
> --
> Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
> pgp key: B178313E   | also on Signal


Sorry I don't know about the pricing, but the newer vMX product is now
split into two VMs, the virtual control plane and virtual forwarding
plane. I think the vRR product is still like the "older" style vMX
which was one combined control and forwarding plane image. At a guess,
perhaps its heavy throughput limited?

We have used the "older" style vMX images in the lab (14.something)
which is the combined all in one VM, it works fine for us for actual
network traffic testing as well as various BGP tests like router
reflectors so I see know reason why it wouldn't work as a vRR. I think
the actual "vRR" product from Juniper is just a more light weight VM,
perhaps someone can clarify the tech behind it?

We don't have any virtual RRs in production yet but we are running
CSR1000v in lab tests right now which is working fine for us so we'll
probably push that out to prod at some point in both scenarios (as an
in path virtual router and out of path virtual route-reflector) but
that is 12+ months away as we still have lots more testing to do.

Cheers,
James.

Re: BGP Route Reflector - Route Server, Router, etc

[James Bensley]

On 13 January 2017 at 04:02, Hugo Slabbert  wrote:
>
> On Thu 2017-Jan-12 22:59:21 +, James Bensley 
> wrote:
>
>> On 12 January 2017 at 20:32, Justin Krejci  wrote:
>>>
>>> . I have not found many resources discussing using a non-router box as a
>>> route reflector (ie a device not necessarily in the forwarding path of the
>>> through traffic). I am thinking things like OpenBGPd and BIRD could make a
>>> good route reflector though they are most often discussed in the context of
>>> IXPs (ie eBGP sessions).
>>
>>
>> The CSR1000v (IOS-XE),IOS-XRv and vMX are production ready. People are
>> deploying these in production and its increasing in popularity.
>
>
> Any thoughts on vRR vs. vMX for this use case?  I see Mark called out vRR as
> having morphed into vMX, but AFAIK vRR is just vMX minus the forwarding
> plane, is targeted as an out-of-path reflector, and coexists with vMX as a
> different deployment option rather than having been replaced by it.  I would
> assume that vRR should come in a few bucks lower than the vMX as a result,
> but I've only previously gotten quotes on vRR not vMX.
>
>
>> Mark Tinka gave a good preso at a recent Nanog:
>>
>> https://www.nanog.org/sites/default/files/2_Tinka_21st_Century_iBGP_Route_Reflection.pdf
>>
>> https://www.youtube.com/watch?v=wLEjOj2fyp8=PLO8DR5ZGla8hcpeEDSBNPE5OrZf70iXZg=21
>>
>> Cheers,
>> James.
>
>
> --
> Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
> pgp key: B178313E   | also on Signal


Sorry I don't know about the pricing, but the newer vMX product is now
split into two VMs, the virtual control plane and virtual forwarding
plane. I think the vRR product is still like the "older" style vMX
which was one combined control and forwarding plane image. At a guess,
perhaps its heavy throughput limited?

We have used the "older" style vMX images in the lab (14.something)
which is the combined all in one VM, it works fine for us for actual
network traffic testing as well as various BGP tests like router
reflectors so I see know reason why it wouldn't work as a vRR. I think
the actual "vRR" product from Juniper is just a more light weight VM,
perhaps someone can clarify the tech behind it?

We don't have any virtual RRs in production yet but we are running
CSR1000v in lab tests right now which is working fine for us so we'll
probably push that out to prod at some point in both scenarios (as an
in path virtual router and out of path virtual route-reflector) but
that is 12+ months away as we still have lots more testing to do.

Cheers,
James.

Re: BGP Route Reflector - Route Server, Router, etc

[Chris Russell]

The CSR1000v (IOS-XE),IOS-XRv and vMX are production ready. People 
are

deploying these in production and its increasing in popularity.

Mark Tinka gave a good preso at a recent Nanog:

https://www.nanog.org/sites/default/files/2_Tinka_21st_Century_iBGP_Route_Reflection.pdf

https://www.youtube.com/watch?v=wLEjOj2fyp8=PLO8DR5ZGla8hcpeEDSBNPE5OrZf70iXZg=21


 +1 , not used in production but fantastic in a couple of our lab 
environments



Chris