[rbak-nsp] No Calling-Station-Id when acting as LAC

[Jim Tyrrell]

No I never did get that working.   Its on my list of things to look into 
when we upgrade to SEOS 11,  I had hoped it would just work once we had 
done the upgrades but I guess not if you are on 11.

Once I have an SEOS11 node to test, if it still doesnt work I'll raise 
it with Ericsson but that wont be for a while.

Let me know if you make any progress in the meantime.

Jim.

On 12/03/2013 07:20, Soe Prapti wrote:
> Hi Jim,
>
> I also get same problem with you, have you get the solution ? in Seos 
> version 11 for calling-station-id is only :
>
> agent-circuit-id  Build Calling-ID string with agent circuit id
> agent-remote-id   Build Calling-ID string with agent remote id
> description       Build Calling-ID string with VC-description
> hostname          Build Calling-ID string with host name
> slot-port         Build Calling-ID string with slot-port info
>
> Regards
>
>
> On Thu, Oct 25, 2012 at 6:51 PM, Jim Tyrrell <jim at scusting.com 
> <mailto:jim at scusting.com>> wrote:
>
>
>     On 12/10/2012 08:34, Peter W wrote:
>
>         Hi Jim,
>
>         Am 11.10.2012 15:33, schrieb Jim Tyrrell:
>
>             I'm seeing a users Calling-Station-Id received  in RADIUS
>             when our
>             SmartEdge 600 is acting as an LNS and terminating a
>             connection, but if
>             we act as LAC and tunnel the connection onward we do not
>             see the
>             Calling-Station-Id.  Is this a bug or do I need to enable
>             something to
>             report the calling detail when we are functioning as a LAC?
>
>             I have seen the RADIUS data for the remote LNS, and that
>             is reporting
>             the correct CLI data, so our SmartEdge is definately
>             seeing the AVP's
>             and passing that onto the remote LNS, why is it not
>             reporting it via
>             RADIUS though?
>
>         what kind of information do you expect in Calling-Station-Id?
>
>         It must be specified with:
>
>         [local]LAC1(config-ctx)#radius attribute calling-station-id
>         format ?
>            agent-circuit-id  Build Calling-ID string with agent circuit id
>            agent-remote-id   Build Calling-ID string with agent remote id
>            description       Build Calling-ID string with VC-description
>            hostname          Build Calling-ID string with host name
>            slot-port         Build Calling-ID string with slot-port info
>
>         Best Regards,
>                 Peter.
>
>
>     I'm expecting the MAC address that we get from our supplier to be
>     reported to RADIUS in Calling-Station-Id.  If we terminate the
>     session on our SE600 then "show subscribers active username x"
>     shows 'calling-id 2cb0.5d8d.7aad' and this value is also reported
>     in RADIUS Calling-Station-Id.
>
>     If we act as a LAC for this session and tunnel to our customers
>     LNS then we dont see calling-id values in the Users session, and
>     Calling-Station-Id is not reported to RADIUS.
>
>     In both scenarios we see the MAC address being reported to us in
>     the AVP debug:
>
>     Oct 25 12:20:34: %L2TP-7-AVP:  M  Len=14 IETF
>     Dialing-Number=2cb0.5d8d.7aad
>
>     Our customer sees the correct Calling-Station-Id on their LNS and
>     RADIUS so its definately there, just not in our local User infomation.
>
>     I tried using the suggested 'radius attribute calling-station-id
>     format' but all I got was "Agent-Circuit-Id Not Present" or
>     "Remote-Agent-Id Not Present" for both LNS and LAC sessions.
>
>     thanks.
>
>     Jim.
>
>
>
>
>
>     _______________________________________________
>     redback-nsp mailing list
>     redback-nsp at puck.nether.net <mailto:redback-nsp at puck.nether.net>
>     https://puck.nether.net/mailman/listinfo/redback-nsp
>
>
>
>
> -- 
> Regards,
>
> Suparti
> 081384850602
>
>
> _______________________________________________
> redback-nsp mailing list
> redback-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/redback-nsp


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/redback-nsp/attachments/20130312/4d2f4181/attachment.html>