Re: Cogent BGP session more than 1 router ipv6

2024-06-12 Thread Andrew Hoyos
We’ve had success with multiple VLAN tagged handoffs/BGP sessions w/ Cogent 
with various customers of ours in similar scenarios.
Perhaps you can ask for multiple VLANs each with a /31 + /127 + BGP sessions.


> On Jun 11, 2024, at 07:35, Justin Wilson (Lists)  wrote:
> 
> We were able to get a /28 from cogent for peering on ipv4.   I believe we are 
> paying for this, but our rep is not getting the concept of it in ipv6.  He 
> says he can only order a /127 or /48.   I don’t mind paying.  I
> 
> Justin Wilson
> j...@mtin.net
> 
> —
> https://j2sw.com (AS399332)
> https://blog.j2sw.com - Podcast and Blog
> 
>> On Jun 10, 2024, at 5:47 PM, Peter Potvin 
>>  wrote:
>> 
>> Cogent stopped offering anything larger than a /31 IPv4 and /127 IPv6 on new 
>> DIA circuits earlier this year, when previously they provided a /29 IPv4 and 
>> /112 IPv6 without issue at no additional cost. Now they expect you to pay 
>> additional for this functionality, including for redundant sessions. 
>> Unfortunately I have not heard of any success stories for people getting 
>> around this as of yet. YMMV
>> 
>> Kind regards,
>> Peter Potvin
>> 
>> 
>> On Mon, Jun 10, 2024 at 17:43 Justin Wilson (Lists) > > wrote:
>>> I am trying to get our Cogent rep to give us a /124 to peer on a Cogent 
>>> circuit with.  We have multipl routers we want to peer to a cogent transit 
>>> circuit with.on.
>>> 
>>> Does anyone have the magic words or a circuit ID example you are doing 
>>> multiple BGP conenctions on a single circuit?
>>> 
>>> 
>>> 
>>> Justin Wilson
>>> j...@mtin.net 
>>> 
>>> —
>>> https://j2sw.com  (AS399332)
>>> https://blog.j2sw.com  - Podcast and Blog
>>> 
> 



Re: Open source Netflow analysis for monitoring AS-to-AS traffic

2024-03-26 Thread Andrew Hoyos
Brian,

Take a peek at Akvorado - https://github.com/akvorado/akvorado
We recently set up a lab instance, and seems to check the boxes below.

> On Mar 26, 2024, at 19:04, Brian Knight via NANOG  wrote:
> 
> What's presently the most commonly used open source toolset for monitoring 
> AS-to-AS traffic?
> 
> I want to see with which ASes I am exchanging the most traffic across my 
> transits and IX links. I want to look for opportunities to peer so I can 
> better sell expansion of peering to upper management.
>  
> Our routers are mostly $VENDOR_C_XR so Netflow support is key.
> 
> In the past, I've used AS-Stats  
> for this purpose. However, it is particularly CPU and disk IO intensive. 
> Also, it has not been actively maintained since 2017.
> 
> InfluxDB wants to sell me 
>  on Telegraf + 
> InfluxDB + Chronograf + Kapacitor, but I can't find any clear guide on what 
> hardware I would need for that, never mind how to set up the software. It 
> does appear to have an open source option, however.
>  
> pmacct seems to be good at gathering Netflow, but doesn't seem to analyze 
> data. I don't see any concise howto guides for setting this up for my 
> purpose, however.
>  
> I'm aware Kentik does this very well, but I have no budget at the moment, my 
> testing window is longer than the 30 day trial, and we are not prepared to 
> share our Netflow data with a third party.
>  
> Elastiflow  appears to have been open source 
>  at one time in 
> the past, but no longer. Since it too appears to be hosted, I have the same 
> objections as I do with Kentik above.
>  
> On-list and off-list replies are welcome.
>  
> Thanks,
>  
> -Brian
>  



Re: Networks ignoring prepends?

2024-01-23 Thread Andrew Hoyos

On Jan 22, 2024, at 14:35, William Herrin  wrote:
> 
> The best path to me from Centurylink is: 3356 1299 20473 11875
> 
> The path Centurylink chose is: 3356 47787 47787 47787 47787 53356
> 11875 11875 11875
> 
> Do you want to tell me again how that's a reasonable path selection,
> or how I'm supposed to pass communities to either 20473 or 53356 which
> tell 3356 to behave itself?

This certainly seems like a reasonable path selection, in the context that 
47787 is likely a 3356 customer.

AS53356 (Free Range Cloud Hosting) appears to have some limited BGP communities 
that may help.

https://docs.freerangecloud.com/en/bgp/communities

implies that you sending 53356:19014 would block announcements to 47787.
That may turn into a game of whack a mole, but the knobs appear to be there to 
try something other than prepending to influence 3356’s selection.

—
Andrew Hoyos
hoy...@gmail.com <mailto:hoy...@gmail.com>



Re: mulcast assignments

2012-05-04 Thread Andrew Hoyos
On May 3, 2012, at 12:24 PM, Philip Lavine wrote:

How do I get a registered multicast block?


If you truly need a globally unique multicast block, and GLOP/RFC6034/SSM won't 
work, you can submit an application to IANA here:

http://www.iana.org/form/multicast-ipv4

--
Andrew Hoyos
hoy...@gmail.com






Re: Alaska IXP?

2010-03-04 Thread Andrew Hoyos

On 3/4/10 8:57 AM, Jay Hanke jha...@myclearwave.net wrote:
snip

 We've seen the same issues in Minnesota. Locally referred to as the Chicago
 Problem. Adding on to point 3, there is also a lack of neutral facilities
 with a sufficient amount of traffic to justify the next carrier connecting.
 In rural areas many times the two ISPs that provide services are enemies at
 the business level. A couple of us have started to talk about starting an
 exchange point. With transit being so cheap it is sometimes difficult to
 justify paying for the x-connects for a small piece of the routing table.

 Have you considered starting your own exchange point with some of the local
 players? Just having the connectivity in place may help with DR situations
 in addition to all of the benefits of an exchange point.

Any interest by other anchor tenants in the area, such as the higher
education facilities? In Madison, we have MadIX[1], an exchange point hosted
by the University of Wisconsin-Madison, with a presence in one of the
neutral carrier hotels in Madison.

That eliminates the carrier to carrier issues you run into in the smaller
cities, also helps with the Chicago Problem which we are very familiar
with here as well.

[1] http://kb.wisc.edu/ns/page.php?id=6636

Andrew