[c-nsp] Building E-Trees

[Pshem Kowalczyk]

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 <ggiannou at 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 <pshem.k at 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 <adamv0025 at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>