On 16 July 2014 11:26, James Bensley <[email protected]> wrote: > On 16 July 2014 09:11, Rob Shakir <[email protected]> wrote: >> The realm/service selection name is generally more relevant to IPStream or >> WBMC Shared (as per SIN471) rather than WBC. >> >> The issue you are facing is that the selection of authentication >> infrastructure is done on the subscriber <-> CP mapping - such that there is >> a tight coupling between the RADIUS authenticating the CP and the forwarding >> context that the authenticated user is placed into. WBC will determine the >> CP that the line belongs to, and then request RADIUS authentication from >> that particular CP’s RADIUS. Since this is the case, then your BT Business >> -> other CP migration is doing what is expected — authenticating with the >> BTB RADIUS infrastructure, rather than your own since the RADIUS is selected >> on the calling line ID (not the authentication details - which WBC passes >> transparently). The same is true with WBMC Shared CPs, the “owning CP” is >> identified, and their RADIUS infrastructure is consulted for authentication >> until such time as the migration has completed. In the WBMC Shared case the >> SSN is used to differentiate different behaviours required for different >> sets of EUs of the same CP. >> >> The potential means to ease your migration path is to ask the owning CP to >> act as a proxy RADIUS for the lines that you are migrating to your own >> infrastructure (although, this of course requires co-operation of the >> existing CP for the line) — such that your authentication details are valid >> for the subscriber on both sets of infrastructure; or alternatively >> determining a means to authenticate these lines without checking the PPP >> authentication credentials on your own infrastructure (for instance, an >> access accept that is based on the SID (BBEU/FTIP/BBIP…) — meaning that once >> the line is migrated, then your infrastructure still authenticates the user, >> regardless of the PPP username/password that is configured. > > > Hi Rob, > > Thanks for chiming in, that is greatly appreciated however what you > have said is contrary to my initial testing. > > I have connected a CPE to a WBC line and successfully authenticated > using PPP details for CP1 to which I have RADIUS access and I can see > then authentication coming in from BTW and the authentication is > successful. I have also authenticated to CP2 using their PPP details > and didn't see the authentication come in to CP1s RADIUS from BTW, CP2 > has confirmed they have the access-request and it was accepted and on > the CPE I see the PPP sesssion is up and running. > > It seems that it isn't always the case the calling ID is mapped to a > single CP. Can you expand on that at all? > > Kind regards, > James.
Through further testing and speaking with BTW we have been able to clarify the behaviour of PPP auth on WBCM services now. For WBC lines the BBEU ID locks a line to a CP. As an auth request comes in to BTW the auth is sent to the corresponding CP based on the BBEU ID look up in the BTW RADIUS. Large customers have their own "virtual-router" within the BRAS which handles this process for them, their PPP auth requests are sent to their "virtual-router" which in turns begins the L2TP process with their RADIUS and LNS platforms. So this is all true and accurate as per the BT SIN. Smaller customers on the "WBMC shared" product set use a shared "virtual-router" within the BTW BRAS so for smaller WBMC shared customers, a user can enter either CP1 or CP2 PPP authentication details and auth to either ISP which will be based on realm because both requests are sent to the shared "virtual-router" in the BTW BRAS irrelevant of the BBEU calling line ID. This allows for smaller CPs to migrate end-sites line-at-a-time by simply changing the PPP auth details and re-authenticating to the new providing CP, before or after a line has been "migrated" which is seems becomes more of a billing and ownership issue than service. It also means you can roll back to CP1 at any time as post migration their PPP details still work due to the scenario described above. Cheers, James. [1] I have no idea what a "virtual-router" within the BRAS is, maybe it is just that? That was the terminology used to describe this to me :)
