Mailing List Archive

Hi Nathan,

Have you made a configruation mistake in your VPDN group maybe?
Perhaps you can share your config, that is always helpful.

You have this in your logs:


Jul 31 18:22:04.352: L2TP tnl 08060:________: remote ip set to
202.10.4.147
Jul 31 18:22:04.352: L2TP tnl 08060:________: local ip set to
203.111.114.28
...
Jul 31 18:22:04.352: L2TP tnl 08060:00003A1E: local ip set to
203.111.114.29

Then this:

Jul 31 18:22:11.348: L2TP _____:________: I StopCCN, flg TLS,
ver 2, len 75
...
Jul 31 18:22:11.352: L2TP _____:________: "203.111.114.28
is unreachable"
....
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Shutting down tunnel
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Result Code
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: General error -
refer to error code
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Error Code
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Vendor specific
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Vendor Error
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Tunnel shut
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Optional Message
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: "203.111.114.28 is
unreachable"

Have you got a mismatch between you "source-ip" on the VPDN group and
actual interface IP?

Cheers,
James.
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

Hi James,

I thought that solved it, I didn't have a source-ip set so I set source-ip
to .29 but it still appears to fail due to unreachable .28??

http://pastebin.com/h0cagDPk

From what I gather I get the SCCRQ and for some reason a SCCRP is not making
it back, then tunnel is killed.



-----Original Message-----
From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On Behalf Of
James Bensley
Sent: Friday, 31 July 2015 7:49 PM
To: cisco-bba@puck.nether.net
Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC

Hi Nathan,

Have you made a configruation mistake in your VPDN group maybe?
Perhaps you can share your config, that is always helpful.

You have this in your logs:


Jul 31 18:22:04.352: L2TP tnl 08060:________: remote ip set to
202.10.4.147
Jul 31 18:22:04.352: L2TP tnl 08060:________: local ip set to
203.111.114.28
...
Jul 31 18:22:04.352: L2TP tnl 08060:00003A1E: local ip set to
203.111.114.29

Then this:

Jul 31 18:22:11.348: L2TP _____:________: I StopCCN, flg TLS,
ver 2, len 75
...
Jul 31 18:22:11.352: L2TP _____:________: "203.111.114.28
is unreachable"
....
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Shutting down tunnel
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Result Code
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: General error -
refer to error code
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Error Code
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Vendor specific
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Vendor Error
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Tunnel shut
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Optional Message
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: "203.111.114.28 is
unreachable"

Have you got a mismatch between you "source-ip" on the VPDN group and actual
interface IP?

Cheers,
James.
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

Hi Wayne,



Thankyou we have progress!!! This shows how laziness causes problems later, when we setup the call termination service 3 years ago I had to specifically route 2 ranges through a private lan.



202.10.4.0/28

202.10.4.16/28



Stupid me decided to be lazy and do the below on our core switch the 7204vxr connects to save typing both out



ip route 202.10.4.0 255.255.255.0 10.239.238.121



turns out they use 202.10.4.128/25 for the LACs across all the states..



Fixed the above and I can at least ping it now :)



Sending 5, 100-byte ICMP Echos to 202.10.4.147, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms



Tunnel wont attempts again until modem tries connecting to LAC, it slows down reattempts as time goes on, seeing if I can get it restarted. We have progress!





From: Wayne Lee [mailto:linkconnect@googlemail.com]
Sent: Friday, 31 July 2015 8:47 PM
To: Nathan Downes <nathandownes@hotmail.com>
Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC



How are you getting back to 202.10.4.147



You will need a route back to the tunnel sources



On 31 July 2015 at 11:38, Nathan Downes <nathandownes@hotmail.com <mailto:nathandownes@hotmail.com> > wrote:

Hi James,

I thought that solved it, I didn't have a source-ip set so I set source-ip
to .29 but it still appears to fail due to unreachable .28??

http://pastebin.com/h0cagDPk

From what I gather I get the SCCRQ and for some reason a SCCRP is not making
it back, then tunnel is killed.




-----Original Message-----
From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net <mailto:cisco-bba-bounces@puck.nether.net> ] On Behalf Of
James Bensley
Sent: Friday, 31 July 2015 7:49 PM
To: cisco-bba@puck.nether.net <mailto:cisco-bba@puck.nether.net>
Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC

Hi Nathan,

Have you made a configruation mistake in your VPDN group maybe?
Perhaps you can share your config, that is always helpful.

You have this in your logs:


Jul 31 18:22:04.352: L2TP tnl 08060:________: remote ip set to
202.10.4.147
Jul 31 18:22:04.352: L2TP tnl 08060:________: local ip set to
203.111.114.28
...
Jul 31 18:22:04.352: L2TP tnl 08060:00003A1E: local ip set to
203.111.114.29

Then this:

Jul 31 18:22:11.348: L2TP _____:________: I StopCCN, flg TLS,
ver 2, len 75
...
Jul 31 18:22:11.352: L2TP _____:________: "203.111.114.28
is unreachable"
....
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Shutting down tunnel
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Result Code
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: General error -
refer to error code
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Error Code
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Vendor specific
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Vendor Error
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Tunnel shut
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Optional Message
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: "203.111.114.28 is
unreachable"

Have you got a mismatch between you "source-ip" on the VPDN group and actual
interface IP?

Cheers,
James.
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net <mailto:cisco-bba@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-bba
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net <mailto:cisco-bba@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-bba

Nathan,



In my experience it’s best to stuff the interfaces facing the provider in a VRF, and point a default route out to their gateway. This way if they add new routes in the future (for new LACs), you don’t need to make any changes. This also works very well when you have multiple loop providers that use private address ranges for their LAC networks, as it ensures you don’t have any conflicts with your routing.



One provider in particular up here in Canuckistan likes to add new LAC subnets without telling anyone, then migrate customers to new LACs on these subnets and leave the ISPs to figure out why hundreds or thousands of their customers are down.



Cheers,


GTG



From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On Behalf Of Nathan Downes
Sent: July 31, 2015 6:49 PM
To: cisco-bba@puck.nether.net
Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC



Hi Wayne,



Thankyou we have progress!!! This shows how laziness causes problems later, when we setup the call termination service 3 years ago I had to specifically route 2 ranges through a private lan.



202.10.4.0/28

202.10.4.16/28



Stupid me decided to be lazy and do the below on our core switch the 7204vxr connects to save typing both out



ip route 202.10.4.0 255.255.255.0 10.239.238.121



turns out they use 202.10.4.128/25 for the LACs across all the states..



Fixed the above and I can at least ping it now J



Sending 5, 100-byte ICMP Echos to 202.10.4.147, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms



Tunnel wont attempts again until modem tries connecting to LAC, it slows down reattempts as time goes on, seeing if I can get it restarted. We have progress!





From: Wayne Lee [mailto:linkconnect@googlemail.com]
Sent: Friday, 31 July 2015 8:47 PM
To: Nathan Downes <nathandownes@hotmail.com>
Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC



How are you getting back to 202.10.4.147



You will need a route back to the tunnel sources



On 31 July 2015 at 11:38, Nathan Downes <nathandownes@hotmail.com> wrote:

Hi James,

I thought that solved it, I didn't have a source-ip set so I set source-ip
to .29 but it still appears to fail due to unreachable .28??

http://pastebin.com/h0cagDPk

From what I gather I get the SCCRQ and for some reason a SCCRP is not making
it back, then tunnel is killed.




-----Original Message-----
From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On Behalf Of
James Bensley
Sent: Friday, 31 July 2015 7:49 PM
To: cisco-bba@puck.nether.net
Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC

Hi Nathan,

Have you made a configruation mistake in your VPDN group maybe?
Perhaps you can share your config, that is always helpful.

You have this in your logs:


Jul 31 18:22:04.352: L2TP tnl 08060:________: remote ip set to
202.10.4.147
Jul 31 18:22:04.352: L2TP tnl 08060:________: local ip set to
203.111.114.28
...
Jul 31 18:22:04.352: L2TP tnl 08060:00003A1E: local ip set to
203.111.114.29

Then this:

Jul 31 18:22:11.348: L2TP _____:________: I StopCCN, flg TLS,
ver 2, len 75
...
Jul 31 18:22:11.352: L2TP _____:________: "203.111.114.28
is unreachable"
....
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Shutting down tunnel
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Result Code
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: General error -
refer to error code
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Error Code
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Vendor specific
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Vendor Error
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Tunnel shut
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: Optional Message
Jul 31 18:22:11.352: L2TP tnl 08060:00003A1E: "203.111.114.28 is
unreachable"

Have you got a mismatch between you "source-ip" on the VPDN group and actual
interface IP?

Cheers,
James.
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

On 5 August 2015 at 22:06, Gary T. Giesen <ggiesen+cisco-bba@giesen.me> wrote:
> In my experience it’s best to stuff the interfaces facing the provider in a
> VRF, and point a default route out to their gateway. This way if they add
> new routes in the future (for new LACs), you don’t need to make any changes.
> This also works very well when you have multiple loop providers that use
> private address ranges for their LAC networks, as it ensures you don’t have
> any conflicts with your routing.


Agreed, this is what I have been doing too. VRF per loop provider with
multiple sub-interfaces, one for each loop provider one per loop
provider per service, with a default route. Keeps the traffic seperate
and easily measurable and a simple config to manage.

James.
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

I will look into this, might make things easier. I am not a cisco expert so slowly learning things as I need them. Takes a lot of reading and research to implement something new :) I ended up finding out that the provider was sending to the host address rather than the one I had allocated. .28 /30 and I was using .29. Tunnel came up after they fixed that but no traffic would flow until I corrected the routing.

I am upgrading to an ASR 1004 for our core soon as I need netflow for some laws here, would it be better to use for termination than the 7204? Not a huge amount of traffic yet so guess I may as well leave it until necessary to replace with more power.

I find it kind of funny that in the end it was 9 lines of config changes that changed to terminate this whole new service. I also had to create a new virtual template with a lower mss for it to work properly.

-----Original Message-----
From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On Behalf Of James Bensley
Sent: Monday, 10 August 2015 7:39 PM
To: cisco-bba@puck.nether.net
Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC

On 5 August 2015 at 22:06, Gary T. Giesen <ggiesen+cisco-bba@giesen.me> wrote:
> In my experience it’s best to stuff the interfaces facing the provider
> in a VRF, and point a default route out to their gateway. This way if
> they add new routes in the future (for new LACs), you don’t need to make any changes.
> This also works very well when you have multiple loop providers that
> use private address ranges for their LAC networks, as it ensures you
> don’t have any conflicts with your routing.


Agreed, this is what I have been doing too. VRF per loop provider with multiple sub-interfaces, one for each loop provider one per loop provider per service, with a default route. Keeps the traffic seperate and easily measurable and a simple config to manage.

James.
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

What kind of NPE in the 7204? I've used 7206 NPE-G1's and they work fairly well at small scale (less than 1000 subs), the G2 is better as it supports more features (particularly things like QoS).

ASR1k's are great LNS boxes, just have to be careful when migrating from 7200's to ASRs as they are a lot more strict about what RADIUS attributes you can use and may cause you lots of frustration trying to figure it out. In particular they don't support full Virtual-Access interfaces (only sub-interfaces) so any attribute that requires a full Virtual-Access interface will not work.

GTG

-----Original Message-----
From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On Behalf Of Nathan Downes
Sent: August-10-15 6:35 AM
To: cisco-bba@puck.nether.net
Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC

I will look into this, might make things easier. I am not a cisco expert so slowly learning things as I need them. Takes a lot of reading and research to implement something new :) I ended up finding out that the provider was sending to the host address rather than the one I had allocated. .28 /30 and I was using .29. Tunnel came up after they fixed that but no traffic would flow until I corrected the routing.

I am upgrading to an ASR 1004 for our core soon as I need netflow for some laws here, would it be better to use for termination than the 7204? Not a huge amount of traffic yet so guess I may as well leave it until necessary to replace with more power.

I find it kind of funny that in the end it was 9 lines of config changes that changed to terminate this whole new service. I also had to create a new virtual template with a lower mss for it to work properly.

-----Original Message-----
From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On Behalf Of James Bensley
Sent: Monday, 10 August 2015 7:39 PM
To: cisco-bba@puck.nether.net
Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC

On 5 August 2015 at 22:06, Gary T. Giesen <ggiesen+cisco-bba@giesen.me> wrote:
> In my experience it’s best to stuff the interfaces facing the provider
> in a VRF, and point a default route out to their gateway. This way if
> they add new routes in the future (for new LACs), you don’t need to make any changes.
> This also works very well when you have multiple loop providers that
> use private address ranges for their LAC networks, as it ensures you
> don’t have any conflicts with your routing.


Agreed, this is what I have been doing too. VRF per loop provider with multiple sub-interfaces, one for each loop provider one per loop provider per service, with a default route. Keeps the traffic seperate and easily measurable and a simple config to manage.

James.
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

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

Hi Gary,

The 7204 is the same as the 7206, as long as they are VXR chassis, they both support NPE-G1 & NPE-G2's. Hugh price difference between 7200 series and ASR1k

If you can get by with an NPE-G1 then they are sub $500 now, which is always attractive for projects.

Cheers
Sarpreet



-----Original Message-----
From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On Behalf Of Gary T. Giesen
Sent: Tuesday, August 18, 2015 8:07 AM
To: cisco-bba@puck.nether.net
Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC

What kind of NPE in the 7204? I've used 7206 NPE-G1's and they work fairly well at small scale (less than 1000 subs), the G2 is better as it supports more features (particularly things like QoS).

ASR1k's are great LNS boxes, just have to be careful when migrating from 7200's to ASRs as they are a lot more strict about what RADIUS attributes you can use and may cause you lots of frustration trying to figure it out. In particular they don't support full Virtual-Access interfaces (only sub-interfaces) so any attribute that requires a full Virtual-Access interface will not work.

GTG

-----Original Message-----
From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On Behalf Of Nathan Downes
Sent: August-10-15 6:35 AM
To: cisco-bba@puck.nether.net
Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC

I will look into this, might make things easier. I am not a cisco expert so slowly learning things as I need them. Takes a lot of reading and research to implement something new :) I ended up finding out that the provider was sending to the host address rather than the one I had allocated. .28 /30 and I was using .29. Tunnel came up after they fixed that but no traffic would flow until I corrected the routing.

I am upgrading to an ASR 1004 for our core soon as I need netflow for some laws here, would it be better to use for termination than the 7204? Not a huge amount of traffic yet so guess I may as well leave it until necessary to replace with more power.

I find it kind of funny that in the end it was 9 lines of config changes that changed to terminate this whole new service. I also had to create a new virtual template with a lower mss for it to work properly.

-----Original Message-----
From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On Behalf Of James Bensley
Sent: Monday, 10 August 2015 7:39 PM
To: cisco-bba@puck.nether.net
Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC

On 5 August 2015 at 22:06, Gary T. Giesen <ggiesen+cisco-bba@giesen.me> wrote:
> In my experience it’s best to stuff the interfaces facing the provider
> in a VRF, and point a default route out to their gateway. This way if
> they add new routes in the future (for new LACs), you don’t need to make any changes.
> This also works very well when you have multiple loop providers that
> use private address ranges for their LAC networks, as it ensures you
> don’t have any conflicts with your routing.


Agreed, this is what I have been doing too. VRF per loop provider with multiple sub-interfaces, one for each loop provider one per loop provider per service, with a default route. Keeps the traffic seperate and easily measurable and a simple config to manage.

James.
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

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

On 8/18/15, 8:06 AM, Gary T. Giesen wrote:
> What kind of NPE in the 7204? I've used 7206 NPE-G1's and they work fairly well at small scale (less than 1000 subs), the G2 is better as it supports more features (particularly things like QoS).
>
> ASR1k's are great LNS boxes, just have to be careful when migrating from 7200's to ASRs as they are a lot more strict about what RADIUS attributes you can use and may cause you lots of frustration trying to figure it out. In particular they don't support full Virtual-Access interfaces (only sub-interfaces) so any attribute that requires a full Virtual-Access interface will not work.
>
> GTG
>
This is the situation I have too - a 7201 terminating pppoe subscribers
- about 1100 - and am now migrating to an Asr1000. What features exactly
cause the requirement for full virtual-access interface? I know my ASR
has the horsepower to do the job but it's got more features and things I
plan on experimenting with in the future, including making much more
extensive use of the QoS features per-subscriber which is somthing I am
not doing today on the 7201.

Mike-
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

Nothing I wasn't able to work around in the end.

Framed-Compression, and qos pre-classify come to mind (qos pre-classify is
not needed anyways). We had both enabled (Framed-Compression in RADIUS users
file, qos pre-classify on the Virtual-Template) and drove me nuts till I
figured out what it was. There may be others.

> -----Original Message-----
> From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On Behalf Of
> Mike
> Sent: August 18, 2015 2:51 PM
> To: cisco-bba@puck.nether.net
> Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC
>
>
> On 8/18/15, 8:06 AM, Gary T. Giesen wrote:
> > What kind of NPE in the 7204? I've used 7206 NPE-G1's and they work
fairly
> well at small scale (less than 1000 subs), the G2 is better as it supports
more
> features (particularly things like QoS).
> >
> > ASR1k's are great LNS boxes, just have to be careful when migrating from
> 7200's to ASRs as they are a lot more strict about what RADIUS attributes
you
> can use and may cause you lots of frustration trying to figure it out. In
> particular they don't support full Virtual-Access interfaces (only sub-
> interfaces) so any attribute that requires a full Virtual-Access interface
will
> not work.
> >
> > GTG
> >
> This is the situation I have too - a 7201 terminating pppoe subscribers
> - about 1100 - and am now migrating to an Asr1000. What features exactly
> cause the requirement for full virtual-access interface? I know my ASR has
> the horsepower to do the job but it's got more features and things I plan
on
> experimenting with in the future, including making much more extensive use
> of the QoS features per-subscriber which is somthing I am not doing today
on
> the 7201.
>
> Mike-
> _______________________________________________
> cisco-bba mailing list
> cisco-bba@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-bba

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

Oh another biggy:

Cisco-AVPair = "lcp:interface-config=XXXX"

https://supportforums.cisco.com/discussion/11532566/asr1002-pppoevpdn-virtua
l-access

> -----Original Message-----
> From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On Behalf Of
> Gary T. Giesen
> Sent: August 18, 2015 4:01 PM
> To: 'Mike'; cisco-bba@puck.nether.net
> Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC
>
> Nothing I wasn't able to work around in the end.
>
> Framed-Compression, and qos pre-classify come to mind (qos pre-classify is
> not needed anyways). We had both enabled (Framed-Compression in
> RADIUS users file, qos pre-classify on the Virtual-Template) and drove me
> nuts till I figured out what it was. There may be others.
>
> > -----Original Message-----
> > From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On Behalf
> > Of Mike
> > Sent: August 18, 2015 2:51 PM
> > To: cisco-bba@puck.nether.net
> > Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC
> >
> >
> > On 8/18/15, 8:06 AM, Gary T. Giesen wrote:
> > > What kind of NPE in the 7204? I've used 7206 NPE-G1's and they work
> fairly
> > well at small scale (less than 1000 subs), the G2 is better as it
> > supports
> more
> > features (particularly things like QoS).
> > >
> > > ASR1k's are great LNS boxes, just have to be careful when migrating
> > > from
> > 7200's to ASRs as they are a lot more strict about what RADIUS
> > attributes
> you
> > can use and may cause you lots of frustration trying to figure it out.
> > In particular they don't support full Virtual-Access interfaces (only
> > sub-
> > interfaces) so any attribute that requires a full Virtual-Access
> > interface
> will
> > not work.
> > >
> > > GTG
> > >
> > This is the situation I have too - a 7201 terminating pppoe
> > subscribers
> > - about 1100 - and am now migrating to an Asr1000. What features
> > exactly cause the requirement for full virtual-access interface? I
> > know my ASR has the horsepower to do the job but it's got more
> > features and things I plan
> on
> > experimenting with in the future, including making much more extensive
> > use of the QoS features per-subscriber which is somthing I am not
> > doing today
> on
> > the 7201.
> >
> > Mike-
> > _______________________________________________
> > cisco-bba mailing list
> > cisco-bba@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-bba
>
> _______________________________________________
> cisco-bba mailing list
> cisco-bba@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-bba

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

Take a look at this doc as well:

http://www.cisco.com/c/en/us/td/docs/routers/asr1000/configuration/guide/cha
ssis/asrswcfg/scaling.html#pgfId-1125595

> -----Original Message-----
> From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On Behalf Of
> Gary T. Giesen
> Sent: August 18, 2015 4:01 PM
> To: 'Mike'; cisco-bba@puck.nether.net
> Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC
>
> Nothing I wasn't able to work around in the end.
>
> Framed-Compression, and qos pre-classify come to mind (qos pre-classify is
> not needed anyways). We had both enabled (Framed-Compression in
> RADIUS users file, qos pre-classify on the Virtual-Template) and drove me
> nuts till I figured out what it was. There may be others.
>
> > -----Original Message-----
> > From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On Behalf
> > Of Mike
> > Sent: August 18, 2015 2:51 PM
> > To: cisco-bba@puck.nether.net
> > Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC
> >
> >
> > On 8/18/15, 8:06 AM, Gary T. Giesen wrote:
> > > What kind of NPE in the 7204? I've used 7206 NPE-G1's and they work
> fairly
> > well at small scale (less than 1000 subs), the G2 is better as it
> > supports
> more
> > features (particularly things like QoS).
> > >
> > > ASR1k's are great LNS boxes, just have to be careful when migrating
> > > from
> > 7200's to ASRs as they are a lot more strict about what RADIUS
> > attributes
> you
> > can use and may cause you lots of frustration trying to figure it out.
> > In particular they don't support full Virtual-Access interfaces (only
> > sub-
> > interfaces) so any attribute that requires a full Virtual-Access
> > interface
> will
> > not work.
> > >
> > > GTG
> > >
> > This is the situation I have too - a 7201 terminating pppoe
> > subscribers
> > - about 1100 - and am now migrating to an Asr1000. What features
> > exactly cause the requirement for full virtual-access interface? I
> > know my ASR has the horsepower to do the job but it's got more
> > features and things I plan
> on
> > experimenting with in the future, including making much more extensive
> > use of the QoS features per-subscriber which is somthing I am not
> > doing today
> on
> > the 7201.
> >
> > Mike-
> > _______________________________________________
> > cisco-bba mailing list
> > cisco-bba@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-bba
>
> _______________________________________________
> cisco-bba mailing list
> cisco-bba@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-bba

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

On 18 August 2015 at 21:01, Gary T. Giesen <ggiesen+cisco-bba@giesen.me> wrote:
> Framed-Compression,

That was quite annoying, we hit that problem too. It doesn't seem to
be documented anywhere that it's not supported although really we
shouldn't of had that setting present as it's not in use anymore so
lazy on our party.

It's annoying as at the time we were using FreeRADIUS and its enabled
be default in a couple of locations :S

Something else that we had to change was that PBR is no longer support
but again, laziness on our part, it was a nudge to remove any
instances of lingering PBR.

Cheers,
James.
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

I may not be able to avoid doing it, as I read deeper in the meta data laws,
I may need to not only keep track of who has what IP in the CGNAT but all
the translations as well, I think the ASR can do this via NEL. I have found
the less I touch things the better reliability is :)

I was figuring if we got a request to say who from (CGNAT external)
connected to DST IP x.x.x.x at port y I could look it up in the netflow from
the LNS but I don't think that contains the translation part. Might be
lucky and only one peron attempted to DST IP in that specific timeframe but
could be tricky if more did.

-----Original Message-----
From: Gary T. Giesen [mailto:ggiesen@giesen.me] On Behalf Of Gary T. Giesen
Sent: Wednesday, 19 August 2015 11:56 PM
To: 'Nathan Downes' <nathandownes@hotmail.com>
Subject: RE: [cisco-bba] 7204vxr as LNS - provider is LAC

If you have a G2 already, I would stick with it. It's still well-supported
with software, and will easily handle your session count.

Having everyone on one device can be nice, but in general I prefer different
devices for different roles. If a device goes down you lose everything on
that device, so the more you have on a single device, the more vulnerable
you can be. Also, it limits the impact of provisioning errors, as if you use
multiple devices you can limit the amount of changes to your core and
hopefully improve reliability.

Cheers,

GTG

> -----Original Message-----
> From: Nathan Downes [mailto:nathandownes@hotmail.com]
> Sent: August 19, 2015 4:29 AM
> To: 'Gary T. Giesen'
> Subject: RE: [cisco-bba] 7204vxr as LNS - provider is LAC
>
> It has a G2 in it, only terminating about 200 sessions now, but
> growing
each
> day. Don't do anything fancy with attributes. I guess as long as it
doesn't
> start smoking it won't matter. Sessions range in speed from 25/5 to
> 100/40 so not sure of the mileage I will have.
>
> I think I liked the idea of moving everything from 3 devices to 1!
>
> Only being forced into upgrade because of new laws here requiring 2
> years of retention, so need netflow on the core. G2 already does
> netflow for
the
> CGNAT and software we use to manage users/radius stores it.
>
> -----Original Message-----
> From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On Behalf
> Of Gary T. Giesen
> Sent: Wednesday, 19 August 2015 6:04 AM
> To: 'Mike' <mike-ciscobba@tiedyenetworks.com>; cisco-
> bba@puck.nether.net
> Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC
>
> Take a look at this doc as well:
>
> http://www.cisco.com/c/en/us/td/docs/routers/asr1000/configuration/gui
> d
> e/cha
> ssis/asrswcfg/scaling.html#pgfId-1125595
>
> > -----Original Message-----
> > From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On Behalf
> > Of Gary T. Giesen
> > Sent: August 18, 2015 4:01 PM
> > To: 'Mike'; cisco-bba@puck.nether.net
> > Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC
> >
> > Nothing I wasn't able to work around in the end.
> >
> > Framed-Compression, and qos pre-classify come to mind (qos
> > pre-classify is not needed anyways). We had both enabled
> > (Framed-Compression in RADIUS users file, qos pre-classify on the
> > Virtual-Template) and drove me nuts till I figured out what it was.
> > There
> may be others.
> >
> > > -----Original Message-----
> > > From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On
> > > Behalf Of Mike
> > > Sent: August 18, 2015 2:51 PM
> > > To: cisco-bba@puck.nether.net
> > > Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC
> > >
> > >
> > > On 8/18/15, 8:06 AM, Gary T. Giesen wrote:
> > > > What kind of NPE in the 7204? I've used 7206 NPE-G1's and they
> > > > work
> > fairly
> > > well at small scale (less than 1000 subs), the G2 is better as it
> > > supports
> > more
> > > features (particularly things like QoS).
> > > >
> > > > ASR1k's are great LNS boxes, just have to be careful when
> > > > migrating from
> > > 7200's to ASRs as they are a lot more strict about what RADIUS
> > > attributes
> > you
> > > can use and may cause you lots of frustration trying to figure it out.
> > > In particular they don't support full Virtual-Access interfaces
> > > (only
> > > sub-
> > > interfaces) so any attribute that requires a full Virtual-Access
> > > interface
> > will
> > > not work.
> > > >
> > > > GTG
> > > >
> > > This is the situation I have too - a 7201 terminating pppoe
> > > subscribers
> > > - about 1100 - and am now migrating to an Asr1000. What features
> > > exactly cause the requirement for full virtual-access interface? I
> > > know my ASR has the horsepower to do the job but it's got more
> > > features and things I plan
> > on
> > > experimenting with in the future, including making much more
> > > extensive use of the QoS features per-subscriber which is somthing
> > > I am not doing today
> > on
> > > the 7201.
> > >
> > > Mike-
> > > _______________________________________________
> > > cisco-bba mailing list
> > > cisco-bba@puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/cisco-bba
> >
> > _______________________________________________
> > cisco-bba mailing list
> > cisco-bba@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-bba
>
> _______________________________________________
> cisco-bba mailing list
> cisco-bba@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-bba

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

I believe the CISCO7600 series can do that as well with a firewall service module or a NAM service module.

Sarpreet

-----Original Message-----
From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On Behalf Of Nathan Downes
Sent: Wednesday, August 19, 2015 1:14 PM
To: cisco-bba@puck.nether.net
Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC

I may not be able to avoid doing it, as I read deeper in the meta data laws, I may need to not only keep track of who has what IP in the CGNAT but all the translations as well, I think the ASR can do this via NEL. I have found the less I touch things the better reliability is :)

I was figuring if we got a request to say who from (CGNAT external) connected to DST IP x.x.x.x at port y I could look it up in the netflow from the LNS but I don't think that contains the translation part. Might be lucky and only one peron attempted to DST IP in that specific timeframe but could be tricky if more did.

-----Original Message-----
From: Gary T. Giesen [mailto:ggiesen@giesen.me] On Behalf Of Gary T. Giesen
Sent: Wednesday, 19 August 2015 11:56 PM
To: 'Nathan Downes' <nathandownes@hotmail.com>
Subject: RE: [cisco-bba] 7204vxr as LNS - provider is LAC

If you have a G2 already, I would stick with it. It's still well-supported with software, and will easily handle your session count.

Having everyone on one device can be nice, but in general I prefer different devices for different roles. If a device goes down you lose everything on that device, so the more you have on a single device, the more vulnerable you can be. Also, it limits the impact of provisioning errors, as if you use multiple devices you can limit the amount of changes to your core and hopefully improve reliability.

Cheers,

GTG

> -----Original Message-----
> From: Nathan Downes [mailto:nathandownes@hotmail.com]
> Sent: August 19, 2015 4:29 AM
> To: 'Gary T. Giesen'
> Subject: RE: [cisco-bba] 7204vxr as LNS - provider is LAC
>
> It has a G2 in it, only terminating about 200 sessions now, but
> growing
each
> day. Don't do anything fancy with attributes. I guess as long as it
doesn't
> start smoking it won't matter. Sessions range in speed from 25/5 to
> 100/40 so not sure of the mileage I will have.
>
> I think I liked the idea of moving everything from 3 devices to 1!
>
> Only being forced into upgrade because of new laws here requiring 2
> years of retention, so need netflow on the core. G2 already does
> netflow for
the
> CGNAT and software we use to manage users/radius stores it.
>
> -----Original Message-----
> From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On Behalf
> Of Gary T. Giesen
> Sent: Wednesday, 19 August 2015 6:04 AM
> To: 'Mike' <mike-ciscobba@tiedyenetworks.com>; cisco-
> bba@puck.nether.net
> Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC
>
> Take a look at this doc as well:
>
> http://www.cisco.com/c/en/us/td/docs/routers/asr1000/configuration/gui
> d
> e/cha
> ssis/asrswcfg/scaling.html#pgfId-1125595
>
> > -----Original Message-----
> > From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On Behalf
> > Of Gary T. Giesen
> > Sent: August 18, 2015 4:01 PM
> > To: 'Mike'; cisco-bba@puck.nether.net
> > Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC
> >
> > Nothing I wasn't able to work around in the end.
> >
> > Framed-Compression, and qos pre-classify come to mind (qos
> > pre-classify is not needed anyways). We had both enabled
> > (Framed-Compression in RADIUS users file, qos pre-classify on the
> > Virtual-Template) and drove me nuts till I figured out what it was.
> > There
> may be others.
> >
> > > -----Original Message-----
> > > From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On
> > > Behalf Of Mike
> > > Sent: August 18, 2015 2:51 PM
> > > To: cisco-bba@puck.nether.net
> > > Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC
> > >
> > >
> > > On 8/18/15, 8:06 AM, Gary T. Giesen wrote:
> > > > What kind of NPE in the 7204? I've used 7206 NPE-G1's and they
> > > > work
> > fairly
> > > well at small scale (less than 1000 subs), the G2 is better as it
> > > supports
> > more
> > > features (particularly things like QoS).
> > > >
> > > > ASR1k's are great LNS boxes, just have to be careful when
> > > > migrating from
> > > 7200's to ASRs as they are a lot more strict about what RADIUS
> > > attributes
> > you
> > > can use and may cause you lots of frustration trying to figure it out.
> > > In particular they don't support full Virtual-Access interfaces
> > > (only
> > > sub-
> > > interfaces) so any attribute that requires a full Virtual-Access
> > > interface
> > will
> > > not work.
> > > >
> > > > GTG
> > > >
> > > This is the situation I have too - a 7201 terminating pppoe
> > > subscribers
> > > - about 1100 - and am now migrating to an Asr1000. What features
> > > exactly cause the requirement for full virtual-access interface? I
> > > know my ASR has the horsepower to do the job but it's got more
> > > features and things I plan
> > on
> > > experimenting with in the future, including making much more
> > > extensive use of the QoS features per-subscriber which is somthing
> > > I am not doing today
> > on
> > > the 7201.
> > >
> > > Mike-
> > > _______________________________________________
> > > cisco-bba mailing list
> > > cisco-bba@puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/cisco-bba
> >
> > _______________________________________________
> > cisco-bba mailing list
> > cisco-bba@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-bba
>
> _______________________________________________
> cisco-bba mailing list
> cisco-bba@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-bba

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

My suggestion would be to avoid CGNAT if at all possible. There are IP
addresses available on the transfer market.

> -----Original Message-----
> From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On Behalf Of
> Nathan Downes
> Sent: August 19, 2015 4:14 PM
> To: cisco-bba@puck.nether.net
> Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC
>
> I may not be able to avoid doing it, as I read deeper in the meta data
laws, I
> may need to not only keep track of who has what IP in the CGNAT but all
the
> translations as well, I think the ASR can do this via NEL. I have found
the less I
> touch things the better reliability is :)
>
> I was figuring if we got a request to say who from (CGNAT external)
> connected to DST IP x.x.x.x at port y I could look it up in the netflow
from the
> LNS but I don't think that contains the translation part. Might be lucky
and
> only one peron attempted to DST IP in that specific timeframe but could be
> tricky if more did.
>
> -----Original Message-----
> From: Gary T. Giesen [mailto:ggiesen@giesen.me] On Behalf Of Gary T.
> Giesen
> Sent: Wednesday, 19 August 2015 11:56 PM
> To: 'Nathan Downes' <nathandownes@hotmail.com>
> Subject: RE: [cisco-bba] 7204vxr as LNS - provider is LAC
>
> If you have a G2 already, I would stick with it. It's still well-supported
with
> software, and will easily handle your session count.
>
> Having everyone on one device can be nice, but in general I prefer
different
> devices for different roles. If a device goes down you lose everything on
that
> device, so the more you have on a single device, the more vulnerable you
> can be. Also, it limits the impact of provisioning errors, as if you use
multiple
> devices you can limit the amount of changes to your core and hopefully
> improve reliability.
>
> Cheers,
>
> GTG
>
> > -----Original Message-----
> > From: Nathan Downes [mailto:nathandownes@hotmail.com]
> > Sent: August 19, 2015 4:29 AM
> > To: 'Gary T. Giesen'
> > Subject: RE: [cisco-bba] 7204vxr as LNS - provider is LAC
> >
> > It has a G2 in it, only terminating about 200 sessions now, but
> > growing
> each
> > day. Don't do anything fancy with attributes. I guess as long as it
> doesn't
> > start smoking it won't matter. Sessions range in speed from 25/5 to
> > 100/40 so not sure of the mileage I will have.
> >
> > I think I liked the idea of moving everything from 3 devices to 1!
> >
> > Only being forced into upgrade because of new laws here requiring 2
> > years of retention, so need netflow on the core. G2 already does
> > netflow for
> the
> > CGNAT and software we use to manage users/radius stores it.
> >
> > -----Original Message-----
> > From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On Behalf
> > Of Gary T. Giesen
> > Sent: Wednesday, 19 August 2015 6:04 AM
> > To: 'Mike' <mike-ciscobba@tiedyenetworks.com>; cisco-
> > bba@puck.nether.net
> > Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC
> >
> > Take a look at this doc as well:
> >
> > http://www.cisco.com/c/en/us/td/docs/routers/asr1000/configuration/gui
> > d
> > e/cha
> > ssis/asrswcfg/scaling.html#pgfId-1125595
> >
> > > -----Original Message-----
> > > From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On Behalf
> > > Of Gary T. Giesen
> > > Sent: August 18, 2015 4:01 PM
> > > To: 'Mike'; cisco-bba@puck.nether.net
> > > Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC
> > >
> > > Nothing I wasn't able to work around in the end.
> > >
> > > Framed-Compression, and qos pre-classify come to mind (qos
> > > pre-classify is not needed anyways). We had both enabled
> > > (Framed-Compression in RADIUS users file, qos pre-classify on the
> > > Virtual-Template) and drove me nuts till I figured out what it was.
> > > There
> > may be others.
> > >
> > > > -----Original Message-----
> > > > From: cisco-bba [mailto:cisco-bba-bounces@puck.nether.net] On
> > > > Behalf Of Mike
> > > > Sent: August 18, 2015 2:51 PM
> > > > To: cisco-bba@puck.nether.net
> > > > Subject: Re: [cisco-bba] 7204vxr as LNS - provider is LAC
> > > >
> > > >
> > > > On 8/18/15, 8:06 AM, Gary T. Giesen wrote:
> > > > > What kind of NPE in the 7204? I've used 7206 NPE-G1's and they
> > > > > work
> > > fairly
> > > > well at small scale (less than 1000 subs), the G2 is better as it
> > > > supports
> > > more
> > > > features (particularly things like QoS).
> > > > >
> > > > > ASR1k's are great LNS boxes, just have to be careful when
> > > > > migrating from
> > > > 7200's to ASRs as they are a lot more strict about what RADIUS
> > > > attributes
> > > you
> > > > can use and may cause you lots of frustration trying to figure it
out.
> > > > In particular they don't support full Virtual-Access interfaces
> > > > (only
> > > > sub-
> > > > interfaces) so any attribute that requires a full Virtual-Access
> > > > interface
> > > will
> > > > not work.
> > > > >
> > > > > GTG
> > > > >
> > > > This is the situation I have too - a 7201 terminating pppoe
> > > > subscribers
> > > > - about 1100 - and am now migrating to an Asr1000. What features
> > > > exactly cause the requirement for full virtual-access interface? I
> > > > know my ASR has the horsepower to do the job but it's got more
> > > > features and things I plan
> > > on
> > > > experimenting with in the future, including making much more
> > > > extensive use of the QoS features per-subscriber which is somthing
> > > > I am not doing today
> > > on
> > > > the 7201.
> > > >
> > > > Mike-
> > > > _______________________________________________
> > > > cisco-bba mailing list
> > > > cisco-bba@puck.nether.net
> > > > https://puck.nether.net/mailman/listinfo/cisco-bba
> > >
> > > _______________________________________________
> > > cisco-bba mailing list
> > > cisco-bba@puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/cisco-bba
> >
> > _______________________________________________
> > cisco-bba mailing list
> > cisco-bba@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-bba
>
> _______________________________________________
> cisco-bba mailing list
> cisco-bba@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-bba

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