Some of their routers in Houston are blocking random flows for us since
Friday. Support has been contacted and they claim nothing is wrong. It is
still broken today.
On Wed, Oct 14, 2020 at 10:38 AM Mike Hammett wrote:
> Are any legitimate beefs with Cogent limited to their IP policies, BGP
>
On 10/15/20 6:15 PM, Robert Blayzor wrote:
On 10/14/20 1:56 PM, Shawn L via NANOG wrote:
When I last spoke to them, it sounded like they were using a bunch of
LAG groups based on ip address because they _really_ wanted to know how
many ip addresses we had and what kind of traffic we would be
On 10/14/20 1:56 PM, Shawn L via NANOG wrote:
> When I last spoke to them, it sounded like they were using a bunch of
> LAG groups based on ip address because they _really_ wanted to know how
> many ip addresses we had and what kind of traffic we would be expecting
> (eyeball networks, big data
On Thu, 15 Oct 2020 at 17:49, Ryan Hamel wrote:
> > So you're dropping in every edge all UDP packets towards these three ports?
> > Your customers may not appreciate.
> You must not be familiar with JUNOS' ACL handling. This would be applied to
> interface lo0, which is specifically for
> Do you want your martini emulated backbone link to fail when operator
> reroutes their own LSR-LSR link failure?
As I said, it's an acceptable loss for my employers network, as we have a BGP
failover mechanism in place that works perfectly.
> So you're dropping in every edge all UDP packets
On Thu, 15 Oct 2020 at 10:28, Ryan Hamel wrote:
> My experience with multiple carriers is that reroutes happen in under a
> minute but rarely happen, I also have redundant backup circuits to another
> datacenter, so no traffic is truly lost. If an outage lasts longer than 5
> minutes, or it's
Saku,
My experience with multiple carriers is that reroutes happen in under a minute
but rarely happen, I also have redundant backup circuits to another datacenter,
so no traffic is truly lost. If an outage lasts longer than 5 minutes, or it's
flapping very frequently, then I call the carrier.
On Thu, 15 Oct 2020 at 09:11, Ryan Hamel wrote:
Yep. Make sure you run BFD with your peering protocols, to catch outages
> very quickly.
>
Make sure you get higher availability with BFD than without it, it is easy
to get this wrong and end up losing availability.
First issue is that BFD has
)
>
>
>
> From: "Mike Hammett"
> To: nanog@nanog.org
> Sent: Wednesday, October 14, 2020 12:36:39 PM
> Subject: Cogent Layer 2
>
> Are any legitimate beefs with Cogent limited to their IP policies, BGP
> session charges, and peering disputes? Meaning, would using t
On Wed, Oct 14, 2020, at 20:38, Rod Beck wrote:
> You are correct that if you have
> to carve it up into a lots of VLANs, it would be a nightmare. But
> Hibernia was a true wholesale carrier providing backbone to clients,
> not links distributing traffic to lots of user end points.
The fact
Message -
From: "Mike Hammett"
To: nanog@nanog.org
Sent: Wednesday, October 14, 2020 12:36:39 PM
Subject: Cogent Layer 2
Are any legitimate beefs with Cogent limited to their IP policies, BGP session
charges, and peering disputes? Meaning, would using them for layer 2 be
On Wed, Oct 14, 2020 at 10:54:49AM -0700, Ryan Hamel wrote:
>
> One would think that with 100GE interfaces, it would not be possible to
> overrun the interface if we allowed full 10Gbps/flow, however most 100GE
> interfaces, at the chip level are broken down into 10Gbps lanes and the
>
wholesale
carrier providing backbone to clients, not links distributing traffic to lots
of user end points.
From: Ryan Hamel
Sent: Wednesday, October 14, 2020 8:34 PM
To: Rod Beck
Cc: Mike Hammett ; nanog@nanog.org
Subject: Re: Cogent Layer 2
Hibernia's
:22 PM
> To: Rod Beck
> Cc: Mike Hammett ; nanog@nanog.org
> Subject: Re: Cogent Layer 2
>
>
> All carrier Ethernet services are tunnels provided by VPLS Psuedowire or
> VXLAN services. Did you really expect a VLAN to be layer 2 switched
> everywhere?
>
> Ryan
> On
. Unfortunately, management
replaced with Switched Ethernet, which many customers distrusted because of
potential overbooking issues.
From: Ryan Hamel
Sent: Wednesday, October 14, 2020 8:22 PM
To: Rod Beck
Cc: Mike Hammett ; nanog@nanog.org
Subject: Re: Cogent Layer 2
gt; From: NANOG on
> behalf of Ryan Hamel
> Sent: Wednesday, October 14, 2020 7:54 PM
> To: Mike Hammett
> Cc: nanog@nanog.org
> Subject: Re: Cogent Layer 2
>
>
> Mike,
>
> Layer 2 is fine once it works.
> You will have to put up with whatever VLAN tags they
I always heard this service was really Layer 3 disguised as Layer 2.
From: NANOG on behalf
of Ryan Hamel
Sent: Wednesday, October 14, 2020 7:54 PM
To: Mike Hammett
Cc: nanog@nanog.org
Subject: Re: Cogent Layer 2
Mike,
Layer 2 is fine once it works
: "David Hubbard"
Sent: Wednesday, October 14, 2020 1:46pm
To: "nanog@nanog.org"
Subject: Re: Cogent Layer 2
I had a discussion with them about a point to point circuit last year and ran
into some weirdness around how burstable it would be for specific IP to IP
str
Mike,
Layer 2 is fine once it works.
You will have to put up with whatever VLAN tags they pick, if you plan on
having multiple virtual circuits on a 10G hub.
They do like to see into the flows of traffic, as they only allow up to
2Gbits/flow, per there legacy infrastructure.
If the circuit
Thus spake Mike Hammett (na...@ics-il.net) on Wed, Oct 14, 2020 at 12:36:39PM
-0500:
>
> Are any legitimate beefs with Cogent limited to their IP policies, BGP
> session charges, and peering disputes? Meaning, would using them for layer 2
> be reasonable?
Be sure to ask if your circuit will
: Wednesday, October 14, 2020 at 1:38 PM
To: "nanog@nanog.org"
Subject: Cogent Layer 2
Are any legitimate beefs with Cogent limited to their IP policies, BGP session
charges, and peering disputes? Meaning, would using them for layer 2 be
reasonable?
-
Mike Hammett
Intelligent
Are any legitimate beefs with Cogent limited to their IP policies, BGP session
charges, and peering disputes? Meaning, would using them for layer 2 be
reasonable?
-
Mike Hammett
Intelligent Computing Solutions
Midwest Internet Exchange
The Brothers WISP
22 matches
Mail list logo