Mailing List Archive

> 5300 - 12.2.15T8
> ----------------
> This is from the start acct packet:

> connect-info=33600/31200 V34+/V42bis/LAPM (33600/28800)

> This is from the Stop acct packet

> connect-info=45333/31200 V90/V44/LAPM (50666/31200)

> Both are from the same user's session.

These must be from DIFFERENT sessions.

a) you will never change compression protocols within a modem call
b) although you may retrain from V.90 down to V.34, you will never
retrain from V.34 up to V.90.

Aaron

---

> From
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t11/ftattr77.htm#xtocid8
> "If the modem negotiation speeds are different, the speeds are shown in a
> bracket format at the end of the call."

> What could be a good explanation in my example?

> --
> ***************************************
> Chatzithomaoglou Anastasios
> Network Design & Development Department
> FORTHnet S.A.
> <achatz@forthnet.gr>
> ***************************************

> _______________________________________________
> cisco-nas mailing list
> cisco-nas@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nas

That's what i though too...but watch the "task_id" = session-id in start/stop records and
the elapsed_time=1140 which is equal to the difference between start-time and stop-time.

Wed Nov 26 10:49:40 2003 194.219.x.x userx Async6 xxx|xxx Start
task_id=000571C9 service=PPP addr=213.16.x.x bytes_in= bytes_out=
disc-cause= elapsed_time= nas-rx-speed= nas-tx-speed= Acct-Multi-Session-Id=
connect-info=33600/31200 V34+/V42bis/LAPM (33600/28800)

Wed Nov 26 11:08:36 2003 194.219.x.x userx Async6 xxx|xxx Stop
task_id=000571C9 service=PPP addr=213.16.x.x bytes_in=849018
bytes_out=5093255 disc-cause=pppRcvTerminate elapsed_time=1140
nas-rx-speed=45333 nas-tx-speed=31200 Acct-Multi-Session-Id=
connect-info=45333/31200 V90/V44/LAPM (50666/31200)

Of cource the Stop record seems to be the correct one, because nas-tx/rx-speeds (swapped)
agree to connect-info.

Aaron Leonard wrote:

>> 5300 - 12.2.15T8
>> ----------------
>> This is from the start acct packet:
>
>
>> connect-info=33600/31200 V34+/V42bis/LAPM (33600/28800)
>
>
>> This is from the Stop acct packet
>
>
>> connect-info=45333/31200 V90/V44/LAPM (50666/31200)
>
>
>> Both are from the same user's session.
>
>
> These must be from DIFFERENT sessions.
> a) you will never change compression protocols within a modem call
> b) although you may retrain from V.90 down to V.34, you will never
> retrain from V.34 up to V.90.
>
> Aaron
>
> ---
>
>> From
>> http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t11/ftattr77.htm#xtocid8
>>
>> "If the modem negotiation speeds are different, the speeds are shown in a
>> bracket format at the end of the call."
>
>
>> What could be a good explanation in my example?
>
>
>> --
>> ***************************************
>> Chatzithomaoglou Anastasios
>> Network Design & Development Department
>> FORTHnet S.A.
>> <achatz@forthnet.gr>
>> ***************************************
>
>
>> _______________________________________________
>> cisco-nas mailing list
>> cisco-nas@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nas
>
>
>

--
***************************************
Chatzithomaoglou Anastasios
Network Design & Development Department
FORTHnet S.A.
<achatz@forthnet.gr>
***************************************

Maybe in the start record, AAA accounting had grabbed some stale
info from the previous call?

---

> That's what i though too...but watch the "task_id" = session-id in start/stop records and
> the elapsed_time=1140 which is equal to the difference between start-time and stop-time.

> Wed Nov 26 10:49:40 2003 194.219.x.x userx Async6 xxx|xxx Start
> task_id=000571C9 service=PPP addr=213.16.x.x bytes_in= bytes_out=
> disc-cause= elapsed_time= nas-rx-speed= nas-tx-speed= Acct-Multi-Session-Id=
> connect-info=33600/31200 V34+/V42bis/LAPM (33600/28800)

> Wed Nov 26 11:08:36 2003 194.219.x.x userx Async6 xxx|xxx Stop
> task_id=000571C9 service=PPP addr=213.16.x.x bytes_in=849018
> bytes_out=5093255 disc-cause=pppRcvTerminate elapsed_time=1140
> nas-rx-speed=45333 nas-tx-speed=31200 Acct-Multi-Session-Id=
> connect-info=45333/31200 V90/V44/LAPM (50666/31200)

> Of cource the Stop record seems to be the correct one, because nas-tx/rx-speeds (swapped)
> agree to connect-info.

> Aaron Leonard wrote:

> >> 5300 - 12.2.15T8
> >> ----------------
> >> This is from the start acct packet:
> >
> >
> >> connect-info=33600/31200 V34+/V42bis/LAPM (33600/28800)
> >
> >
> >> This is from the Stop acct packet
> >
> >
> >> connect-info=45333/31200 V90/V44/LAPM (50666/31200)
> >
> >
> >> Both are from the same user's session.
> >
> >
> > These must be from DIFFERENT sessions.
> > a) you will never change compression protocols within a modem call
> > b) although you may retrain from V.90 down to V.34, you will never
> > retrain from V.34 up to V.90.
> >
> > Aaron
> >
> > ---
> >
> >> From
> >> http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t11/ftattr77.htm#xtocid8
> >>
> >> "If the modem negotiation speeds are different, the speeds are shown in a
> >> bracket format at the end of the call."
> >
> >
> >> What could be a good explanation in my example?
> >
> >
> >> --
> >> ***************************************
> >> Chatzithomaoglou Anastasios
> >> Network Design & Development Department
> >> FORTHnet S.A.
> >> <achatz@forthnet.gr>
> >> ***************************************
> >
> >
> >> _______________________________________________
> >> cisco-nas mailing list
> >> cisco-nas@puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/cisco-nas
> >
> >
> >

> --
> ***************************************
> Chatzithomaoglou Anastasios
> Network Design & Development Department
> FORTHnet S.A.
> <achatz@forthnet.gr>
> ***************************************

How could this be done? A bug on our radius?

Aaron Leonard wrote:

> Maybe in the start record, AAA accounting had grabbed some stale
> info from the previous call?
>
> ---
>
>> That's what i though too...but watch the "task_id" = session-id in
>> start/stop records and
>> the elapsed_time=1140 which is equal to the difference between
>> start-time and stop-time.
>
>
>> Wed Nov 26 10:49:40 2003 194.219.x.x userx Async6 xxx|xxx Start
>> task_id=000571C9 service=PPP addr=213.16.x.x
>> bytes_in= bytes_out=
>> disc-cause= elapsed_time= nas-rx-speed= nas-tx-speed=
>> Acct-Multi-Session-Id=
>> connect-info=33600/31200 V34+/V42bis/LAPM (33600/28800)
>
>
>> Wed Nov 26 11:08:36 2003 194.219.x.x userx Async6 xxx|xxx Stop
>> task_id=000571C9 service=PPP addr=213.16.x.x
>> bytes_in=849018
>> bytes_out=5093255 disc-cause=pppRcvTerminate elapsed_time=1140
>> nas-rx-speed=45333 nas-tx-speed=31200 Acct-Multi-Session-Id=
>> connect-info=45333/31200 V90/V44/LAPM (50666/31200)
>
>
>> Of cource the Stop record seems to be the correct one, because
>> nas-tx/rx-speeds (swapped)
>> agree to connect-info.
>
>
>> Aaron Leonard wrote:
>
>
>> >> 5300 - 12.2.15T8
>> >> ----------------
>> >> This is from the start acct packet:
>> >
>> >
>> >> connect-info=33600/31200 V34+/V42bis/LAPM (33600/28800)
>> >
>> >
>> >> This is from the Stop acct packet
>> >
>> >
>> >> connect-info=45333/31200 V90/V44/LAPM (50666/31200)
>> >
>> >
>> >> Both are from the same user's session.
>> >
>> >
>> > These must be from DIFFERENT sessions.
>> > a) you will never change compression protocols within a modem call
>> > b) although you may retrain from V.90 down to V.34, you will never
>> > retrain from V.34 up to V.90.
>> >
>> > Aaron
>> >
>> > ---
>> >
>> >> From
>> >>
>> http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t11/ftattr77.htm#xtocid8
>>
>> >>
>> >> "If the modem negotiation speeds are different, the speeds are
>> shown in a
>> >> bracket format at the end of the call."
>> >
>> >
>> >> What could be a good explanation in my example?
>> >
>> >
>> >> --
>> >> ***************************************
>> >> Chatzithomaoglou Anastasios
>> >> Network Design & Development Department
>> >> FORTHnet S.A.
>> >> <achatz@forthnet.gr>
>> >> ***************************************
>> >
>> >
>> >> _______________________________________________
>> >> cisco-nas mailing list
>> >> cisco-nas@puck.nether.net
>> >> https://puck.nether.net/mailman/listinfo/cisco-nas
>> >
>> >
>> >
>
>
>> --
>> ***************************************
>> Chatzithomaoglou Anastasios
>> Network Design & Development Department
>> FORTHnet S.A.
>> <achatz@forthnet.gr>
>> ***************************************
>
>
>

--
***************************************
Chatzithomaoglou Anastasios
Network Design & Development Department
FORTHnet S.A.
<achatz@forthnet.gr>
***************************************

From your description so far, it sounds like it could be a bug
in IOS RADIUS.

How about this one:

CSCdy25116
Externally found severe defect: Resolved (R)
Radius Connect-Info attribute contains extraneous information

Release-note: Added 020801

When analog and HDLC calls are mixed on CSMV6, the
Radius attribute Connect-Info for the HDLC call that
is brought up after the analog call, contains information
from the previous analog call on that port.

This problem doesn't have any known workaround.

Version: 12.2(02)XB07
To-be-fixed: 12.2(02)XB07
Integrated-releases: 12.2(15)BX 12.2(15)ZN 12.2(15)BZ 12.2(15)BW 12.2(13.03)B 12.2(02)XB08 12.2(12.07)PI06 12.2(12.05)T

Aaron

---

> How could this be done? A bug on our radius?

> Aaron Leonard wrote:

> > Maybe in the start record, AAA accounting had grabbed some stale
> > info from the previous call?
> >
> > ---
> >
> >> That's what i though too...but watch the "task_id" = session-id in
> >> start/stop records and
> >> the elapsed_time=1140 which is equal to the difference between
> >> start-time and stop-time.
> >
> >
> >> Wed Nov 26 10:49:40 2003 194.219.x.x userx Async6 xxx|xxx Start
> >> task_id=000571C9 service=PPP addr=213.16.x.x
> >> bytes_in= bytes_out=
> >> disc-cause= elapsed_time= nas-rx-speed= nas-tx-speed=
> >> Acct-Multi-Session-Id=
> >> connect-info=33600/31200 V34+/V42bis/LAPM (33600/28800)
> >
> >
> >> Wed Nov 26 11:08:36 2003 194.219.x.x userx Async6 xxx|xxx Stop
> >> task_id=000571C9 service=PPP addr=213.16.x.x
> >> bytes_in=849018
> >> bytes_out=5093255 disc-cause=pppRcvTerminate elapsed_time=1140
> >> nas-rx-speed=45333 nas-tx-speed=31200 Acct-Multi-Session-Id=
> >> connect-info=45333/31200 V90/V44/LAPM (50666/31200)
> >
> >
> >> Of cource the Stop record seems to be the correct one, because
> >> nas-tx/rx-speeds (swapped)
> >> agree to connect-info.
> >
> >
> >> Aaron Leonard wrote:
> >
> >
> >> >> 5300 - 12.2.15T8
> >> >> ----------------
> >> >> This is from the start acct packet:
> >> >
> >> >
> >> >> connect-info=33600/31200 V34+/V42bis/LAPM (33600/28800)
> >> >
> >> >
> >> >> This is from the Stop acct packet
> >> >
> >> >
> >> >> connect-info=45333/31200 V90/V44/LAPM (50666/31200)
> >> >
> >> >
> >> >> Both are from the same user's session.
> >> >
> >> >
> >> > These must be from DIFFERENT sessions.
> >> > a) you will never change compression protocols within a modem call
> >> > b) although you may retrain from V.90 down to V.34, you will never
> >> > retrain from V.34 up to V.90.
> >> >
> >> > Aaron
> >> >
> >> > ---
> >> >
> >> >> From
> >> >>
> >> http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t11/ftattr77.htm#xtocid8
> >>
> >> >>
> >> >> "If the modem negotiation speeds are different, the speeds are
> >> shown in a
> >> >> bracket format at the end of the call."
> >> >
> >> >
> >> >> What could be a good explanation in my example?
> >> >
> >> >
> >> >> --
> >> >> ***************************************
> >> >> Chatzithomaoglou Anastasios
> >> >> Network Design & Development Department
> >> >> FORTHnet S.A.
> >> >> <achatz@forthnet.gr>
> >> >> ***************************************
> >> >
> >> >
> >> >> _______________________________________________
> >> >> cisco-nas mailing list
> >> >> cisco-nas@puck.nether.net
> >> >> https://puck.nether.net/mailman/listinfo/cisco-nas
> >> >
> >> >
> >> >
> >
> >
> >> --
> >> ***************************************
> >> Chatzithomaoglou Anastasios
> >> Network Design & Development Department
> >> FORTHnet S.A.
> >> <achatz@forthnet.gr>
> >> ***************************************
> >
> >
> >

> --
> ***************************************
> Chatzithomaoglou Anastasios
> Network Design & Development Department
> FORTHnet S.A.
> <achatz@forthnet.gr>
> ***************************************

> _______________________________________________
> cisco-nas mailing list
> cisco-nas@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nas

It could be the reason, but i'm using AS5300 - 12.2.15T7-9


Aaron Leonard wrote:

>> From your description so far, it sounds like it could be a bug
>
> in IOS RADIUS.
>
> How about this one:
>
> CSCdy25116
> Externally found severe defect: Resolved (R)
> Radius Connect-Info attribute contains extraneous information
>
> Release-note: Added 020801
>
> When analog and HDLC calls are mixed on CSMV6, the
> Radius attribute Connect-Info for the HDLC call that is brought up after
> the analog call, contains information
> from the previous analog call on that port.
>
> This problem doesn't have any known workaround.
>
> Version: 12.2(02)XB07
> To-be-fixed: 12.2(02)XB07
> Integrated-releases: 12.2(15)BX 12.2(15)ZN 12.2(15)BZ 12.2(15)BW
> 12.2(13.03)B 12.2(02)XB08 12.2(12.07)PI06 12.2(12.05)T
>
> Aaron
>
> ---
>
>> How could this be done? A bug on our radius?
>
>
>> Aaron Leonard wrote:
>
>
>> > Maybe in the start record, AAA accounting had grabbed some stale
>> > info from the previous call?
>> >
>> > ---
>> >
>> >> That's what i though too...but watch the "task_id" = session-id in
>> >> start/stop records and
>> >> the elapsed_time=1140 which is equal to the difference between
>> >> start-time and stop-time.
>> >
>> >
>> >> Wed Nov 26 10:49:40 2003 194.219.x.x userx Async6 xxx|xxx
>> Start
>> >> task_id=000571C9 service=PPP addr=213.16.x.x
>> >> bytes_in= bytes_out=
>> >> disc-cause= elapsed_time= nas-rx-speed= nas-tx-speed=
>> >> Acct-Multi-Session-Id=
>> >> connect-info=33600/31200 V34+/V42bis/LAPM (33600/28800)
>> >
>> >
>> >> Wed Nov 26 11:08:36 2003 194.219.x.x userx Async6 xxx|xxx
>> Stop
>> >> task_id=000571C9 service=PPP addr=213.16.x.x
>> >> bytes_in=849018
>> >> bytes_out=5093255 disc-cause=pppRcvTerminate
>> elapsed_time=1140
>> >> nas-rx-speed=45333 nas-tx-speed=31200 Acct-Multi-Session-Id=
>> >> connect-info=45333/31200 V90/V44/LAPM (50666/31200)
>> >
>> >
>> >> Of cource the Stop record seems to be the correct one, because
>> >> nas-tx/rx-speeds (swapped)
>> >> agree to connect-info.
>> >
>> >
>> >> Aaron Leonard wrote:
>> >
>> >
>> >> >> 5300 - 12.2.15T8
>> >> >> ----------------
>> >> >> This is from the start acct packet:
>> >> >
>> >> >
>> >> >> connect-info=33600/31200 V34+/V42bis/LAPM (33600/28800)
>> >> >
>> >> >
>> >> >> This is from the Stop acct packet
>> >> >
>> >> >
>> >> >> connect-info=45333/31200 V90/V44/LAPM (50666/31200)
>> >> >
>> >> >
>> >> >> Both are from the same user's session.
>> >> >
>> >> >
>> >> > These must be from DIFFERENT sessions.
>> >> > a) you will never change compression protocols within a modem call
>> >> > b) although you may retrain from V.90 down to V.34, you will never
>> >> > retrain from V.34 up to V.90.
>> >> >
>> >> > Aaron
>> >> >
>> >> > ---
>> >> >
>> >> >> From
>> >> >>
>> >>
>> http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t11/ftattr77.htm#xtocid8
>>
>> >>
>> >> >>
>> >> >> "If the modem negotiation speeds are different, the speeds are
>> >> shown in a
>> >> >> bracket format at the end of the call."
>> >> >
>> >> >
>> >> >> What could be a good explanation in my example?
>> >> >
>> >> >
>> >> >> --
>> >> >> ***************************************
>> >> >> Chatzithomaoglou Anastasios
>> >> >> Network Design & Development Department
>> >> >> FORTHnet S.A.
>> >> >> <achatz@forthnet.gr>
>> >> >> ***************************************
>> >> >
>> >> >
>> >> >> _______________________________________________
>> >> >> cisco-nas mailing list
>> >> >> cisco-nas@puck.nether.net
>> >> >> https://puck.nether.net/mailman/listinfo/cisco-nas
>> >> >
>> >> >
>> >> >
>> >
>> >
>> >> --
>> >> ***************************************
>> >> Chatzithomaoglou Anastasios
>> >> Network Design & Development Department
>> >> FORTHnet S.A.
>> >> <achatz@forthnet.gr>
>> >> ***************************************
>> >
>> >
>> >
>
>
>> --
>> ***************************************
>> Chatzithomaoglou Anastasios
>> Network Design & Development Department
>> FORTHnet S.A.
>> <achatz@forthnet.gr>
>> ***************************************
>
>
>> _______________________________________________
>> cisco-nas mailing list
>> cisco-nas@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nas
>
>
>

--
***************************************
Chatzithomaoglou Anastasios
Network Design & Development Department
FORTHnet S.A.
<achatz@forthnet.gr>
***************************************

Then maybe MICA calls are susceptible to the CSCdy25116 problem
as well. I couldn't find a matching DDTS for this, so perhaps
this problem is still present in current IOS.

Aaron

---

> It could be the reason, but i'm using AS5300 - 12.2.15T7-9


> Aaron Leonard wrote:

> >> From your description so far, it sounds like it could be a bug
> >
> > in IOS RADIUS.
> >
> > How about this one:
> >
> > CSCdy25116
> > Externally found severe defect: Resolved (R)
> > Radius Connect-Info attribute contains extraneous information
> >
> > Release-note: Added 020801
> >
> > When analog and HDLC calls are mixed on CSMV6, the
> > Radius attribute Connect-Info for the HDLC call that is brought up after
> > the analog call, contains information
> > from the previous analog call on that port.
> >
> > This problem doesn't have any known workaround.
> >
> > Version: 12.2(02)XB07
> > To-be-fixed: 12.2(02)XB07
> > Integrated-releases: 12.2(15)BX 12.2(15)ZN 12.2(15)BZ 12.2(15)BW
> > 12.2(13.03)B 12.2(02)XB08 12.2(12.07)PI06 12.2(12.05)T
> >
> > Aaron
> >
> > ---
> >
> >> How could this be done? A bug on our radius?
> >
> >
> >> Aaron Leonard wrote:
> >
> >
> >> > Maybe in the start record, AAA accounting had grabbed some stale
> >> > info from the previous call?
> >> >
> >> > ---
> >> >
> >> >> That's what i though too...but watch the "task_id" = session-id in
> >> >> start/stop records and
> >> >> the elapsed_time=1140 which is equal to the difference between
> >> >> start-time and stop-time.
> >> >
> >> >
> >> >> Wed Nov 26 10:49:40 2003 194.219.x.x userx Async6 xxx|xxx
> >> Start
> >> >> task_id=000571C9 service=PPP addr=213.16.x.x
> >> >> bytes_in= bytes_out=
> >> >> disc-cause= elapsed_time= nas-rx-speed= nas-tx-speed=
> >> >> Acct-Multi-Session-Id=
> >> >> connect-info=33600/31200 V34+/V42bis/LAPM (33600/28800)
> >> >
> >> >
> >> >> Wed Nov 26 11:08:36 2003 194.219.x.x userx Async6 xxx|xxx
> >> Stop
> >> >> task_id=000571C9 service=PPP addr=213.16.x.x
> >> >> bytes_in=849018
> >> >> bytes_out=5093255 disc-cause=pppRcvTerminate
> >> elapsed_time=1140
> >> >> nas-rx-speed=45333 nas-tx-speed=31200 Acct-Multi-Session-Id=
> >> >> connect-info=45333/31200 V90/V44/LAPM (50666/31200)
> >> >
> >> >
> >> >> Of cource the Stop record seems to be the correct one, because
> >> >> nas-tx/rx-speeds (swapped)
> >> >> agree to connect-info.
> >> >
> >> >
> >> >> Aaron Leonard wrote:
> >> >
> >> >
> >> >> >> 5300 - 12.2.15T8
> >> >> >> ----------------
> >> >> >> This is from the start acct packet:
> >> >> >
> >> >> >
> >> >> >> connect-info=33600/31200 V34+/V42bis/LAPM (33600/28800)
> >> >> >
> >> >> >
> >> >> >> This is from the Stop acct packet
> >> >> >
> >> >> >
> >> >> >> connect-info=45333/31200 V90/V44/LAPM (50666/31200)
> >> >> >
> >> >> >
> >> >> >> Both are from the same user's session.
> >> >> >
> >> >> >
> >> >> > These must be from DIFFERENT sessions.
> >> >> > a) you will never change compression protocols within a modem call
> >> >> > b) although you may retrain from V.90 down to V.34, you will never
> >> >> > retrain from V.34 up to V.90.
> >> >> >
> >> >> > Aaron
> >> >> >
> >> >> > ---
> >> >> >
> >> >> >> From
> >> >> >>
> >> >>
> >> http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t11/ftattr77.htm#xtocid8
> >>
> >> >>
> >> >> >>
> >> >> >> "If the modem negotiation speeds are different, the speeds are
> >> >> shown in a
> >> >> >> bracket format at the end of the call."
> >> >> >
> >> >> >
> >> >> >> What could be a good explanation in my example?
> >> >> >
> >> >> >
> >> >> >> --
> >> >> >> ***************************************
> >> >> >> Chatzithomaoglou Anastasios
> >> >> >> Network Design & Development Department
> >> >> >> FORTHnet S.A.
> >> >> >> <achatz@forthnet.gr>
> >> >> >> ***************************************
> >> >> >
> >> >> >
> >> >> >> _______________________________________________
> >> >> >> cisco-nas mailing list
> >> >> >> cisco-nas@puck.nether.net
> >> >> >> https://puck.nether.net/mailman/listinfo/cisco-nas
> >> >> >
> >> >> >
> >> >> >
> >> >
> >> >
> >> >> --
> >> >> ***************************************
> >> >> Chatzithomaoglou Anastasios
> >> >> Network Design & Development Department
> >> >> FORTHnet S.A.
> >> >> <achatz@forthnet.gr>
> >> >> ***************************************
> >> >
> >> >
> >> >
> >
> >
> >> --
> >> ***************************************
> >> Chatzithomaoglou Anastasios
> >> Network Design & Development Department
> >> FORTHnet S.A.
> >> <achatz@forthnet.gr>
> >> ***************************************
> >
> >
> >> _______________________________________________
> >> cisco-nas mailing list
> >> cisco-nas@puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/cisco-nas
> >
> >
> >

> --
> ***************************************
> Chatzithomaoglou Anastasios
> Network Design & Development Department
> FORTHnet S.A.
> <achatz@forthnet.gr>
> ***************************************

> _______________________________________________
> cisco-nas mailing list
> cisco-nas@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nas