Hi James, Oops — sorry, I completely missed your response.
On 22 Jul 2014, at 15:04, James Bensley <[email protected]> wrote: > […snip…] > 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. rjs> It’s not actually “large customers” here — the difference is that one may buy Wholesale Broadband Connect (WBC, SIN 472) which requires connectivity directly at a POSI, and a dedicated forwarding context within our network (+dedicated WBC MSILs), or Wholesale Broadband Managed Connect (WBMC, SIN471). WBMC Shared is itself a WBC customer, but aggregates so that each CP does not need its own forwarding context and MSILs. Larger customers will usually buy WBC, but might also buy WBMC Shared - it depends upon the time at which it is worth having ones own MSILs. > > 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. rjs> Apologies, this was my mistake in the previous e-mail. WBMC Shared RADIUS (as you’ve discovered) currently has different behaviour to WBC Platform RADIUS. > [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 > :) rjs> It’s simply that each CP within WBC has it’s own forwarding table in the BRAS, such that we can have different CPs using PTA who announce their own default routes, and route traffic to that particular CP’s infrastructure. Kind regards and apologies for missing the previous mail, r.
