>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 > _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
