View Only
last person joined: 3 days ago 

Ask questions and share experiences about ACX Series, CTP Series, MX Series, PTX Series, SSR Series, JRR Series, and all things routing, including portfolios and protocols.
  • 1.  VPLS BUM packet handling

    Posted 04-13-2023 14:35

    Hello Community,

    I am looking to find some information in regards to BUM packet handling in VPLS.
    I am more or less understand on how it works, but looking to have some "documentation" that can prove my understanding. 

    I sow some topics around unicast packet flow, and this more or less good described, but did not found any details about the BUM.
    Some confusion is around "split horizon" rules and principals... and how the L2 loop can damage the full mash (multi tenant instance) due to Broadcast.

    Thank you for any feedback and information.



  • 2.  RE: VPLS BUM packet handling

    Posted 04-15-2023 13:49

    I would say that broadcast is not the same as l2 loop for the purposes of a BUM filter.  While it is true that an L2 loop will generate lots of broadcast this is not what the BUM filter is aimed at correcting.

    BUM filters are simple rate limiting function because we know there is a distance and link limitation between the L2 devices.  As a result we don't want a large portion of the traffic to be these BUM member packets and using too much of these limited links.  So the BUM filter is just rate limiting the potential for taking too much of the link resource rather than trying to mitigate a problem that has occurred in the layer 2 domain like a loop.

    Sorry, that I don't have a documentation link.  you are right that the docs tend to focus on how and configs and not so much the why.

    Steve Puluka BSEET - Juniper Ambassador
    IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP - Retired)

  • 3.  RE: VPLS BUM packet handling

    Posted 04-17-2023 03:16

    Thank you so much Steve,
    Most probably I did not formulated correct the request.

    The main idea I am looking to clarify is the behaviour of BUM traffic in a Full Mesh VPLS instance.
    - How the PE will handle the traffic received from CE port (BUM traffic)
    - How the PE will handle the traffic received from PE port (BUM traffic)

    As the main idea of VPLS (the way how I understand this) is to replicate the functionality of a Standard Switch - the Broadcast frame may/will leave forever in a Full Mesh VPLS - as there is no TTL or any other way to stop/discard it?
    I am confident it's not the case - and I was looking for some documentation that could describe how the PE device will handle the BUM traffic been part of a full Mesh VPLS.



  • 4.  RE: VPLS BUM packet handling

    Posted 04-17-2023 06:18

    VPLS does handle BUM traffic as the RFC dictate, there are not changes to that part.

    What the BUM filter is for is rate limiting to prevent too much of the traffic from being sent between instances and clogging the limited path.

    Steve Puluka BSEET - Juniper Ambassador
    IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP - Retired)

  • 5.  RE: VPLS BUM packet handling

    Posted 04-17-2023 07:38

    Thank you so much!

    So (just to have sort of confirmation to my understanding), according to RFC4762 , the BUM will be flooded to all ports (section 4.1)
    Same time section 4.4 says there should be sort of "

    some loop-breaking protocol, like a spanning tree

    And this part I am looking to understand better.
    How this is realised within the Juniper devices?

    Any references on this matter?


  • 6.  RE: VPLS BUM packet handling

    Posted 04-18-2023 06:46

    Sorry I was missing the point. I think I see the issue you are trying to address now, and agree you do NOT want to directly neighbor vpls instances in a loop.  They do behave similar to old style hubs and the rate limit is minimal protection.  For these scenarios where you want redundancy between multiple vpls instances you could use pseudo wire l2 circuits with failover paths so that only one is active at a time in a mesh group.  These circuits stitch into the vpls and provide a connection with redundant failover.

    These are some documentation examples.

    Steve Puluka BSEET - Juniper Ambassador
    IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP - Retired)

  • 7.  RE: VPLS BUM packet handling

    Posted 04-17-2023 10:34
    Edited by aaron.gould 04-18-2023 10:56
    My initial learning of VPLS was gained while working with Cisco equipment.  Forgive me if some of this is different in Juniper, and I would like to know where it differs.  I have setup manual (static) and bgp-auto (dynamic) vpls routing instances in my network using Juniper ACX5048's, but don't know of all the fowarding behaviors and options
    VPLS has concepts of root and leaf connections
    Leaf being the auto-pseudowires that are created with BGP Auto Discovery, and also manual pw's under a vfi
    Root being the local AC's (attachment circuits, usually physical or logical unit subinterfaces), or a pw above/outside of a vfi (which may be known as H-VPLS)
    For traffic forwarding, BUM handling, loop prevention, and security using Hub-Spoke architecture creating MEF E-Tree EVC, is leaf to leaf communications is *not* allowed
    You have to know what is considered to be a leaf
    Within Cisco, particularly the ASR9000 (IOS-XR), there's a VFI concept (virtual forwarding interface) as mentioned above.  pw's under/within a vfi are *leafs* and mac addresses learned on vfi-pw's cannot communicate with other mac addresses learned on other vfi-pw's.
    Forwarding is allowed...
    Forwarding is not allowed...
    however, leaf to leaf *is* allowed if you configure one of the leafs in a different split horizon group
    I would like to read about these concepts in Juniper documents 
    UPDATE 4/18/2023 - i did find a few links to help understand some of the ways to allow/disallow forwarding , some of these links may/may not apply to all platforms, as I read ACX and EX in these links

    EVPN-ETREE Overview

    Juniper remove preview
    EVPN-ETREE Overview
    The EVPN-ETREE service is a VPN service where each attachment circuit is designated as either root or leaf. The EVPN E-Tree feature implements E-Tree service as defined by the Metro Ethernet Forum (MEF) in draft-sajassi-l2vpn-evpn-etree-03. The E-Tree service is a rooted-multipoint service that is supported only with EVPN over MPLS in the core.
    View this on Juniper >



    Juniper remove preview
    Specify that access ports in this VLAN domain do not forward packets to each other. You use this statement with primary VLANs and isolated secondary VLANs. You can also disable local switching on both customer edge (CE) and VPLS edge (VE) mesh-groups. Access and core-facing interfaces are included in the system-generated CE mesh-group and VE mesh-group, respectively.
    View this on Juniper >


    - Aaron