[j-nsp] Junos BNG PPPoE inside a VPLS

Terebizh, Evgeny eterebizh at amt.ru
Fri Sep 27 09:05:56 EDT 2013


>ET> It's not that bad comparing to IPoE model. At least you got PPP
>keepalives, so it won't take a long time for a CPE to re-establish
>internet connectivity through terminating existing session and creating a
>new one. As I recall, In IPoE scenario CPE will keep existing session up
>for 75% of dhcp lease time configured which could take some time unless
>your CPE supports ARP ping. Anybody knows if Juniper MX/E support this
>feature? 
>
>CB> DHCP leases can be quite short still, 5 min or less if your
>router/DHCP server can support it.  Some BNGs can also split-lease DHCP
>(not sure if Juniper can do this, anybody?) where the BNG maintains a
>short lease with the client but only relays a long lease (1 day etc) to
>the main DHCP server reducing the resource requirements of the servers.
ET> Thanks for your answer. Right. I've seen scenario with few thousands
of subscribers sitting on a same box having 5-min dhcp lease time
interval. 
I was planning to configure a 45 min interval, but accidentally wrong
interval came into production environment. Anyway, no issues so far.
Routing Engine is *not* experiencing huge load under jdhcp process. I
believe that box was using RE-1800x 64-bit routing engine.
I was kinda surprised at JUNOS not supporting DHCP in hardware (RE is
handling this AFAIK). Cisco ASR9K supports this in hardware though. You
could set whichever *low* DHCP lease time you would like to. Never heard
about split-lease DHCP. Interesting. Gotta check this out.

>
>ET> Nice feature. As far as I understand you can't achieve load sharing
>using it, right? You've got single master for existing VRRP group and
>master handles 
>PADO replies, so when backup BNG takes over it would consider *every*
>session unknown. Is my understanding correct?
>
>CB>  Yes when the backup BNG takes over it does consider every session
>unknown and sends a PADT to kill the session immediately on the CPE so it
>is quite fast to failover.  You can also achieve load balancing by
>running multiple VRRP groups on each interface and tying some
>subinterfaces/vlan/vlan-ranges to each group.
ET> I guess my second question would be about load balancing :)
 Thank you.

>
>ET> Since we're using the juniper mail list it's worth mentioning the
>Virtual-chassis feature of JUNOS which is kinda nice I believe (didn't use
>it though). 
>
>CB>  I agree with you that Juniper VC on the MX is a fantastic feature
>and the stateful session failover is great but I would still like to see
>a last-line-of-defence in case a software bug or ISSU failure brings down
>the entire VC in one hit.
ET> I believe that's always a limitation of using a single Virtual device
instead on two distinct boxes. Some kind of tradeoff I would say.

> 
>-- 
>This transmission or any part of it is intended solely for the named
>
>addressee.  It is confidential.  The copying or distribution of this
>
>transmission or any information it contains, by anyone other than the
>
>addressee, is prohibited. CommTel Network Solutions cannot be held
>
>accountable for any comments, statements or attachments.
>
>
>
>If you have received this transmission in error, please phone
>
>  +61 3 8340 6100  or by reply e-mail to the sender.  If you are not the
>
>named addressee, you must destroy the original transmission and its
>contents. 
>
>
>
>You may not rely on electronically transmitted material unless
>
>requested that the transmission is subsequently confirmed by fax or
>letter.
>
>Material transmitted to you should also be checked by reference
>
>to a hard copy of that material printed directly from our word processing
>system.
>
>Message  protected by MailGuard: e-mail anti-virus, anti-spam and content
>filtering.http://www.mailguard.com.au/mg
>




More information about the juniper-nsp mailing list