Re: [j-nsp] Multi Core on JUNOS?
Yes, routing protocols on SR OS use multiple cores (within protocols, and across protocols). Feel free to contact me off-list, or on alcatel-nsp, for further discussion. AJ Original Message From: Chris Morrow Sent: Friday, May 8, 2015 3:22 PM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Multi Core on JUNOS? On 05/08/2015 03:15 PM, Colton Conor wrote: > use multiple cores please define this better. Does their version of rpd actually get multi-threaded? and end up using more than 1 core at once? does the 'rpd' get stuck to a single core and everything else floats around on several more? this is what, in a sense, newer junos does... nothing you care about is multithreaded (or just straight smp), but the underlying fbsd is so somethings run on other cores. ___ 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] Junose (ERX) IP pool management
Gabriel, Gabriel Blanchard wrote: > We are trying to configure multiple ERXs 310 to share a Pool of IPs to > assign to DSL customers. These ERXs are acting as LNSes. > > The problem is that right now we are statically configuring each of > the ERXs with different Pools of IPs. We would like all of them to be > able to share the same Pool of IPs to ease of management. > > I believe the best way would be to configure sqlippool in our > Freeradius daemons to manage the IPs. > > Someone else here thinks that it would be possible to configure the > ERXes to relay the request to a dhcp serverI don't think it would > work. Mostly because we need to manage different types of IP pools. My recommendation here (having spent quite a bit of time building RADIUS + DHCP AAA infrastructure) is to use RADIUS. While the ERX (as pointed out) can support DHCP for subscriber IP binding, I don't think it's needed for your environment. The reasons are quite straightforwards: 1. [It sounds like] you are using RADIUS already. Introducing another control plane protocol is unnecessary, and runs the typical infrastructure issues. 2. RADIUS is a perfectly valid way to deliver IP addressing to BRAS/LNS infrastructure, with well understood and functional VSAs (either a pool hint, or a Framed-IP-Address itself). 3. If you are making policy decisions in your RADIUS AAA infrastructure today (sounds like it), and your IP address assignment for the subscriber is dependent on some policy, you have a single policy point, rather than 2. 4. You avoid maintaining a PPP <> DHCP state table in your LNS. 5. RADIUS will (through framed-ip-address/framed-route VSA) meet your needs. You will probably need to construct some robust policy logic in your RADIUS engine(s) though. There are some advantages to having DHCP infrastructure and you may want to review those if you ever look at migrating to an IPoE (TR-101) network topology. regards, aj ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
