[j-nsp] Junos BNG PPPoE inside a VPLS

[HahnC at t-systems.com]

Hello Paul,

I've configured lt-interfaces only on MX40 but should be in principle the same on heavier boxes. You need to enable tunnel-services on the MIC/PIC your want to use for this. I use that to connect logical-systems. Under the lt-interface config I had to define the corresponding lt-interface as "peer-unit".
I have no clue how this influences the throughput on this particular MIC/PIC. This is my config:

chassis {
	fpc 1 {
		pic 1 {
			tunnel-services;
		}
	}
}

interfaces {
	lt-1/1/0 {
		unit 0 {
			peer-unit 1;
			<usual interface config>
		}
		unit 1 {
			peer-unit 0;
			<usual interface config>
		}
	}
}

Hope this helps a bit,

cheers,
Christian

<><><><><><><><><><><><>

T-Systems International GmbH
Telekom IT

Christian Hahn
E-TSOCT, Verbundtest NT

Holzhauser Str. 4-8, 13509 Berlin
+49 30 8353-24212 (Tel.)
+49 69 66531-111 (Fax)
+49 170 7641791 (Mobil)
E-Mail: hahnc at t-systems.com
Internet: http://www.t-systems.de

T-Systems International GmbH
Supervisory Board: René Obermann (Chairman)
Board of Management: Reinhard Clemens (Chairman), Dr. Ferri Abolhassan, Dr. Markus Müller, Georg Pepping, Hagen Rickmann, Klaus Werner
Commercial register: Amtsgericht Frankfurt am Main HRB 55933
Registered office: Frankfurt am Main
WEEE-Reg.-No. DE50335567

Notice: This transmittal and/or attachments may be privileged or confidential. It is intended solely for the addressee named above. Any dissemination, or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you.



>-----Ursprüngliche Nachricht-----
>Von: juniper-nsp [mailto:juniper-nsp-bounces at puck.nether.net] Im Auftrag
>von Paul Stewart
>Gesendet: Mittwoch, 9. Oktober 2013 20:57
>An: juniper-nsp at puck.nether.net
>Betreff: Re: [j-nsp] Junos BNG PPPoE inside a VPLS
>
>Has anyone configured this up?  I'm looking to implement it (testing at
>this point) but confused...:)
>
>It looks like you still need to utilize an LT interface to identify
>which PFE is going to do the heavy lifting?  Believe it or not, I've
>never actually configured an LT interface before so this is perhaps a
>silly question but which interface would I want for this purpose and how
>much traffic could it handle?
>
>Hardware inventory:
>Item             Version  Part number  Serial number     Description
>Chassis                                xxxxxxxxxxxx      MX480
>Midplane         REV 05   710-017414   xxxxxxxx          MX480 Midplane
>FPM Board        REV 02   710-017254   xxxxxxxx          Front Panel
>Display
>PEM 0            Rev 05   740-027736   xxxxxxxxxxx       DC 2.4kW Power
>Entry Module
>PEM 1            Rev 05   740-027736   xxxxxxxxxxx       DC 2.4kW Power
>Entry Module
>PEM 2            Rev 05   740-027736   xxxxxxxxxxx       DC 2.4kW Power
>Entry Module
>PEM 3            Rev 05   740-027736   xxxxxxxxxxx       DC 2.4kW Power
>Entry Module
>Routing Engine 0 REV 08   740-031116   xxxxxxxxxx        RE-S-1800x4
>Routing Engine 1 REV 08   740-031116   xxxxxxxxxx        RE-S-1800x4
>CB 0             REV 15   710-021523   xxxxxxxx          MX SCB
>CB 1             REV 15   710-021523   xxxxxxxx          MX SCB
>FPC 0            REV 05   750-044444   xxxxxxxx          MPCE Type 2 3D
>P
>  CPU            REV 04   711-038484   xxxxxxxx          MPCE PMB 2G
>  MIC 0          REV 29   750-028387   xxxxxxxx          3D 4x 10GE  XFP
>    PIC 0                 BUILTIN      xxxxxxxx          2x 10GE  XFP
>      Xcvr 0     REV 01   740-014289   xxxxxxxx          XFP-10G-SR
>      Xcvr 1     REV 01   740-014289   xxxxxxxx          XFP-10G-SR
>    PIC 1                 BUILTIN      xxxxxxxx          2x 10GE  XFP
>  QXM 0          REV 06   711-028408   xxxxxxxx          MPC QXM
>  QXM 1          REV 06   711-028408   xxxxxxxx          MPC QXM
>FPC 1            REV 05   750-044444   xxxxxxxx          MPCE Type 2 3D
>P
>  CPU            REV 04   711-038484   xxxxxxxx          MPCE PMB 2G
>  MIC 1          REV 29   750-028387   xxxxxxxx          3D 4x 10GE  XFP
>    PIC 2                 BUILTIN      xxxxxxxx          2x 10GE  XFP
>      Xcvr 0     REV 01   740-014289   xxxxxxxx          XFP-10G-SR
>      Xcvr 1     REV 01   740-014289   xxxxxxxx          XFP-10G-SR
>    PIC 3                 BUILTIN      xxxxxxxx          2x 10GE  XFP
>  QXM 0          REV 06   711-028408   xxxxxxxx          MPC QXM
>  QXM 1          REV 06   711-028408   xxxxxxxx          MPC QXM
>Fan Tray                                                 Enhanced Left
>Fan
>Tray
>
>Any feedback appreciated...
>
>Paul
>
>
>
>
>On 2013-09-24 5:46 AM, "Mark Tinka" <mark.tinka at seacom.mu> wrote:
>
>>On Tuesday, September 17, 2013 04:05:50 PM Adrien Desportes
>>wrote:
>>
>>> Hello William,
>>>
>>> Before 13.2 you would have to use an external loop to terminate the
>>> vpls on one side and the ppp on the other side (as lt- interface does
>>> not support the proper encapsulation for ppp).
>>>
>>> Starting 13.2 (that was just released), if you use L2VPN rather than
>>> VPLS to backhaul your DSLAM VLAN, the below feature might do the job
>>> w/o consuming ports for the external hairpin:
>>>
>>> http://www.juniper.net/techpubs/en_US/junos13.2/topics/co
>>> ncept/pseudowire-subscriber-interfaces-overview.html
>>
>>Now I really don't have to have VPLS at all.
>>
>>Happy days :-).
>>
>>Mark.
>>_______________________________________________
>>juniper-nsp mailing list juniper-nsp at puck.nether.net
>>https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>_______________________________________________
>juniper-nsp mailing list juniper-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/juniper-nsp