Is there any data on packet duplication?

Tue Jun 23 07:03:59 UTC 2020

Am Montag, 22. Juni 2020, 23:53:44 schrieb William Herrin:
> On Mon, Jun 22, 2020 at 10:21 PM Saku Ytti <saku at ytti.fi> wrote:
> > On Tue, 23 Jun 2020 at 08:12, William Herrin <bill at herrin.us> wrote:
> > > That's what spanning tree and its compatriots are for. Otherwise,
> > > ordinary broadcast traffic (like those arp packets) would travel in a
> > > loop, flooding the network and it would just about instantly collapse
> > > when you first turned it on.
> > 
> > Metro: S1-S2-S3-S1
> > PE1: S1
> > PE2: S2
> > Customer: S3
> > STP blocking: ANY
> > 
> > S3 sends frame, it is unknown unicast flooded, S1+S2 both get it
> > (regardless of which metro port blocks), which will send it via PE to
> > Internet.
> 
> There's a link in the chain you haven't explained. The packet which
> entered at S3 has a unicast destination MAC address. That's what was
> in the arp table. If they're following the standards, only one of PE1
> and PE2 will accept packets with that destination mac address. The
> other, recognizing that the packet is not addressed to it, drops it.
> 
> Recall that ethernet worked without duplicating packets back in the
> days of hubs when all stations received all packets. This is how.
> 
> 
> That having been said, I've seen vendors creatively breach the
> boundary between L2 and L3 with some really peculiar results. AWS VPCs
> for example. But then this ring configuration doesn't exist in an AWS
> VPC and I've not particularly observed a lot of packet duplication out
> of Amazon.
> 
> Regards,
> Bill Herrin

They don't have to break anything or get creative , just assume vrrp between the PE Routers.
Not sure how many vendors drop by default if they are not the active router.

Regards
Karsten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200623/cf06aab1/attachment.html>