AS45102(Alibaba) Contact

2020-09-23 Thread Pascal Masha
Hello,

We are experiencing a routing issue towards AS45102, any engineer available
on this list to help resolve. Please contact me offline. Emails to their
noc have gone unanswered.


Linux WiFi Package Issues

2021-10-12 Thread Pascal Masha
Hello All,

I have been wondering whether there is any known issue with the Linux WiFi
package since the last 3 days or so? I'm Ubuntu 20.04.3 LTS 64bit Distro
and WiFi has been dropping almost every 5 minutes. A colleague on another
Linux Disto also contacted me about the same thing. Has anyone in the
community experienced the same issue?

Regards
Paschal Masha


Geo-location - IP Location Websites

2021-10-20 Thread Pascal Masha
Dear All,

If you are running a website that provides IP Location data; it's only fair
that you be updating your data fast enough (not more than a month) and poll
the correct information provided by the respective RIRs and more especially
if other services rely on your data to lock services.

Apart from that, how do you all get them to quickly change their records
especially for a block that you recovered from one country and moved to
another within the same RIR region/continent?

Regards,
Paschal Masha.


AKAMAI CDN

2023-01-12 Thread Pascal Masha
Hello,

Anyone from Akamai responsible for making decisions on cluster
scaling /refresh here?

Kindly contact me offlist.

Regards

Paschal Masha


Re: Coherent 100G in QSFP28

2023-02-28 Thread Pascal Masha
How much will these cost?

On Tue, Feb 21, 2023 at 5:58 PM Mark Tinka  wrote:

>
>
> On 2/13/23 16:47, Tarko Tikan wrote:
>
> > To the best of my knowledge the actual products are like ~1y away.
>
> Yes - if you are keen, reach out to your Adva (Adtran now, really) AM to
> get some beta units for testing; but FCS is Q2'24.
>
> Getting our hands on some to see how they perform. Won't replace
> longhaul DWDM applications, but can be very handy in the 1km - 120km
> metro range.
>
> Mark.
>


Flowspec Implementation on Cisco ASR

2023-05-24 Thread Pascal Masha
Hi Folks,

Has anyone implemented flowspec on Cisco ASR terminating PPPoE users.
Flowspec rules should apply to the addresses assigned to PPPoE customers.
If yes, kindly share configuration samples..


Regards

Paschal Masha


MX204 Virtual Chassis Setup

2023-08-21 Thread Pascal Masha
Hello,

Does the MX204 support virtual chassis setup?

Regards,
Paschal Masha


IP Planning and Modelling Tools

2023-08-22 Thread Pascal Masha
Hello Folks,

Any good alternatives to Ciena Blue Planet out there?

Regards,
Paschal Masha


Re: MX204 Virtual Chassis Setup

2023-08-22 Thread Pascal Masha
Thanks just wanted to know whether it was a supported feature.

On Tue, 22 Aug 2023, 21:00 Chris,  wrote:

> No, but they do however work just great as an active-active pair of
> routers when cross linked and iBGP peered to each other and everything
> downstream connected to each one.
>
> Chris
>
> On Mon, Aug 21, 2023 at 9:43 AM Pascal Masha 
> wrote:
>
>> Hello,
>>
>> Does the MX204 support virtual chassis setup?
>>
>> Regards,
>> Paschal Masha
>>
>


Re: MX204 Virtual Chassis Setup

2023-08-28 Thread Pascal Masha
Sounds more like a Huawei roadmap oops, didn't mean to mention names :)

On Sun, 27 Aug 2023, 07:02 Mark Tinka,  wrote:

>
>
> On 8/27/23 04:52, Eric Kuhnke wrote:
>
> > I sincerely doubt there is much demand for *new* 40G these days.
> >
> > Look at the population of 40G members on major IXes.
> >
> > People have either one 10G, 2 x 10G, or 100G.
> >
> > 40G was a dead-end 9 years ago and much so more now.
>
> We have customers that sometimes ask for 40Gbps interconnects. I always
> tell our Pre-Sales team that those are the ones who "led the way", back
> in the day. Sadly, they were a bit too early :-).
>
> Mark.
>


Google Contact

2023-09-14 Thread Pascal Masha
Hello Folks,

Anyone from Google who can assist setup BGP peering through SFMIX IX,
kindly contact me off list.

Thanks
Regards

Paschal Masha


Re: Google Contact

2023-09-14 Thread Pascal Masha
Thank Robert!

This is the way.

On Thu, Sep 14, 2023 at 9:11 PM Robert Story  wrote:

> On Thu 2023-09-14 19:33:42+0300 Pascal wrote:
> > Anyone from Google who can assist setup BGP peering through SFMIX IX,
> > kindly contact me off list.
>
> I have contacts at google, and when I asked a similar question
> earlier this year I was refereed to their peering page:
>
>https://peering.google.com/#/options/peering
>
> As I recall, it took us about 2 weeks.
>
> Regards,
> Robert
>
> --
> USC Information Sciences Institute 
> Networking and Cybersecurity Division
>


Re: Google Contact

2023-09-14 Thread Pascal Masha
More of receiving specifics via ISP that I don't wish to drop/filter
compared to aggregates via the router servers.

On Thu, Sep 14, 2023 at 9:22 PM TJ Trout  wrote:

> Having trouble using the route servers?
>
> On Thu, Sep 14, 2023, 9:37 AM Pascal Masha  wrote:
>
>> Hello Folks,
>>
>> Anyone from Google who can assist setup BGP peering through SFMIX IX,
>> kindly contact me off list.
>>
>> Thanks
>> Regards
>>
>> Paschal Masha
>>
>


Re: AFRINIC placed in receivership

2023-09-15 Thread Pascal Masha
AFRINIC has the right to reclaim those resources should it prove that usage
of such is not in any way beneficial to the continent in which it's
mandated to operate and support.
We will not defend CI or Lu Heng for persisting in this, we the members
felt it's a blackmail and the action taken by AFRNIC was in good faith.
Anyone supporting such actions as those taken by CI and its sympathizers is
against democracy and fair utilization/usage of global number resources and
by extension; I dare say, not a Mandolorian. This is the way!

On Sat, Sep 16, 2023 at 2:20 AM Delong.com via NANOG 
wrote:

>
>
> On Sep 15, 2023, at 15:05, Eric Kuhnke  wrote:
>
> A much better explanation of the situation can be found at:
>
> https://www.theregister.com/2023/07/03/nrs_afrinic_review/
>
> I also recommend that everyone who is not yet familiar with the issue
> google Lu Heng and Cloud Innovations, the Hong Kong based corporate entity
> in question which caused this.
>
>
> Fair suggestion, but I wouldn’t say it’s fair to say Lu Heng or CI caused
> this. I’d say that AFRINIC’s
> leadership at the time had an at least equal role in creating the problems
> and in failing to address
> Them in a timely manner.
>
> CI didn’t sue AFRINIC for nothing. AFRINIC, in violation of the actual
> text of their bylaws attempted
> to revoke CI space and created major disruptions to a number of networks
> in the process. Had CI
> not received the injunctions they got from the courts, likely the
> disruption would have been much
> worse and caused some pretty wide-spread outages.
>
>
> https://www.google.com/search?client=firefox-b-d&q=lu+heng+cloud+innovation
>
> The short version of this is that a HK based corporate entity claims it is
> the legitimate "owner" of 7 million AFRINIC IPs.
>
>
> AFRINIC legitimately issued those (closer to 6M) IP addresses to Cloud
> Innovation based on justifications submitted. AFRINIC then attempted, using
> claims that usage out of region is not permitted by the bylaws
> (It is not prohibited by the bylaws, feel free to read them yourself), to
> reclaim those addresses.
>
> AFRINIC whois and the courts have confirmed that Cloud Innovation is the
> rightful registrant of those
> addresses at the time and as of now. Until a court rules otherwise (which
> is very unlikely at this point),
> they don’t “own” the addresses, but they do “own” the rights to those
> registrations in the AFRINIC
> database.
>
> (Nobody “owns” any integers… Everyone remains equally free to use the
> number 5 as much as they want.)
>
> Owen
>
>
>
>
>
>
> On Thu, Sep 14, 2023 at 6:09 AM Bryan Fields 
> wrote:
>
>> On 9/13/23 9:27 PM, Bryan Fields wrote:
>> > I think this qualifies as potentially operational.
>> >
>> > Afrinic placed in receivership, board elections to be held in six
>> months:
>> > https://archive.ph/jOFE4
>>
>> Looks like archive.ph is having problems.  This is the original article.
>>
>> >
>> https://www.capacitymedia.com/article/2c6pnx4ymt7sd5c493wg0/news/exclusive-afrinic-placed-in-receivership-board-elections-to-be-held-in-six-months
>> --
>> Bryan Fields
>>
>> 727-409-1194 - Voice
>> http://bryanfields.net
>>
>
>


Re: AFRINIC placed in receivership

2023-09-16 Thread Pascal Masha
NO Owen, we can't have a single rogue member bring a whole entity that is
mandated with an important task for the continent to a stand still just
because they can twist the law and quote bylaws or manipulate processes.

This is WRONG and shall remain to be so no matter how repeated and
"fancily" satinize it with a good read of the mandalorians ways of life.

LET AFRINIC BE, and not undermine it's operations or the intelligence of
the other members who need it's services.

On Sat, Sep 16, 2023 at 11:59 AM Owen DeLong  wrote:

> No, Pascal, you are simply wrong here. AFRINIC has the right to reclaim
> the resources in the event of an actual violation of the RSA or by
> incorporation the AFRINIC bylaws or the policies passed by the community.
>
> Afrinic knew full well that the bylaws and policy don’t prohibit out of
> region usage. They brought this fact before the community and practically
> begged the community to develop policy to prohibit it. The community
> rejected that idea pretty soundly. As a result, the bylaws and policy still
> do not prohibit out of region usage.
>
> Given that the board knew that the policies and the bylaws were not
> actually being violated, their actions were not in good faith and the court
> has ruled accordingly.
>
> It is your attitude of “the law says what we want to pretend it says”
> which is perfectly in line with the board which is anti-democracy.
> Democracy says that even if you don’t like the law, you follow it until you
> can convince enough of your fellow citizens to change it. I freely admit I
> am not a Mandalorian and I have no desire to be a Mandalorian. I don’t
> particularly like wearing helmets or masks and I enjoy communal meals.
> Further, Mandalorians are NOT a democracy. More like a theocracy. That is
> their way. Perhaps you should study some of these things before you attempt
> to speak authoritatively about them, for here you have clearly expressed
> your ignorance about democracy, the rule of law, and the way of the
> Mandalorians.
>
> These are the facts.
>
> Owen
>
>
> On Sep 15, 2023, at 23:12, Pascal Masha  wrote:
>
> AFRINIC has the right to reclaim those resources should it prove that
> usage of such is not in any way beneficial to the continent in which it's
> mandated to operate and support.
> We will not defend CI or Lu Heng for persisting in this, we the members
> felt it's a blackmail and the action taken by AFRNIC was in good faith.
> Anyone supporting such actions as those taken by CI and its sympathizers is
> against democracy and fair utilization/usage of global number resources and
> by extension; I dare say, not a Mandolorian. This is the way!
>
> On Sat, Sep 16, 2023 at 2:20 AM Delong.com via NANOG 
> wrote:
>
>>
>>
>> On Sep 15, 2023, at 15:05, Eric Kuhnke  wrote:
>>
>> A much better explanation of the situation can be found at:
>>
>> https://www.theregister.com/2023/07/03/nrs_afrinic_review/
>>
>> I also recommend that everyone who is not yet familiar with the issue
>> google Lu Heng and Cloud Innovations, the Hong Kong based corporate entity
>> in question which caused this.
>>
>>
>> Fair suggestion, but I wouldn’t say it’s fair to say Lu Heng or CI caused
>> this. I’d say that AFRINIC’s
>> leadership at the time had an at least equal role in creating the
>> problems and in failing to address
>> Them in a timely manner.
>>
>> CI didn’t sue AFRINIC for nothing. AFRINIC, in violation of the actual
>> text of their bylaws attempted
>> to revoke CI space and created major disruptions to a number of networks
>> in the process. Had CI
>> not received the injunctions they got from the courts, likely the
>> disruption would have been much
>> worse and caused some pretty wide-spread outages.
>>
>>
>>
>> https://www.google.com/search?client=firefox-b-d&q=lu+heng+cloud+innovation
>>
>> The short version of this is that a HK based corporate entity claims it
>> is the legitimate "owner" of 7 million AFRINIC IPs.
>>
>>
>> AFRINIC legitimately issued those (closer to 6M) IP addresses to Cloud
>> Innovation based on justifications submitted. AFRINIC then attempted, using
>> claims that usage out of region is not permitted by the bylaws
>> (It is not prohibited by the bylaws, feel free to read them yourself), to
>> reclaim those addresses.
>>
>> AFRINIC whois and the courts have confirmed that Cloud Innovation is the
>> rightful registrant of those
>> addresses at the time and as of now. Until a court rules otherwise (which
>> is very unlikely at this point),
>> they don’t “own” the addresses,

Re: AFRINIC placed in receivership

2023-09-16 Thread Pascal Masha
My point exactly!

And it's so shameful that we have people trying to defend them by throwing
laws,bylaws, management blah blah..spoof coof attacks on AFRINIC processes.


We are not happy with the current situation and the member should be
awareness and we also noticed how rogue that member is during the election
period.




On Sat, 16 Sept 2023, 13:19 Eric Kuhnke,  wrote:

> I'm not quite sure that we agree on the meaning of "legitimate
> application" when a HK based corporate entity is using and claiming
> permanent rights to AFRINIC IP space, primarily for ISP operations in east
> asia.
>
> There have been multiple well documented instances of AFRINIC insiders
> with privileged access shoveling IP space out the back door by less than
> legitimate means. For a number of different suspicious recipients.
>
> Undoubtedly this is part of what contributed to its board members and
> management fleeing the organization in the face of litigation and
> investigations.
>
> The fact that these organizations that received IP space by less than
> honest means are now suing AFRINIC into financial oblivion honestly does
> not help the situation.
>
>
>
> On Fri, Sep 15, 2023 at 5:04 PM Delong.com  wrote:
>
>> Noe… You are conflating two completely different cases, sir.
>>
>> CI submitted legitimate applications and their addresses were issued
>> prior to Ernest’s activities.
>>
>> You’re mixing Lu Heng up with Elad Cohen.
>>
>> Owen
>>
>>
>> On Sep 15, 2023, at 16:32, Eric Kuhnke  wrote:
>>
>>
>> https://www.devdiscourse.com/article/international/1813989-the-strange-case-of-africas-stolen-ip-addresses
>>
>>
>> https://www.google.com/search?client=firefox-b-d&q=Ernest+Byaruhanga+afrinic
>>
>> On Fri, Sep 15, 2023 at 4:30 PM Eric Kuhnke 
>> wrote:
>>
>>> > AFRINIC legitimately issued those (closer to 6M) IP addresses to Cloud
>>> Innovation based on justifications submitted. AFRINIC then attempted, using
>>> claims that usage out of region is not permitted by the bylaws
>>> (It is not prohibited by the bylaws, feel free to read them yourself),
>>> to reclaim those addresses.
>>>
>>> This is not what happened. AFRINIC issued those IP addresses to Cloud
>>> Innovations based on fundamental misrepresentations by the applicant and
>>> internal fraudulent activity conducted by a single employee within AFRINIC.
>>>
>>>
>>>
>>> On Fri, Sep 15, 2023 at 4:17 PM Delong.com  wrote:
>>>


 On Sep 15, 2023, at 15:05, Eric Kuhnke  wrote:

 A much better explanation of the situation can be found at:

 https://www.theregister.com/2023/07/03/nrs_afrinic_review/

 I also recommend that everyone who is not yet familiar with the issue
 google Lu Heng and Cloud Innovations, the Hong Kong based corporate entity
 in question which caused this.


 Fair suggestion, but I wouldn’t say it’s fair to say Lu Heng or CI
 caused this. I’d say that AFRINIC’s
 leadership at the time had an at least equal role in creating the
 problems and in failing to address
 Them in a timely manner.

 CI didn’t sue AFRINIC for nothing. AFRINIC, in violation of the actual
 text of their bylaws attempted
 to revoke CI space and created major disruptions to a number of
 networks in the process. Had CI
 not received the injunctions they got from the courts, likely the
 disruption would have been much
 worse and caused some pretty wide-spread outages.



 https://www.google.com/search?client=firefox-b-d&q=lu+heng+cloud+innovation

 The short version of this is that a HK based corporate entity claims it
 is the legitimate "owner" of 7 million AFRINIC IPs.


 AFRINIC legitimately issued those (closer to 6M) IP addresses to Cloud
 Innovation based on justifications submitted. AFRINIC then attempted, using
 claims that usage out of region is not permitted by the bylaws
 (It is not prohibited by the bylaws, feel free to read them yourself),
 to reclaim those addresses.

 AFRINIC whois and the courts have confirmed that Cloud Innovation is
 the rightful registrant of those
 addresses at the time and as of now. Until a court rules otherwise
 (which is very unlikely at this point),
 they don’t “own” the addresses, but they do “own” the rights to those
 registrations in the AFRINIC
 database.

 (Nobody “owns” any integers… Everyone remains equally free to use the
 number 5 as much as they want.)

 Owen






 On Thu, Sep 14, 2023 at 6:09 AM Bryan Fields 
 wrote:

> On 9/13/23 9:27 PM, Bryan Fields wrote:
> > I think this qualifies as potentially operational.
> >
> > Afrinic placed in receivership, board elections to be held in six
> months:
> > https://archive.ph/jOFE4
>
> Looks like archive.ph is having problems.  This is the original
> article.
>
> >
> https://www.capacitymedia.com/article

Contact from Apple Cache for ISP

2024-03-05 Thread Pascal Masha
Hello,

Looking for contacts for anyone from Apple who can assist with subject
request.

Regards,
Pascal


Re: Contact from Apple Cache for ISP

2024-03-06 Thread Pascal Masha
Cool, wanted to follow up on request I already submitted.

On Wed, 6 Mar 2024, 17:52 Eric Dugas,  wrote:

> You can submit your request here: https://cache.edge.apple/inquire
>
> On Wed, Mar 6, 2024 at 8:54 AM Aaron1  wrote:
>
>> peering-...@group.apple.com
>>
>> I think it’s AEC (Apple Edge Caching). This might get you closer to
>> speaking with someone in that group.
>>
>> Aaron
>>
>> > On Mar 6, 2024, at 1:46 AM, Pascal Masha  wrote:
>> >
>> > Hello,
>> >
>> > Looking for contacts for anyone from Apple who can assist with subject
>> request.
>> >
>> > Regards,
>> > Pascal
>>
>>


Best TAC Services from Equipment Vendors

2024-03-06 Thread Pascal Masha
Thought about it but so far I believe companies from China provide better
and fast TAC responses to their customers than the likes of Cisco and
perhaps that’s why some companies(where there are no restrictions)prefer
them for critical services.

For a short period in TAC call you can have over 10 R&D engineers and
solutions provided in a matter of hours even if it involves software
changes.. while these other companies even before you get in a call with a
TAC engineer it’s hours and when they join you hear something like “my
shift ended 15 minutes ago, hold let me look for another engineer”. WHY?
Thoughts


Re: Best TAC Services from Equipment Vendors

2024-03-06 Thread Pascal Masha
For us this has been the experience to a point where 100s of nodes( from
vendor x) had to be swapped out because no one had the patience anymore…

On Wed, 6 Mar 2024 at 21:29,  wrote:

> Interesting, this has never been my experience even with Cisco or Juniper,
> have always been able to escalate quickly to engineering. I wonder if it
> was related to the size of my accounts.
>
> Shane
>
> > On Mar 6, 2024, at 1:27 PM, Pascal Masha  wrote:
> >
> > Thought about it but so far I believe companies from China provide
> better and fast TAC responses to their customers than the likes of Cisco
> and perhaps that’s why some companies(where there are no
> restrictions)prefer them for critical services.
> >
> > For a short period in TAC call you can have over 10 R&D engineers and
> solutions provided in a matter of hours even if it involves software
> changes.. while these other companies even before you get in a call with a
> TAC engineer it’s hours and when they join you hear something like “my
> shift ended 15 minutes ago, hold let me look for another engineer”. WHY?
> Thoughts
>


Re: Best TAC Services from Equipment Vendors

2024-03-07 Thread Pascal Masha
With all honesty, if you ask me, my experience with most companies from
China-in relation to Support- has always been fast and super satisfactory
no matter the raised case or sensitivity of the impact to users. I have
always felt comfortable running their gear and gives some sort of
confidence in not having prolonged outages no matter the reasons( engineer
inexperienced, not knowledgeable)

On Thu, 7 Mar 2024 at 09:49, Saku Ytti  wrote:

> On Wed, 6 Mar 2024 at 22:57, michael brooks - ESC
>  wrote:
>
> > Funny you should mention this now, we were just discussing (more like
> lamenting...) if support is a dying industry. It seems as though vendor
> budgets are shrinking to the point they only have a Sales/Pre-Sales
> department, and from Day Two on you are on your own. Dramatic take of
> course, but if we are speaking in trajectories
>
> My personal experience extending in three different decades is that
> there is no meaningful change in support quality or amount of issues
> encountered.
>
> Support quality has always been very modest, unless you specifically
> pay to have access to named engineers. And this is not because quality
> of the engineers changes, this is because vast majority of support
> cases are useless cases, and to handle this massive volume support
> tries to assume which support cases are legitimate problems, which are
> PEBKAC and in which cases the user already solved their problem by the
> time you read their ticket and will never respond back. The last case
> is so common that every first-line adopts the strategy of 'pinging'
> you, regardless how good and clear information you provide, they ask
> some soft-ball question, to see if you're still engaged.
> Having a named engineer changes this process, because the engineer
> will quickly learn that you don't open useless cases, that the issue
> you're having is legitimate, and will actually read the ticket and
> think about the problem.
>
> To me this seems an inevitable outcome, if your product is popular,
> most of its users are users who don't do their homework and do not
> respect the support line's time, which ends up being a disservice to
> the whole ecosystem, because legitimate problems will take longer to
> fix, or in case of open source software, authors just burn out and
> kill the project.
>
> What shocks me more than the low quality support is the low quality
> software, decades pass along, and everyone still is having
> show-stopper level of issues in basic functions on a regular basis,
> the software quality is absolutely abysmal. I fear low software
> quality is organically market-driven, no one is trying to make poor
> NOS, it's just market incentives drive poor quality NOS. When no one
> has high quality NOS, there is no reason to develop one, because most
> of your revenue is support contracts, not hardware sales, and if the
> NOS wouldn't be out-right broken needing to be recompiled regularly to
> get basic things working, lot of users might stop buying support,
> because they don't need the hand-holding part of it, they just need
> working software.
> This is not something that vendors actively drive, I'm sure most
> companies believe they are making an honest attempt to improve
> quality, but it is visible in where investments are put. One vendor
> had a very promising project to take a holistic look into their NOS
> quality issue, by senior subject matter experts, this project was
> killed (I'm sure funding was needed somewhere with better returns),
> and the responsible senior person went to Amazon instead.
>
>
>
> >
> >
> >
> >
> > michael brooks
> > Sr. Network Engineer
> > Adams 12 Five Star Schools
> > michael.bro...@adams12.org
> > 
> > "flying is learning how to throw yourself at the ground and miss"
> >
> >
> >
> > On Wed, Mar 6, 2024 at 11:25 AM Pascal Masha 
> wrote:
> >>
> >> Thought about it but so far I believe companies from China provide
> better and fast TAC responses to their customers than the likes of Cisco
> and perhaps that’s why some companies(where there are no
> restrictions)prefer them for critical services.
> >>
> >> For a short period in TAC call you can have over 10 R&D engineers and
> solutions provided in a matter of hours even if it involves software
> changes.. while these other companies even before you get in a call with a
> TAC engineer it’s hours and when they join you hear something like “my
> shift ended 15 minutes ago, hold let me look for another engineer”. WHY?
> Thoughts
> >
> >
> > This is a staff email account managed by Adams 12 Five Star Schools.
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the sender.
>
>
>
> --
>   ++ytti
>


Re: Best TAC Services from Equipment Vendors

2024-03-14 Thread Pascal Masha
The only issue,that I have experienced, with Nokia TAC is throwing stuff
from team to team and before you get things done, each team has blamed the
other team.

On Thu, 14 Mar 2024 at 01:43, scott via NANOG  wrote:

>
>
> In light of this thread's contents, I have to give a shout out to Nokia
> TAC.  Maybe because we buy a lotta stuff and have a lotta maint
> contracts, but they don't do things like what has been mentioned.  Of
> course, I see some stuff from Level 1 folks where I think 'whaaat???'
> but they haven't done anything like what I have heard on this thread in
> the past 5 years I have been using them.  Even for 'informational'
> tickets they respond quickly.
>
> scott
>


Re: Snapchat CDN/network contact

2024-03-21 Thread Pascal Masha
Hi,
Did anyone reach out? Looking to discuss the Snapchat CDN share contact in
case they did reach out to yo.

On Thu, 21 Mar 2024 at 01:26, Clinton Work  wrote:

> I'm looking for a Snapchat CDN/network contact to discuss some non-optimal
> traffic delivery into our network.  I couldn't find a peerindb entry for
> their AS395291.
>
> --
> Clinton Work
>


All crickets at HE

2024-03-24 Thread Pascal Masha
Seems like the good folks at noc@he are no longer responding to emails!! Is
anyone else on the list experiencing this?

Regards,
Paschal Masha


Re: All crickets at HE

2024-03-25 Thread Pascal Masha
Someone nice from HE reached out and got sorted. NOC is usually very fast
at responding to incidents. Got me worried when this took days without a
response!

On Mon, 25 Mar 2024 at 21:35, Dominik Dobrowolski <
dobrowolski.dom...@gmail.com> wrote:

> In my experience HE noc was always exemplary when it comes to response
> time.
>
> Kind Regards,
> Dominik Dobrowolski
>
> W dniu pon., 25.03.2024 o 04:59 Pascal Masha 
> napisał(a):
>
>> Seems like the good folks at noc@he are no longer responding to emails!!
>> Is anyone else on the list experiencing this?
>>
>> Regards,
>> Paschal Masha
>>
>


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

2024-03-26 Thread Pascal Masha
Interested in responses to this as well. Perhaps something informative that
I can also adopt for zero $$ would be amazing. In case you do get pointers
off-list kindly share- we can walk the journey together and compare notes :)

On Wed, 27 Mar 2024 at 03:06, 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
>
>


Free(opensource) Ticketing solutions

2024-05-27 Thread Pascal Masha
Hello,

Which free and good ticketing systems do you folks(for those who do) use?

Regards,
Paschal Masha


Re: Switch/Router

2017-12-14 Thread Pascal Masha
Hi,

Perhaps you could also checkout the HP A5800-24G-SFP, it's an SFP type
switch pretty good, the only downside,  however, is that it has a
weird limitation on the number of received BGP routes - but with some
tweaking you can hack it. They can also do a cluster setup through an
IRF port, has a expansion slot for an extra 6x10gig module.

This link 
https://www.cnet.com/products/hp-a5800-48g-switch-switch-48-ports-managed-series/specs/
shows another  related model, the only difference is that it has
electrical gig ports.


Regards,

Paschal Masha.

On Wed, Dec 13, 2017 at 1:11 AM, Baldur Norddahl
 wrote:
> The ZTE 5928 has 24x 1G and 4x 10G. It has dual PSU with options for both
> AC and DC power. It will do BGP, MPLS etc with about 30.000 routes. Price
> is approximately 2k USD.
>
> If you need more 10G ports there is the ZTE 5960 with 24x 10G plus 2x 40G
> at approximately twice the price.
>
> Also take a peek at the switches at fs.com.
>
>
> Den 12. dec. 2017 15.48 skrev "K MEKKAOUI" :
>
> Hi
>
>
>
> I am looking for a router preferably (or switch) with the following specs:
>
> 1-  Carrier grade
>
> 2-  Dual power supply
>
> 3-  1RU
>
> 4-  Gig and 10Gig interfaces.
>
> 5-  Does support protocols like BGP, etc.
>
>
>
> Any recommendation please? Your help will be appreciated.
>
>
>
> Thank you
>
>
>
> KARIM M.
>
> MEKTEL INC.
>
> Tél. : 1(855) 563-5835 poste 404
>
> www.mektel.ca