Re: [j-nsp] MX-80 as a BRAS and as a LAC

[Enoch Nyatoti]

Thank you guys for your inputs. I have got it working. We have a little over 
2000 subscribers for a particular area so the 4000 limit is not a concern.


 
Best regards
Enoch Nyatoti





On Thursday, October 24, 2013 2:51 PM, Paul Stewart  
wrote:
 
Also make sure you talk to your Juniper SE and engage him in your plans -
make sure you understand which code releases you require for your
deployment.  The last I checked, LNS was not supported on MX80 but that
may have changed in recent 13.2 code.

Like everything there’s several ways to configure things - here’s a pretty
base configuration that will hopefully help point you in the right
direction… the local pool assignment isn’t need if your Radius is going to
hand out all dynamic addresses...

dynamic-profiles {
    PPPOE {
        predefined-variable-defaults {
            input-filter PERMIT-ALL;
            output-filter PERMIT-ALL;
        }
        interfaces {
            pp0 {
                unit "$junos-interface-unit" {
                    ppp-options {
                        pap;
                    }
                    pppoe-options {
                        underlying-interface "$junos-underlying-interface";
                        server;
                    }
                    keepalives interval 30;
                    family inet {
                        filter {
                            input "$junos-input-filter";
                            output "$junos-output-filter";
                        }
                        unnumbered-address lo0.0;
                    }
                }
            }
        }
    }
}

interfaces {
    ge-1/0/0 {    
        description ge0-1-0.dis4.xx;
        vlan-tagging;
        encapsulation flexible-ethernet-services;
        unit 404 { 
            description x;
            vlan-id 404;
            family pppoe {
                duplicate-protection;
                dynamic-profile PPPOE;
                short-cycle-protection;
            }      
        }          
    }              
}


access {
    radius-server {
        Xx.xxx.xx.xxx {
            secret “xxx"; ## SECRET-DATA
            source-address xx.xx.xxx.xx;
        }
        Xx.xxx.xxx.xx {
            secret “xxx"; ## SECRET-DATA
            source-address xx.xxx.xx.xx;
        }
    }
    group-profile DNS {
        ppp {
            primary-dns xxx.xxx.xx.xxx;
            secondary-dns xx.xx.x.xxx;
        }
    }
    profile RADIUS {
        accounting-order radius;
        authentication-order radius;
        radius {
            authentication-server [ xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx ];
            accounting-server [ xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx ];
            options {
                revert-interval 0;
                client-authentication-algorithm round-robin;
                client-accounting-algorithm round-robin;
            }
        }
        accounting {
            order radius;
            accounting-stop-on-failure;
            accounting-stop-on-access-deny;
            immediate-update;
            update-interval 10;
            statistics volume-time;
        }
    }
    address-assignment {
        pool PPPOE-1 {
            link PPPOE-2;
            family inet {
                network 10.0.0.0/24;
                range 1 {
                    low 10.0.0.1;
                    high 10.0.0.254;
                }
            }
        }
       }
    }
}
access-profile RADIUS;



Also note that this example doesn’t include anything for your routing.  So
everything in JunOS is “access-internal” and you need to redistribute them
into OSPF (or whatever IGP you are running).  When you redistribute them,
each route shows up separately for each subscriber - a large amount of /32
routes if you are not careful which can cause “bad things to happen(™)”.
What I did to work around this was to summarize the routes but in doing so
I had to ensure that static IP assignments would still function:

routing-options {
static {
route 10.0.0.0/24 discard;
    }
}

policy-options {
        term access-internal-1 {
            from {
                protocol access-internal;
                route-filter 10.0.0.0/24 longer;
            then reject;
        }
        term access-internal-2 {
            from protocol access-internal;
            then accept;
        }
        term implicit-deny {
            then reject;
        }
    }
}


Hope that helps...

Paul



On 10/24/2013, 3:12 AM, "Terebizh, Evgeny"  wrote:

>Hi,
>Check out the feature map below:
>https://www.juniper.net/techpubs/en_US/junos12.3/information-products/path
>w
>ay-pages/subscriber-access/technology-overview-graphic.html
>
>Here¹s the relevant L2TP section:
>https://www.juniper.net/techpubs/en_US/junos13.2/information-products/path
>w
>ay-pages/subscriber-access/l2tp/subscriber-management-l2tp.html
>
>Bear in mind that you might need a juniper.net account to access these
>links. 
>
>
>/Evgeny
>
>
>
>
>On 19/10/13 2

Re: [j-nsp] srx cluster - port channel - cisco switches - esx devices - 12.1x45-d15.5 some virtual machines can't be reached

[Ben Dale]

On 24 Oct 2013, at 5:48 pm, pkc_mls  wrote:

> Le 24/10/2013 00:55, Ben Dale a écrit :
>> Can you confirm that you have two "active" port-channels configured on the 
>> Cisco side, one into each SRX? 
> From the docs I found I was assuming a single port-channel could handle all 
> interfaces attached to the same reth on srx.
> 
> For example, if ge-0/0/2, ge-0/0/3, ge-5/0/2, ge-5/0/3 are attached to reth0, 
> can I connect all the ports to the same etherchannel on the stack ?
> 
> 

No, there will be two sub-LAGs formed from the SRX - one on the active node, 
and one on the standby node.  To downstream devices, these appear as distinct 
LACP bundles, even though they are part of the same reth interface on the SRX.

There is a rather wordy explanation of it here, but the Note box in the middle 
of the page is probably a good summary:

http://www.juniper.net/techpubs/software/junos-security/junos-security10.2/junos-security-swconfig-interfaces/understand-lacp-in-cc-mode-section.html

Ben
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4550 true power consumption

[Michael Loftis]

On Thu, Oct 24, 2013 at 3:02 PM, Chuck Anderson  wrote:
> On Thu, Oct 24, 2013 at 09:38:43AM -0700, Michael Loftis wrote:
>> I don't know anyone that assumes that the peak capability of a PSU
>> (especially in network gear) is it's actual consumtion, but thats just
>> me.  I do agree I wish they'd publish at least approximate figures.
>> It can be a deciding factor in a lot of environments today.  Keep in
>> mined 650W is high-line mode (~220/240VAC) - in 120V it's only going
>> to be around 325W.
>
> This deserves clarification.  The power usage in Watts for a given
> hardware configuration should be the same either way--it is just that
> in high-line mode 208/220/240V, you will draw less current in Amps, by
> about half for twice the voltage (ohms law approximately, with a Power
> Factor Correction thrown in), and because of this the power supply is
> designed so that you can consume up to 650W of power only if you use
> high-line mode, and if you max-out the supply in low-line 120V mode
> you will only be able to consume up to 325W.  This implies that if you
> use low-line mode, you won't be able to install as many
> modules/optics/whatever-else-uses-power before hitting the max or
> losing power supply redundancy (being that both PSUs will be required
> to power everything).

Yeah sorry, I was quoting the PSU wattage ratings from memory at the
input voltage ranges, not usage.  So yes, barring efficiency
differences between 120V (low-line) and 240V (high-line) "mode" the
wall usage is, of course, the same.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4550 true power consumption

[Chuck Anderson]

On Thu, Oct 24, 2013 at 09:38:43AM -0700, Michael Loftis wrote:
> I don't know anyone that assumes that the peak capability of a PSU
> (especially in network gear) is it's actual consumtion, but thats just
> me.  I do agree I wish they'd publish at least approximate figures.
> It can be a deciding factor in a lot of environments today.  Keep in
> mined 650W is high-line mode (~220/240VAC) - in 120V it's only going
> to be around 325W.

This deserves clarification.  The power usage in Watts for a given
hardware configuration should be the same either way--it is just that
in high-line mode 208/220/240V, you will draw less current in Amps, by
about half for twice the voltage (ohms law approximately, with a Power
Factor Correction thrown in), and because of this the power supply is
designed so that you can consume up to 650W of power only if you use
high-line mode, and if you max-out the supply in low-line 120V mode
you will only be able to consume up to 325W.  This implies that if you
use low-line mode, you won't be able to install as many
modules/optics/whatever-else-uses-power before hitting the max or
losing power supply redundancy (being that both PSUs will be required
to power everything).
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX-80 as a BRAS and as a LAC

[Skeeve Stevens]

Also,

You can only buy the 4000 user license for the MX80 midrange (MX5-MX80)


...Skeeve

*Skeeve Stevens - *eintellego Networks Pty Ltd
ske...@eintellegonetworks.com ; www.eintellegonetworks.com

Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve

facebook.com/eintellegonetworks ;  
linkedin.com/in/skeeve

twitter.com/theispguy ; blog: www.theispguy.com


The Experts Who The Experts Call
Juniper - Cisco - Cloud


On Fri, Oct 25, 2013 at 1:05 AM, Alex D.  wrote:

> Am 19.10.2013 21:44, schrieb Enoch Nyatoti:
>
>> Hello,
>>
>> I am new to Juniper hence my request. We would like to deploy BRAS  and
>> LAC functionality on MX80 routers to existing Cisco NAS and I was wondering
>> if you could give me a lead on
>> how to configure these features in Junos including the relevant PPPoE
>> interface configuration. The idea is to tunnel some sessions to an LNS
>> depending on
>> the domain name.
>> __**_
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/**mailman/listinfo/juniper-nsp
>>
>>
> Hi,
>
> how much users do you want to terminate on your MX80 ?
> Keep in mind, that there is a limit of 16.000 IFLs. When you plan to use
> hierarchical qos, better go to a bigger platform.
>
> Regards,
> Alex
>
> __**_
> 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

Re: [j-nsp] MX-80 as a BRAS and as a LAC

[sthaug]

> how much users do you want to terminate on your MX80 ?
> Keep in mind, that there is a limit of 16.000 IFLs. When you plan to use
> hierarchical qos, better go to a bigger platform.

Good luck with MX80 as a BRAS for 16000 users. Given its weak CPU,
you should expect the practical limit to be significantly lower.

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX-80 as a BRAS and as a LAC

[Paul Stewart]

Thanks for bringing that up Š. 16,000 IFL¹s and PPPOE uses two IFL¹s per
subscriber and the box doesn¹t handle more than 4,000 PPPOE customers very
well.  There has been some challenges with Juniper identifying how far the
box will really scale - we tell our customers to not go above 4,000 as a
³good rule of thumb² of course depending on what they are doing and how
they are using it etcŠ.

-p

On 10/24/2013, 10:05 AM, "Alex D."  wrote:

>Am 19.10.2013 21:44, schrieb Enoch Nyatoti:
>> Hello,
>>
>> I am new to Juniper hence my request. We would like to deploy BRAS  and
>>LAC functionality on MX80 routers to existing Cisco NAS and I was
>>wondering if you could give me a lead on
>> how to configure these features in Junos including the relevant PPPoE
>> interface configuration. The idea is to tunnel some sessions to an LNS
>>depending on
>> the domain name.
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
>Hi,
>
>how much users do you want to terminate on your MX80 ?
>Keep in mind, that there is a limit of 16.000 IFLs. When you plan to use
>hierarchical qos, better go to a bigger platform.
>
>Regards,
>Alex
>
>___
>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

Re: [j-nsp] EX4550 true power consumption

[Michael Loftis]

I don't know anyone that assumes that the peak capability of a PSU
(especially in network gear) is it's actual consumtion, but thats just
me.  I do agree I wish they'd publish at least approximate figures.
It can be a deciding factor in a lot of environments today.  Keep in
mined 650W is high-line mode (~220/240VAC) - in 120V it's only going
to be around 325W.

On Thu, Oct 24, 2013 at 8:40 AM, Jonas Frey (Probe Networks)
 wrote:
> Michael,
>
> i understand that it depends on the config. But why is it so hard to
> give some figures? E.g. base xx Watts, each optic xx Watts, VC module xx
> Watts and so on. Even Cisco does this (for example Nexus 3k).
> Right now it appears (with the only 650W power supply figure) as if the
> EX4550 is a power hog (compared to similar units like the above
> mentioned Nexus 3k).
>
> -J
>
>
> Am Donnerstag, den 24.10.2013, 08:28 -0700 schrieb Michael Loftis:
>> The correct answer is it depends on configuration and traffic. Loaded
>> with LR SFP+s, vc modules, and pushing a significant amount of traffic
>> it will easily be 400W or more. Around 100W for a base, idle unit with
>> a few optics sounds right. Each optic module draws several watts
>> depending on the type.
>>
>> On Oct 23, 2013 10:25 AM, "Jonas Frey (Probe Networks)"
>>  wrote:
>> Hello,
>>
>> does anybody have real world power consumption specs of the
>> EX4550?
>> (EX4550-32F-AFI)
>> Juniper has no word about this anywhere in the documentation.
>> There are
>> only statements about the power supply itself (650W capacity)
>> and "less
>> than five watts per 10GB fiber interface".
>> I've been able to find various values on non-juniper related
>> sites which
>> range from 175W to 345W.
>>
>> Best regards,
>> Jonas
>>
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp



-- 

"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4550 true power consumption

[Michael Loftis]

The correct answer is it depends on configuration and traffic. Loaded with
LR SFP+s, vc modules, and pushing a significant amount of traffic it will
easily be 400W or more. Around 100W for a base, idle unit with a few optics
sounds right. Each optic module draws several watts depending on the type.
On Oct 23, 2013 10:25 AM, "Jonas Frey (Probe Networks)" <
j...@probe-networks.de> wrote:

> Hello,
>
> does anybody have real world power consumption specs of the EX4550?
> (EX4550-32F-AFI)
> Juniper has no word about this anywhere in the documentation. There are
> only statements about the power supply itself (650W capacity) and "less
> than five watts per 10GB fiber interface".
> I've been able to find various values on non-juniper related sites which
> range from 175W to 345W.
>
> Best regards,
> Jonas
>
> ___
> 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

Re: [j-nsp] EX4550 true power consumption

[Jonas Frey (Probe Networks)]

Michael,

i understand that it depends on the config. But why is it so hard to
give some figures? E.g. base xx Watts, each optic xx Watts, VC module xx
Watts and so on. Even Cisco does this (for example Nexus 3k).
Right now it appears (with the only 650W power supply figure) as if the
EX4550 is a power hog (compared to similar units like the above
mentioned Nexus 3k).

-J


Am Donnerstag, den 24.10.2013, 08:28 -0700 schrieb Michael Loftis:
> The correct answer is it depends on configuration and traffic. Loaded
> with LR SFP+s, vc modules, and pushing a significant amount of traffic
> it will easily be 400W or more. Around 100W for a base, idle unit with
> a few optics sounds right. Each optic module draws several watts
> depending on the type.
> 
> On Oct 23, 2013 10:25 AM, "Jonas Frey (Probe Networks)"
>  wrote:
> Hello,
> 
> does anybody have real world power consumption specs of the
> EX4550?
> (EX4550-32F-AFI)
> Juniper has no word about this anywhere in the documentation.
> There are
> only statements about the power supply itself (650W capacity)
> and "less
> than five watts per 10GB fiber interface".
> I've been able to find various values on non-juniper related
> sites which
> range from 175W to 345W.
> 
> Best regards,
> Jonas
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


signature.asc
Description: This is a digitally signed message part
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX-80 as a BRAS and as a LAC

[Alex D.]

Am 19.10.2013 21:44, schrieb Enoch Nyatoti:

Hello,

I am new to Juniper hence my request. We would like to deploy BRAS  and LAC 
functionality on MX80 routers to existing Cisco NAS and I was wondering if you 
could give me a lead on
how to configure these features in Junos including the relevant PPPoE
interface configuration. The idea is to tunnel some sessions to an LNS 
depending on
the domain name.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp



Hi,

how much users do you want to terminate on your MX80 ?
Keep in mind, that there is a limit of 16.000 IFLs. When you plan to use
hierarchical qos, better go to a bigger platform.

Regards,
Alex

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX-MPC2-3D layer 3 license required

[Paul Stewart]

Honor system at moment - just received some licenses and they were just
paper (no codes to enter)

Paul


On 10/23/2013, 9:27 PM, "John pp"  wrote:

>Is the layer 3 license required or is it an honour system?
>
>Thanks
>___
>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

Re: [j-nsp] MX-80 as a BRAS and as a LAC

[Paul Stewart]

Also make sure you talk to your Juniper SE and engage him in your plans -
make sure you understand which code releases you require for your
deployment.  The last I checked, LNS was not supported on MX80 but that
may have changed in recent 13.2 code.

Like everything there’s several ways to configure things - here’s a pretty
base configuration that will hopefully help point you in the right
direction… the local pool assignment isn’t need if your Radius is going to
hand out all dynamic addresses...

dynamic-profiles {
PPPOE {
predefined-variable-defaults {
input-filter PERMIT-ALL;
output-filter PERMIT-ALL;
}
interfaces {
pp0 {
unit "$junos-interface-unit" {
ppp-options {
pap;
}
pppoe-options {
underlying-interface "$junos-underlying-interface";
server;
}
keepalives interval 30;
family inet {
filter {
input "$junos-input-filter";
output "$junos-output-filter";
}
unnumbered-address lo0.0;
}
}
}
}
}
}

interfaces {
ge-1/0/0 { 
description ge0-1-0.dis4.xx;
vlan-tagging;
encapsulation flexible-ethernet-services;
unit 404 { 
description x;
vlan-id 404;
family pppoe {
duplicate-protection;
dynamic-profile PPPOE;
short-cycle-protection;
}  
}  
}  
}


access {
radius-server {
Xx.xxx.xx.xxx {
secret “xxx"; ## SECRET-DATA
source-address xx.xx.xxx.xx;
}
Xx.xxx.xxx.xx {
secret “xxx"; ## SECRET-DATA
source-address xx.xxx.xx.xx;
}
}
group-profile DNS {
ppp {
primary-dns xxx.xxx.xx.xxx;
secondary-dns xx.xx.x.xxx;
}
}
profile RADIUS {
accounting-order radius;
authentication-order radius;
radius {
authentication-server [ xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx ];
accounting-server [ xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx ];
options {
revert-interval 0;
client-authentication-algorithm round-robin;
client-accounting-algorithm round-robin;
}
}
accounting {
order radius;
accounting-stop-on-failure;
accounting-stop-on-access-deny;
immediate-update;
update-interval 10;
statistics volume-time;
}
}
address-assignment {
pool PPPOE-1 {
link PPPOE-2;
family inet {
network 10.0.0.0/24;
range 1 {
low 10.0.0.1;
high 10.0.0.254;
}
}
}
   }
}
}
access-profile RADIUS;



Also note that this example doesn’t include anything for your routing.  So
everything in JunOS is “access-internal” and you need to redistribute them
into OSPF (or whatever IGP you are running).  When you redistribute them,
each route shows up separately for each subscriber - a large amount of /32
routes if you are not careful which can cause “bad things to happen(™)”.
What I did to work around this was to summarize the routes but in doing so
I had to ensure that static IP assignments would still function:

routing-options {
static {
route 10.0.0.0/24 discard;
}
}

policy-options {
term access-internal-1 {
from {
protocol access-internal;
route-filter 10.0.0.0/24 longer;
then reject;
}
term access-internal-2 {
from protocol access-internal;
then accept;
}
term implicit-deny {
then reject;
}
}
}


Hope that helps...

Paul



On 10/24/2013, 3:12 AM, "Terebizh, Evgeny"  wrote:

>Hi,
>Check out the feature map below:
>https://www.juniper.net/techpubs/en_US/junos12.3/information-products/path
>w
>ay-pages/subscriber-access/technology-overview-graphic.html
>
>Here¹s the relevant L2TP section:
>https://www.juniper.net/techpubs/en_US/junos13.2/information-products/path
>w
>ay-pages/subscriber-access/l2tp/subscriber-management-l2tp.html
>
>Bear in mind that you might need a juniper.net account to access these
>links. 
>
>
>/Evgeny
>
>
>
>
>On 19/10/13 23:44, "Enoch Nyatoti"  wrote:
>
>>Hello,
>>
>>I am new to Juniper hence my request. We would like to deploy BRAS  and
>>LAC functionality on MX80 routers to existing Cisco NAS and I was
>>wondering if you could give me a lead on
>>how to configure the

Re: [j-nsp] EX4550 true power consumption

[Jed Laundry]

Hi Jonas,

Not sure if it helps, but on my lab -48V D.C. unit I'm seeing ~100W with 2x
SFP+, 5x SFP and 2x ge copper (no stacking/expansion module).

Thanks,
Jed.
 On 24/10/2013 6:26 am, "Jonas Frey (Probe Networks)" 
wrote:

> Hello,
>
> does anybody have real world power consumption specs of the EX4550?
> (EX4550-32F-AFI)
> Juniper has no word about this anywhere in the documentation. There are
> only statements about the power supply itself (650W capacity) and "less
> than five watts per 10GB fiber interface".
> I've been able to find various values on non-juniper related sites which
> range from 175W to 345W.
>
> Best regards,
> Jonas
>
> ___
> 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

Re: [j-nsp] srx cluster - port channel - cisco switches - esx devices - 12.1x45-d15.5 some virtual machines can't be reached

[pkc_mls]

Le 24/10/2013 00:55, Ben Dale a écrit :
Can you confirm that you have two "active" port-channels configured on 
the Cisco side, one into each SRX? 
From the docs I found I was assuming a single port-channel could handle 
all interfaces attached to the same reth on srx.


For example, if ge-0/0/2, ge-0/0/3, ge-5/0/2, ge-5/0/3 are attached to 
reth0, can I connect all the ports to the same etherchannel on the stack ?



___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX-80 as a BRAS and as a LAC

[Terebizh, Evgeny]

Hi,
Check out the feature map below:
https://www.juniper.net/techpubs/en_US/junos12.3/information-products/pathw
ay-pages/subscriber-access/technology-overview-graphic.html

Here¹s the relevant L2TP section:
https://www.juniper.net/techpubs/en_US/junos13.2/information-products/pathw
ay-pages/subscriber-access/l2tp/subscriber-management-l2tp.html

Bear in mind that you might need a juniper.net account to access these
links. 


/Evgeny




On 19/10/13 23:44, "Enoch Nyatoti"  wrote:

>Hello,
>
>I am new to Juniper hence my request. We would like to deploy BRAS  and
>LAC functionality on MX80 routers to existing Cisco NAS and I was
>wondering if you could give me a lead on
>how to configure these features in Junos including the relevant PPPoE
>interface configuration. The idea is to tunnel some sessions to an LNS
>depending on 
>the domain name.
>___
>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