[ixpmanager] Broadcast Traffic

Basil Elbalaawi saifbasilyazan at gmail.com
Wed Nov 11 16:47:39 GMT 2020


Thanks Nick , you are a wonderful man .


On Tue, Nov 10, 2020 at 7:31 PM Nick Hilliard (INEX) <nick at inex.ie> wrote:

> Basil Elbalaawi wrote on 08/11/2020 12:54:
> > I have one question about  Broadcast Traffic where I think it is not
> > allowed to be transmitted on the “IXP” switch Device except for ARP. So
> > there is Upon initial connection and subsequently if they deem
> > necessary, the partner may place a Participant's port into a separate
> > "quarantine" VLAN or stop the neighbor peering, for diagnostic purposes,
> > or to verify policy-compliant operation. This action shall restore
> > Participant's port to full functionality immediately upon resolution of
> > the triggering issue. My question!
> >
> > How can it be tested for the Broadcast Traffic at our IXP , or which
> > command can be used about it with example , where i think you mentioned
> > it about the Quarantine Route collector to do this , if you please
> > explain how to do it to prevent the  Broadcast Traffic?
>
> in fact that there are different types of broadcast traffic, e.g.
>
> - link-local traffic: traffic which goes from one switch port to another
> and no further (loopback frames, LLDP, etc)
> - broadcast traffic
> - multicast traffic
> - unknown unicast traffic
>
> For a quarantine LAN, the best option is to use RX port monitoring to
> detect all incoming frames on the new network port.  This is the only
> option that shows you all frames, not just Bcast/Ucast/Mcast traffic.
>
> On a production IXP, it's often a good idea to run a broadcast frame
> collector, e.g. ixp-watch (https://github.com/euro-ix/IXP-Watch).  This
> will monitor for ongoing problems.
>
> Nick
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.inex.ie/pipermail/ixpmanager/attachments/20201111/7245955e/attachment.htm>


More information about the ixpmanager mailing list