Tue, May 24, 2016 at 12:39:03PM +, Nevin Gonsalves wrote:
> I just had to sit and trace all the cables to make sure the tx/rx
> lined up for the right circuits as well as hitting the right patch
> panel ports. Once all that got aligned nicely things started working
> magically.
Yep, ports in a
On 25/May/16 00:14, Eric Kuhnke wrote:
> Or a very reckless oversubscription ratio and misjudgment of the customer,
> example, if a provider had 2 x 100GbE capacity between two locations and
> sold a customer a 100GbE EoMPLS transport circuit from A to Z, based on the
> mistaken idea of "Well th
Or a very reckless oversubscription ratio and misjudgment of the customer,
example, if a provider had 2 x 100GbE capacity between two locations and
sold a customer a 100GbE EoMPLS transport circuit from A to Z, based on the
mistaken idea of "Well these guys probably aren't going to peak more than
3
On 24/May/16 06:29, Rob Laidlaw wrote:
> Yes. Many vendors are using l2vpn/pseudo-wire services of one sort or
> another to provide circuits and most do not transport LACP by default.
To the OP's case, commercially, I'd find it interesting to transport a
100Gbps circuit as EoMPLS rather than E
Yes. Many vendors are using l2vpn/pseudo-wire services of one sort or
another to provide circuits and most do not transport LACP by default.
LACP uses slow-protocols address:
https://wiki.wireshark.org/LinkAggregationControlProtocol
If they are using ALU gear, they can enable this using the port
Thanks all..!
I just had to sit and trace all the cables to make sure the tx/rx lined up for
the right circuits as well as hitting the right patch panel ports. Once all
that got aligned nicely things started working magically. thanks,-nevin
On Tuesday, May 24, 2016 2:49 AM, Eygene Ryabink
Nevin, good day.
Sun, May 22, 2016 at 07:55:31PM +, Nevin Gonsalves via NANOG wrote:
> Hoping someone may have come across a similar issue. Has anyone ever
> seen a situation where maybe like a Level3 transport system could be
> possibly dropping LACP frames..?
> End point A - tx and rx count
On 24/May/16 08:51, Jared Mauch wrote:
> I’ve seen optical transport gear be non-transparent in a few situations when
> using OTU2 vs OTU2e, but they turned out to be a bug.
I've seen this as well, including in an SDH transport, where OSPF
packets were being eaten (something Multicast-related)
> On May 24, 2016, at 12:06 AM, Colton Conor wrote:
>
> What is performing the LACP? The Level3 transport system for the most part
> is purley optical, so I don't think it touches LACP. Did you check the hash
> values?
I’ve seen optical transport gear be non-transparent in a few situations when
What is performing the LACP? The Level3 transport system for the most part
is purley optical, so I don't think it touches LACP. Did you check the hash
values?
On Sun, May 22, 2016 at 2:55 PM, Nevin Gonsalves via NANOG
wrote:
> Hi Nanog-ers,
> Hoping someone may have come across a similar issue.
Hi Nanog-ers,
Hoping someone may have come across a similar issue. Has anyone ever seen a
situation where maybe like a Level3 transport system could be possibly dropping
LACP frames..?
End point A - tx and rx counts incrementing for LACP
LACP info: Role System System
11 matches
Mail list logo