Any reason to use MC-LAG as the termination/CE-facing method out of a VPLS, instead of using the standard VPLS primary/backup "sites" to prevent layer-2 looping?
Since MC-LAG generally is tricky (I've seen dumps as well), it made us re-think our reasons for using MC-LAG for our MX-to-Layer2-Agg-Network VPLS Termination. We ended up migrating away from it as a permanent solution, Instead, using primary/backup (BGP) VPLS where possible. Another solution to try: If you control the downstream (CE) switch and it's an EX-Series, you can also move the loop-avoidance mechanism there, by using Redundant Trunk Groups (RTGs). You can then pass more than just VPLS layer-2 traffic too from the redundant PEs. However, this being said, and you need MC-LAG - we've tested it (using vlan-vpls interfaces) on 10.3R4 through pretty much the entire 10.4-series (we're up to 10.4R6 now). I'd be interested if anyone is running MC-LAG on 11-dot-anything on an MX at the moment. - Chris. On 2011-11-01, at 5:54 PM, David wrote: > Trying this now for a customer, running 10.2R3.3. Currently seeing an issue > with l2 subsystem crashing and throwing a core dump, got this issue > escalated to ATAC. > > webnetwiz. > > On Sun, May 29, 2011 at 2:32 PM, <david....@orange-ftgroup.com> wrote: > >> Hi All, >> >> Somebody has experience regarding MX LAG on Juniper MX in 10.2 ? >> >> MC LAG in stanby-active for VPLS mode with LACP and ICCP configured ? >> Does-it work ? Are-there any HW or SW requierements ? Some sample config >> are welcome, too. >> I tried to configure it with DPC combo card (20x1GE - 2x20GE). All the >> configuration has commited but my LAG is still down. >> >> Thanks for your help. >> Regards >> David >> >> Hereafter my configuration : >> >> On MX 1 : >> >> ae0 { >> encapsulation ethernet-vpls; >> aggregated-ether-options { >> link-speed 1g; >> lacp { >> active; >> system-priority 1; >> system-id 00:00:00:00:00:01; >> admin-key 12345; >> } >> mc-ae { >> mc-ae-id 1; >> redundancy-group 1; >> chassis-id 0; >> mode active-standby; >> status-control standby; >> } >> } >> unit 0; >> } >> ge-0/0/3 { >> speed 1g; >> link-mode full-duplex; >> gigether-options { >> 802.3ad ae0; >> } >> } >> iccp { >> local-ip-addr 1.1.1.1; >> peer 2.2.2.2 { >> redundancy-group-id-list 1; >> liveness-detection { >> minimum-interval 1000; >> } >> } >> } >> >> On MX 2 >> >> >> ae0 { >> encapsulation ethernet-vpls; >> aggregated-ether-options { >> link-speed 1g; >> lacp { >> active; >> system-priority 1; >> system-id 00:00:00:00:00:01; >> admin-key 12345; >> } >> mc-ae { >> mc-ae-id 1; >> redundancy-group 1; >> chassis-id 0; >> mode active-standby; >> status-control active; <<<<<<<<<<<<<<<< >> } >> } >> unit 0; >> } >> ge-0/0/5 { >> speed 1g; >> link-mode full-duplex; >> gigether-options { >> 802.3ad ae0; >> } >> } >> iccp { >> local-ip-addr 2.2.2.2; >> peer1.1.1.1 { >> redundancy-group-id-list 1; >> liveness-detection { >> minimum-interval 1000; >> } >> } >> } >> >> >> ******************************************************************************** >> IMPORTANT.Les informations contenues dans ce message electronique y >> compris les fichiers attaches sont strictement confidentielles >> et peuvent etre protegees par la loi. >> Ce message electronique est destine exclusivement au(x) destinataire(s) >> mentionne(s) ci-dessus. >> Si vous avez recu ce message par erreur ou s il ne vous est pas destine, >> veuillez immediatement le signaler a l expediteur et effacer ce message >> et tous les fichiers eventuellement attaches. >> Toute lecture, exploitation ou transmission des informations contenues >> dans ce message est interdite. >> Tout message electronique est susceptible d alteration. >> A ce titre, le Groupe France Telecom decline toute responsabilite >> notamment s il a ete altere, deforme ou falsifie. >> De meme, il appartient au destinataire de s assurer de l absence de tout >> virus. >> >> IMPORTANT.This e-mail message and any attachments are strictly >> confidential and may be protected by law. This message is >> intended only for the named recipient(s) above. >> If you have received this message in error, or are not the named >> recipient(s), please immediately notify the sender and delete this e-mail >> message. >> Any unauthorized view, usage or disclosure ofthis message is prohibited. >> Since e-mail messages may not be reliable, France Telecom Group shall not >> be liable for any message if modified, changed or falsified. >> Additionally the recipient should ensure they are actually virus free. >> >> ******************************************************************************** >> >> >> _______________________________________________ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp