Re: BGP peering strategies for smaller routers

[James Milko]

On Mon, May 2, 2016 at 3:07 PM, Mike  wrote:

> Hello,
>
> I have an ASR1000 router with 4gb of ram. The specs say I can get '1
> million routes' on it, but as far as I have been advised, a full table of
> internet routes numbers more than 530k by itself, so taking 2 full tables
> seems to be out of the question (?).
>
>  I am looking to connect to a second ip transit provider and I'm
> looking for any advice or strategies that would allow me to take advantage
> and make good forwarding decisions while not breaking the bank on bgp
> memory consumption. I simply don't understand how this would likely play
> out and what memory consumption mitigation steps may be necessary here. Im
> open to ideas... a pair of route reflectors? selective bgp download? static
> route filter maps?
>
> Thank you.
>
> Mike-
>
>
You have to keep in mind there are two pools of memory on the router.  The
RIB and the FIB.  The RIB contains all the routes that the router could
possibly load.  This includes all your BGP routes, even the ones not
selected as best, and all your IGP routes.  Whereas the FIB would only have
the best routes that the router is actively using to forward traffic.

FIB = 'sh ip route 4.2.2.2'
RIB = 'sh ip bgp 4.2.2.2' (or OSPF, or IS-IS, or RIP, etc, etc)

Generally FIB capacity is given as a number of routes and RIB capacity is
given as a memory amount.  Since the router manufacturer doesn't know what
protocols you'll be running or how many attributes you'll be storing they
don't really have a good idea of how many routes you'll get in the memory
the router has.

Now that you have a full table on the router, you won't see much growth on
the FIB.  For the most part every route you'll learn is already learned.
You'll have some growth because not every transit provider will advertise
the exact same table.  My router with 3 transits has 580k routes for
instance.

In short, you're fine.  Read up on RIB and FIB though so you have a good
handle on when you're about to start running into problems.

JM

Re: 60 hudson - insurance?

[James Milko]

We got this from them a few years ago.  Same story to pull up the dock as
well.


On Thu, Jun 23, 2016 at 11:52 AM, Dovid Bender  wrote:

> Chris,
>
> We were told this a long time ago. You can always just say they work for
> you ;)
>
>
> Regards,
>
> Dovid
>
> -Original Message-
> From: Chris McDonald 
> Sender: "NANOG" Date: Thu, 23 Jun 2016 16:22:30
> To: nanog list
> Subject: 60 hudson - insurance?
>
> are others being told that their remote hands / installers , etc now need
> to show proof of insurance?
>
> thanks
>

Re: Feedback - SBC Vendors.

[James Milko]

 Which Ribbon product are you looking at?  There are quite a few now and
they have different code bases/features.

JM

On Wed, Aug 8, 2018 at 7:56 PM, Ryan Finnesey  wrote:

> I am going to have to install a series of SBCs for a  voice offering
> connected to Microsoft Teams.  We are going to pass the SIP traffic off to
> a larger number of SIP providers.  I would like  to get some feedback from
> the group on SBC vendors.  I have two options for vendors Ribbon or
> AudioCodes.  I am leaning towards a software based SBC over an appliance.
>
> Would be helpful to get the other members feedback on Ribbon or AudioCodes
> deployments within their networks.
>
> Cheers
> Ryan
>
>

Re: For the Wireless Guys

[James Milko]

Never has the phrase "It burns when IP" been more accurate.



On Wed, Aug 16, 2017 at 5:03 PM, Jon Lewis  wrote:

> On Wed, 16 Aug 2017, Sean Heskett wrote:
>
> 2.4GHz is only stopped by a tree because the FCC EIRP limit for point to
>> multipoint gear is 4 watts or 36dbm.  If you turn the power up high enough
>> 2.4GHz will easily go through trees and other objects.  It's a regulatory
>> limit, not a physics limit ;-)
>>
>
> So you're saying, with enough power, line of sight will be cleared...at
> least of any organic obstacles?  :)
>
> --
>  Jon Lewis, MCP :)   |  I route
>  |  therefore you are
> _ http://www.lewis.org/~jlewis/pgp for PGP public key_
>

Spectrum prefix hijacks

[James Milko]

Not sure if anyone from Spectrum is looking here at this hour, but someone
is hijacking a few of your prefixes.  It's causing problems in my area (NC)
with reaching Google services.  I'm sure there are other impacts, but
that's what people are noticing.

Sorry if this hits the list twice, I sent it from the wrong e-mail address
the first go round.

 *   107.12.0.0/16193.0.0.56 0  1103
203040 10512 i
 *>   103.247.3.45   0 58511 203040
10512 i
 *   107.13.0.0/16193.0.0.56 0  1103
203040 10512 i
 *>   103.247.3.45   0 58511 203040
10512 i
 *   107.14.0.0/16193.0.0.56 0  1103
203040 10512 i
 Network  Next HopMetric LocPrf Weight Path
 *>   103.247.3.45   0 58511 203040
10512 i
 *   107.15.0.0/16193.0.0.56 0  1103
203040 10512 i
 *103.247.3.45   0 58511 203040
10512 i

Re: Spectrum prefix hijacks

[James Milko]

The output I dumped was from route-views.routeviews.org.  On affected
prefes you get 7843->6453->nothing unaffected prefixes get
7843->6453->15169.  Unaffected prefixes don't have more specifics from
10512.  My sample size is only 8 though with a mix of affected and
unaffected users.

JM

On Tue, Jan 2, 2018 at 9:30 PM, Christopher Morrow 
wrote:

> it looks like 203040 is a pure transit as (no originated prefixes) and
> 1103 - surfnet could squish what is your view anyway.
>
> On Tue, Jan 2, 2018 at 9:29 PM, Christopher Morrow <
> morrowc.li...@gmail.com> wrote:
>
>>
>>
>> On Tue, Jan 2, 2018 at 8:50 PM, James Milko  wrote:
>>
>>> Not sure if anyone from Spectrum is looking here at this hour, but
>>> someone
>>> is hijacking a few of your prefixes.  It's causing problems in my area
>>> (NC)
>>> with reaching Google services.  I'm sure there are other impacts, but
>>> that's what people are noticing.
>>>
>>> Sorry if this hits the list twice, I sent it from the wrong e-mail
>>> address
>>> the first go round.
>>>
>>>  *   107.12.0.0/16193.0.0.56 0  1103
>>> 203040 10512 i
>>>  *>   103.247.3.45   0 58511
>>> 203040
>>> 10512 i
>>>  *   107.13.0.0/16193.0.0.56 0  1103
>>> 203040 10512 i
>>>  *>   103.247.3.45   0 58511
>>> 203040
>>> 10512 i
>>>  *   107.14.0.0/16193.0.0.56 0  1103
>>> 203040 10512 i
>>>  Network  Next HopMetric LocPrf Weight Path
>>>  *>   103.247.3.45   0 58511
>>> 203040
>>> 10512 i
>>>  *   107.15.0.0/16193.0.0.56 0  1103
>>> 203040 10512 i
>>>  *103.247.3.45   0 58511
>>> 203040
>>> 10512 i
>>>
>>
>> E-Forex you say? shocker:
>>
>> AS  | BGP IPv4 Prefix | AS Name
>> 10512   | 102.164.0.0/16  | EFOREX-AS - E-FOREX, US
>> 10512   | 102.194.0.0/16  | EFOREX-AS - E-FOREX, US
>> 10512   | 103.116.0.0/16  | EFOREX-AS - E-FOREX, US
>> 10512   | 106.128.0.0/16  | EFOREX-AS - E-FOREX, US
>> 10512   | 106.129.0.0/16  | EFOREX-AS - E-FOREX, US
>> 10512   | 106.130.0.0/16  | EFOREX-AS - E-FOREX, US
>> 10512   | 106.131.0.0/16  | EFOREX-AS - E-FOREX, US
>> 10512   | 107.12.0.0/16   | EFOREX-AS - E-FOREX, US
>> 10512   | 107.13.0.0/16   | EFOREX-AS - E-FOREX, US
>> 10512   | 107.14.0.0/16   | EFOREX-AS - E-FOREX, US
>> 10512   | 107.15.0.0/16   | EFOREX-AS - E-FOREX, US
>> 10512   | 14.5.0.0/16 | EFOREX-AS - E-FOREX, US
>> 10512   | 147.17.0.0/16   | EFOREX-AS - E-FOREX, US
>> 10512   | 180.237.0.0/16  | EFOREX-AS - E-FOREX, US
>> 10512   | 42.183.0.0/16   | EFOREX-AS - E-FOREX, US
>> 10512   | 42.185.0.0/16   | EFOREX-AS - E-FOREX, US
>> 10512   | 42.186.0.0/16   | EFOREX-AS - E-FOREX, US
>> 10512   | 42.187.0.0/16   | EFOREX-AS - E-FOREX, US
>> 10512   | 42.188.0.0/16   | EFOREX-AS - E-FOREX, US
>> 10512   | 42.189.0.0/16   | EFOREX-AS - E-FOREX, US
>> 10512   | 42.190.0.0/16   | EFOREX-AS - E-FOREX, US
>> 10512   | 42.191.0.0/16   | EFOREX-AS - E-FOREX, US
>> 10512   | 42.192.0.0/16   | EFOREX-AS - E-FOREX, US
>> 10512   | 42.193.0.0/16   | EFOREX-AS - E-FOREX, US
>> 10512   | 42.194.0.0/16   | EFOREX-AS - E-FOREX, US
>> 10512   | 42.195.0.0/16   | EFOREX-AS - E-FOREX, US
>>
>> I'm going to guess they are hijacking a bunch of space and sending spam?
>> (the 42/8 space is variously telecom malaysia and china unicom)
>> the 102 space is un-allocated afrnic space... probably no good these folk
>> are up to.
>>
>>
>

Re: Console Servers & Cellular Providers

[James Milko]

 How is cell reception in multi-story data centers/carrier hotels?  Good
enough for remote management?


JM

Re: "Everyone should be deploying BCP 38! Wait, they are ...."

[James Milko]

Is using data from a self-selected group even meaningful when
extrapolated?  It's been a while since Stats in college, and it's very
likely the guys from MIT know more than I do, but one of the big things
they pushed was random sampling.

JM


On Tue, Feb 18, 2014 at 2:11 PM, Larry Sheldon  wrote:

> On 2/18/2014 11:20 AM, Jay Ashworth wrote:
>
>> Here's a piece which uses the MIT ANA data to assert that the job is
>> mostly done already.
>>
>> Unless I'm very much mistaken, it appears that a large percentage of
>> the failed BCP 38 spoofing tests listed in that data are actually due
>> to customer side NAT routers dropping packets...
>>
>> which is of course egress filtering rather than ingress filtering,
>> and thus doesn't actually apply to our questions.
>>
>> Am I interpreting that correctly?
>>
>
> The date seems a little past "buy by" in light of the very recent
> observations and comments here.
>
>  http://www.senki.org/everyone-should-be-deploying-bcp-38-wait-they-are/
>>
>
>
> --
> Requiescas in pace o email   Two identifying characteristics
> of System Administrators:
> Ex turpi causa non oritur actio  Infallibility, and the ability to
> learn from their mistakes.
>   (Adapted from Stephen Pinker)
>
>

Clued contact at Brighthouse

[James Milko]

Brighthouse seems to be announcing one of our prefixes.  Does anyone have a
contact for them that doesn't end up in residential support?

Thanks,
James Milko
Senior Network Engineer
www.inetwork.com
4001 Weston Parkway
Cary, NC 27513

inetwork is a division of Bandwidth

Re: Clued contact at Brighthouse

[James Milko]

Thanks to everyone who contacted us off list.  We got in touch with the
correct people over at Brighthouse and are working on it now.

Thanks,
James Milko
Senior Network Engineer
www.inetwork.com
4001 Weston Parkway
Cary, NC 27513

inetwork is a division of Bandwidth


On Tue, Feb 14, 2012 at 4:32 PM, James Milko  wrote:

> Brighthouse seems to be announcing one of our prefixes.  Does anyone have
> a contact for them that doesn't end up in residential support?
>
> Thanks,
> James Milko
> Senior Network Engineer
> www.inetwork.com
> 4001 Weston Parkway
> Cary, NC 27513
>
> inetwork is a division of Bandwidth
>

Re: Cogent - Google - HE Fun

[James Milko]

On Sun, Mar 13, 2016 at 8:32 PM, William Herrin  wrote:

> On Sun, Mar 13, 2016 at 5:25 PM, Doug Barton  wrote:
> > No one who is serious about IPv6 is single-homed to Cogent. Arguably, no
> one
> > who is serious about "The Internet" is single-homed on either protocol.
>
> At the very least, no one who is clueful about "The Internet" is
> single-homed to Cogent with any protocol.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Owner, Dirtside Systems . Web: 
>

s/single-homed/dual-homed/

It's not like losing Google/HE because your other transit dropped is
acceptable.

JM

Re: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 hours

[James Milko]

On Mon, Jul 20, 2015 at 3:40 PM, ML  wrote:

> On 7/20/2015 2:57 PM, valdis.kletni...@vt.edu wrote:
>
>> On Mon, 20 Jul 2015 19:42:39 +0100, Colin Johnston said:
>>
>>> see below for china ranges I believe, ipv4 and ipv6
>>>
>> You may believe... but are you *sure*?  (Over the years, we've seen
>> *lots* of "block China" lists that accidentally block chunks allocated
>> to Taiwan or Australia or other Pacific Rim destinations).
>>
>>
> If you really wanted to go the route of blocking all/almost all China.
> Isn't there a short list of ASNs that provide transit to China
> citizens/networks?
> I'm referring to AS4134, AS4837, etc
> Wouldn't blackholing any prefix with those ASNs in the AS path accomplish
> the goal and stay up to date with a new prefixes originated from China?
>
>
That would prevent you from responding to their traffic (assuming DFZ),
 but their traffic would still have a valid route to your network.

JM