Hi, This is very helpful. I'll test this and report back.
kind regards Pshem On Wed, 18 Jan 2017 at 20:05 George Giannousopoulos <ggian...@gmail.com> wrote: > Hi, > > There is a newer document about split horizon groups, which is more clear. > > http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-1/lxvpn/configuration/guide/lesc51x/lesc51p2mps.html#68334 > > Split horizon groups are actually supported for PWs, provided that you > have a relatively recent IOS-XR version. > > -- > George > > On Tue, Jan 17, 2017 at 10:01 PM, Pshem Kowalczyk <pshe...@gmail.com> > wrote: > > Hi, > > I think that might help, but I need to figure out a way for the packets to > not be flooded to other PWE3. according to the docs: > > http://www.cisco.com/en/US/docs/routers/asr9000/software/mpls/configuration/guide/gcasr9kvpls.html#wp1171784 > > *"Note *Split horizon groups are not supported for access PWs." > > > > I'll try to test that. Alternatively I'll try to see if I can move the > neighbour statement to a vfi (and build a fake static VPLS). > > I actually wonder if there is any difference between having the neighbours > directly under the bridge domain vs having a VFI under the bridge domain > and neighbours under the VFI. > > kind regards > Pshem > > > > On Tue, 17 Jan 2017 at 23:39 <adamv0...@netconsultings.com> wrote: > > > Hi Pshem, > > > > > Pshem Kowalczyk > > > Sent: Monday, January 16, 2017 9:25 PM > > > > > > Hi, > > > > > > We have a setup that currently uses a local bridge domain on asr9k, one > > local > > > physical interface and a number of P2P PWE3 that terminate on PWHE on > > > other asr9ks. The setup is used for broadband termination. The P2P PWE3 > > go > > > to BNGs. > > > The main reason for using a bridge domain with multiple PWE3 so we can > > > load-balance the subscribers among larger number of BNGs but also to > > > provide more graceful fail-over to what can be achieved with a backup > > > PWE3. > > > > > > Currently the bridge domain learns MAC addresses, but as the number of > > > subscriber grows that's likely to become a limiting factor. In reality > > we > > need > > > something like an e-tree where the BNGs are the leafs and the physical > > > interface is the root but with limited MAC address learning. In fact > what > > all > > > we need is one MAC address per BNG plus a 'default route' that points > to > > the > > > physical interface. Is there a way to define something like that? > > > > > > > Have you considered disabling mac learning on the BD and defining mac > > addresses of BNGs and GW statically please? > > > > RP/0/RP0/CPU0:router(config-l2vpn-bg)# bridge-domain bar > > RP/0/RP0/CPU0:router(config-l2vpn-bg-bd)# mac > > RP/0/RP0/CPU0:router(config-l2vpn-bg-bd-mac)# learning disable > > RP/0/RP0/CPU0:router(config-l2vpn-bg-bd-vfi)# neighbor 10.1.1.2 pw-id > 1000 > > RP/0/RP0/CPU0:router(config-l2vpn-bg-bd-vfi-pw)# static-mac-address 1.1.1 > > RP/0/RP0/CPU0:router(config-l2vpn-bg-bd)# interface GigabitEthernet > 0/1/0/0 > > RP/0/RP0/CPU0:router(config-l2vpn-bg-bd-ac)# static-mac-address 2.2.2 > > > > adam > > > > netconsultings.com > > ::carrier-class solutions for the telecommunications industry:: > > > > > > _______________________________________________ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/