Hi nanogers, Recently (today :) I've been playing with configuring Sean ACL 112 on our transit BGP router. I'm surprised by the number of routes which have been dropped, especialy in the 206.0.0.0/7 range. The exact access list is the one Sean described on this list in 1995, available at http://www.ianai.net/filters/Sprint-ACL112 Here are the result: Before: Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 144.85.0.5 4 6893 42 30 687201 0 0 00:22:52 13 194.38.74.206 4 6776 28 37 687201 0 0 00:24:54 21 194.38.74.214 4 65501 26 27 687202 0 0 00:22:15 2 194.38.74.218 4 65402 0 0 0 0 0 never Idle (Admin) 194.148.254.253 4 3334 28 30 687162 0 0 00:23:04 2 195.89.0.85 4 5378 22567 26 687202 0 0 00:20:38 59045 195.141.225.1 4 6730 22398 15 687202 0 0 00:09:00 62345 195.202.192.33 4 8493 1040 1042 687202 0 0 17:17:48 0 195.202.192.41 4 8493 1040 1042 687202 0 0 17:17:53 0 195.202.192.77 4 8493 1040 1042 687202 0 0 17:17:48 0 195.202.192.117 4 8493 89 91 687202 0 0 01:26:17 0 Right after (clear ip bgp (5378|6730) soft in): Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 144.85.0.5 4 6893 45 33 749634 0 0 00:25:43 13 194.38.74.206 4 6776 31 40 749634 0 0 00:27:45 21 194.38.74.214 4 65501 28 30 749634 1 0 00:25:06 2 194.38.74.218 4 65402 0 0 0 0 0 never Idle (Admin) 194.148.254.253 4 3334 30 32 687372 0 0 00:25:56 2 195.89.0.85 4 5378 22669 29 687372 1 0 00:23:30 41236 195.141.225.1 4 6730 22452 17 687372 14 0 00:11:52 42188 195.202.192.33 4 8493 1043 1045 749634 0 0 17:20:40 0 195.202.192.41 4 8493 1043 1045 749634 0 0 17:20:44 0 195.202.192.77 4 8493 1043 1045 749634 0 0 17:20:40 0 195.202.192.117 4 8493 92 94 749634 0 0 01:29:09 0 lsne-br1#sh access-lists 199 Extended IP access list 199 permit ip 192.0.0.0 13.255.255.255 0.0.0.0 255.255.255.0 (35236 matches) permit ip 194.0.0.0 9.255.255.255 0.0.0.0 255.255.255.0 (20987 matches) permit ip 198.0.0.0 1.255.255.255 0.0.0.0 255.255.255.0 (15285 matches) permit ip 206.0.0.0 0.255.255.255 0.0.0.0 255.255.224.0 (894 matches) permit ip 206.0.0.0 1.255.255.255 0.0.0.0 255.255.192.0 (611 matches) permit ip 224.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0 permit ip 128.0.0.0 63.255.255.255 0.0.0.0 255.255.0.0 (10520 matches) permit ip 1.0.0.0 126.0.0.0 0.0.0.0 255.0.0.0 (20 matches) permit ip 2.0.0.0 125.0.0.0 0.0.0.0 255.0.0.0 (6 matches) permit ip 4.0.0.0 123.0.0.0 0.0.0.0 255.0.0.0 (10 matches) permit ip 8.0.0.0 119.0.0.0 0.0.0.0 255.0.0.0 (2 matches) permit ip 16.0.0.0 111.0.0.0 0.0.0.0 255.0.0.0 (2 matches) permit ip 32.0.0.0 95.0.0.0 0.0.0.0 255.0.0.0 (2 matches) permit ip 64.0.0.0 63.0.0.0 0.0.0.0 255.0.0.0 permit ip 9.2.0.0 0.0.255.255 host 255.255.0.0 (2 matches) permit ip 9.20.0.0 0.0.255.255 host 255.255.192.0 permit ip 39.0.0.0 0.255.255.255 0.0.0.0 255.255.255.0 deny ip 0.0.0.0 127.255.255.255 0.128.0.0 255.127.255.255 (1458 matches) deny ip 0.0.0.0 127.255.255.255 0.64.0.0 255.191.255.255 deny ip 0.0.0.0 127.255.255.255 0.32.0.0 255.223.255.255 deny ip 0.0.0.0 127.255.255.255 0.16.0.0 255.239.255.255 deny ip 0.0.0.0 127.255.255.255 0.8.0.0 255.247.255.255 deny ip 0.0.0.0 127.255.255.255 0.4.0.0 255.251.255.255 deny ip 0.0.0.0 127.255.255.255 0.2.0.0 255.253.255.255 deny ip 0.0.0.0 127.255.255.255 0.1.0.0 255.254.255.255 deny ip 0.0.0.0 127.255.255.255 0.0.0.0 255.255.0.0 deny ip 0.0.0.0 191.255.255.255 0.0.128.0 255.255.127.255 (4635 matches) deny ip 0.0.0.0 191.255.255.255 0.0.64.0 255.255.191.255 deny ip 0.0.0.0 191.255.255.255 0.0.32.0 255.255.223.255 deny ip 0.0.0.0 191.255.255.255 0.0.16.0 255.255.239.255 deny ip 0.0.0.0 191.255.255.255 0.0.8.0 255.255.247.255 deny ip 0.0.0.0 191.255.255.255 0.0.4.0 255.255.251.255 deny ip 0.0.0.0 191.255.255.255 0.0.2.0 255.255.253.255 deny ip 0.0.0.0 191.255.255.255 0.0.1.0 255.255.254.255 deny ip 206.0.0.0 1.255.255.255 0.0.32.0 255.255.223.255 (12062 matches) deny ip 206.0.0.0 1.255.255.255 0.0.16.0 255.255.239.255 deny ip 206.0.0.0 1.255.255.255 0.0.8.0 255.255.247.255 deny ip 206.0.0.0 1.255.255.255 0.0.4.0 255.255.251.255 deny ip 206.0.0.0 1.255.255.255 0.0.2.0 255.255.253.255 deny ip 206.0.0.0 1.255.255.255 0.0.1.0 255.255.254.255 deny ip 224.0.0.0 15.255.255.255 0.0.32.0 255.255.223.255 deny ip 224.0.0.0 15.255.255.255 0.0.16.0 255.255.239.255 deny ip 224.0.0.0 15.255.255.255 0.0.8.0 255.255.247.255 deny ip 224.0.0.0 15.255.255.255 0.0.4.0 255.255.251.255 deny ip 224.0.0.0 15.255.255.255 0.0.2.0 255.255.253.255 deny ip 224.0.0.0 15.255.255.255 0.0.1.0 255.255.254.255 deny ip any host 255.255.255.0 (9567 matches) deny ip any 0.0.0.128 255.255.255.127 (335 matches) deny ip any 0.0.0.64 255.255.255.191 deny ip any 0.0.0.32 255.255.255.223 deny ip any 0.0.0.16 255.255.255.239 deny ip any 0.0.0.8 255.255.255.247 deny ip any 0.0.0.4 255.255.255.251 deny ip any 0.0.0.2 255.255.255.253 deny ip any 0.0.0.1 255.255.255.252 deny ip 240.0.0.0 15.255.255.255 any deny ip 0.0.0.0 0.255.255.255 any After reverting order of specific bit masking: Right after (clear ip bgp (5378|6730) soft in).. Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 144.85.0.5 4 6893 378 366 808741 0 0 05:56:23 88 194.38.74.206 4 6776 364 383 808741 0 0 05:58:25 21 194.38.74.214 4 65501 359 360 808741 0 0 05:55:46 2 194.38.74.218 4 65402 0 0 0 0 0 never Idle (Admin) 194.148.254.253 4 3334 361 377 808741 0 0 05:56:36 2 195.89.0.85 4 5378 81719 362 808741 0 0 05:54:09 40707 195.141.225.1 4 6730 31911 350 808741 0 0 05:42:32 42273 195.202.192.33 4 8493 1374 1376 809317 0 0 22:51:19 0 195.202.192.41 4 8493 1374 1376 809317 0 0 22:51:24 0 195.202.192.77 4 8493 1374 1376 809317 0 0 22:51:19 0 195.202.192.117 4 8493 422 424 809317 0 0 06:59:48 0 lsne-br1#sh access-lists 199 Extended IP access list 199 permit ip 192.0.0.0 13.255.255.255 0.0.0.0 255.255.255.0 (35360 matches) permit ip 194.0.0.0 9.255.255.255 0.0.0.0 255.255.255.0 (23838 matches) permit ip 198.0.0.0 1.255.255.255 0.0.0.0 255.255.255.0 (15257 matches) permit ip 206.0.0.0 0.255.255.255 0.0.0.0 255.255.224.0 (894 matches) permit ip 206.0.0.0 1.255.255.255 0.0.0.0 255.255.192.0 (612 matches) permit ip 224.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0 permit ip 128.0.0.0 63.255.255.255 0.0.0.0 255.255.0.0 (10540 matches) permit ip 1.0.0.0 126.0.0.0 0.0.0.0 255.0.0.0 (20 matches) permit ip 2.0.0.0 125.0.0.0 0.0.0.0 255.0.0.0 (6 matches) permit ip 4.0.0.0 123.0.0.0 0.0.0.0 255.0.0.0 (10 matches) permit ip 8.0.0.0 119.0.0.0 0.0.0.0 255.0.0.0 (2 matches) permit ip 16.0.0.0 111.0.0.0 0.0.0.0 255.0.0.0 (2 matches) permit ip 32.0.0.0 95.0.0.0 0.0.0.0 255.0.0.0 (2 matches) permit ip 64.0.0.0 63.0.0.0 0.0.0.0 255.0.0.0 permit ip 9.2.0.0 0.0.255.255 host 255.255.0.0 (2 matches) permit ip 9.20.0.0 0.0.255.255 host 255.255.192.0 permit ip 39.0.0.0 0.255.255.255 0.0.0.0 255.255.255.0 deny ip 0.0.0.0 127.255.255.255 0.1.0.0 255.254.255.255 (1434 matches) means that ~700 networks in the old A class are announced /15 deny ip 0.0.0.0 127.255.255.255 0.2.0.0 255.253.255.255 (12 matches) deny ip 0.0.0.0 127.255.255.255 0.4.0.0 255.251.255.255 (6 matches) deny ip 0.0.0.0 127.255.255.255 0.8.0.0 255.247.255.255 (6 matches) deny ip 0.0.0.0 127.255.255.255 0.16.0.0 255.239.255.255 deny ip 0.0.0.0 127.255.255.255 0.32.0.0 255.223.255.255 deny ip 0.0.0.0 127.255.255.255 0.64.0.0 255.191.255.255 deny ip 0.0.0.0 127.255.255.255 0.128.0.0 255.127.255.255 (4 matches) deny ip 0.0.0.0 127.255.255.255 0.0.0.0 255.255.0.0 deny ip 0.0.0.0 191.255.255.255 0.0.1.0 255.255.254.255 (2946 matches) ~1500 networks in the old B class are announced /23 deny ip 0.0.0.0 191.255.255.255 0.0.2.0 255.255.253.255 (656 matches) deny ip 0.0.0.0 191.255.255.255 0.0.4.0 255.255.251.255 (281 matches) deny ip 0.0.0.0 191.255.255.255 0.0.8.0 255.255.247.255 (156 matches) deny ip 0.0.0.0 191.255.255.255 0.0.16.0 255.255.239.255 (170 matches) deny ip 0.0.0.0 191.255.255.255 0.0.32.0 255.255.223.255 (205 matches) deny ip 0.0.0.0 191.255.255.255 0.0.64.0 255.255.191.255 (123 matches) deny ip 0.0.0.0 191.255.255.255 0.0.128.0 255.255.127.255 (147 matches) deny ip 206.0.0.0 1.255.255.255 0.0.1.0 255.255.254.255 (7752 matches) ~3800 nets announced /23 in the supposedely /18 allocated old C space deny ip 206.0.0.0 1.255.255.255 0.0.2.0 255.255.253.255 (1379 matches) deny ip 206.0.0.0 1.255.255.255 0.0.4.0 255.255.251.255 (1047 matches) deny ip 206.0.0.0 1.255.255.255 0.0.8.0 255.255.247.255 (770 matches) deny ip 206.0.0.0 1.255.255.255 0.0.16.0 255.255.239.255 (676 matches) deny ip 206.0.0.0 1.255.255.255 0.0.32.0 255.255.223.255 (422 matches) deny ip 224.0.0.0 15.255.255.255 0.0.1.0 255.255.254.255 deny ip 224.0.0.0 15.255.255.255 0.0.2.0 255.255.253.255 deny ip 224.0.0.0 15.255.255.255 0.0.4.0 255.255.251.255 deny ip 224.0.0.0 15.255.255.255 0.0.8.0 255.255.247.255 deny ip 224.0.0.0 15.255.255.255 0.0.16.0 255.255.239.255 deny ip 224.0.0.0 15.255.255.255 0.0.32.0 255.255.223.255 deny ip any host 255.255.255.0 (9611 matches) deny ip any 0.0.0.1 255.255.255.252 deny ip any 0.0.0.2 255.255.255.253 (18 matches) deny ip any 0.0.0.4 255.255.255.251 (28 matches) deny ip any 0.0.0.8 255.255.255.247 (22 matches) deny ip any 0.0.0.16 255.255.255.239 (53 matches) deny ip any 0.0.0.32 255.255.255.223 (102 matches) deny ip any 0.0.0.64 255.255.255.191 (92 matches) deny ip any 0.0.0.128 255.255.255.127 (45 matches) deny ip 240.0.0.0 15.255.255.255 any deny ip 0.0.0.0 0.255.255.255 any I know that some old unused A classe were being reallocated CIDR. Don't know much about anything else. Also, old 1995 ACL112 doesn't consider europeean allocation policy (194/8 at /24, 195/8 at /20 for example), while today sprint filtering policy take this into consideration. Anyone clueful on this topic? Is old 1995 ACL112 way to restrictive? or ISP behavior really really bad (RAM is cheap nowadays.. except cisco RAM :-) TIA, cheers. -- Philippe Strauss, ingenieur reseau/systemes, Urbanet SA philippe.strauss@urbanet.ch tel +41 21 623 30 20 --
On Wed, 16 Jun 1999, Philippe Strauss wrote:
I'm surprised by the number of routes which have been dropped, especialy in the 206.0.0.0/7 range.
Who is announcing these crap routes? Would be interesting to add 'top 10 bogus route announcements' to the weekly CIDR list. -Dan
At 11:37 PM 6/16/99 +0200, Philippe Strauss wrote:
Hi nanogers,
Recently (today :) I've been playing with configuring Sean ACL 112 on our transit BGP router. I'm surprised by the number of routes which have been dropped, especialy in the 206.0.0.0/7 range.
The exact access list is the one Sean described on this list in 1995, available at http://www.ianai.net/filters/Sprint-ACL112
Since you are using my copy of Sean's filters, I'll comment. I put that up as reference material, not as a recommendation. My "official" recommendation for filtering is: http://www.merit.edu/ipma/docs/help.html And it might interest you to know that, to the best of my knowledge, neither EBONE (Sean's current employer) or Sprint (Sean's former employer) use that type of filter any longer. The only thing I can see from any big providers is filtering on /24s. (If someone knows differently, please correct me. I'm just commenting on what I see - I have no first hand knowledge of the filters in anyone else's routers.) But feel free to use whatever you like on your network. I just don't want you to think that *I* use those. TTFN, patrick -- I Am Not An Isp - www.ianai.net ISPF, The Forum for ISPs by ISPs, <http://www.ispf.com> "Think of it as evolution in action." - Niven & Pournelle (No, I still don't have enable. ;-)
In February we received a new /20 CIDR from ARIN. I felt that we might be caught by the filters at ISPs like Sprint (http://www.sprint.net/filter.htm). I contacted Sprint twice and spoke to two different engineers, both told me that they were not filtering as their page described, and they would allow advertisements for /20 in 206/8 - 233/8. Since that time I have spoken to several people who purchase transit from Sprint, and they do indeed see my advertisements. Looking at NetFlow stats I can't find any major provider that we have not had traffic flow between. I assume they had to have accepted my advertisements, nobody runs BGP and default routes :). BTW: I also contacted, and received a similar response from ANS. On Thu, 17 Jun 1999, I Am Not An Isp wrote:
And it might interest you to know that, to the best of my knowledge, neither EBONE (Sean's current employer) or Sprint (Sean's former employer) use that type of filter any longer. The only thing I can see from any big providers is filtering on /24s. (If someone knows differently, please correct me. I'm just commenting on what I see - I have no first hand knowledge of the filters in anyone else's routers.)
======================================================================= Michael Lucking Michael@Lucking.COM
At 11:37 PM 6/16/99 +0200, Philippe Strauss wrote:
The exact access list is the one Sean described on this list in 1995, available at http://www.ianai.net/filters/Sprint-ACL112
Something I had forgotten was pointed out to me by a friend. THAT LIST CONTAINS ERRORS - YOU ARE DENYING VALID ROUTES. And I do not mean just those with masks longer than 19 bits. Specifically, from http://www.cctec.com/maillists/nanog/historical/9509/msg00107.html, we see: ! allow M =< /18 in 206/8-239/8 (1100 111x *, 1110 xxxx *) ! (allow mask bits in first 18 bits) ! 1100111x == {206,207} ! 1110xxxx == {208-239} ! access-list 112 permit ip 206.0.0.0 1.255.255.255 0.0.0.0 255.255.192.0 access-list 112 permit ip 239.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0 Which *should* be: ! allow M =< /18 in 206/8-239/8 (1100 111x *, 1110 xxxx *) ! (allow mask bits in first 18 bits) ! 1100111x == {206,207} ! 1101xxxx == {208,224} ! 1110xxxx == {224-239} ! access-list 112 permit ip 206.0.0.0 1.255.255.255 0.0.0.0 255.255.192.0 access-list 112 permit ip 208.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0 access-list 112 permit ip 224.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0 (Ignoring the fact that /19s were just allowed in 206/8 in the line before. :) This was a very early rev of 112, posted by Sean here on NANOG. (The earliest I could find, in fact.) First of all, you are blocking even /19s in all but 206/8, allowing /18s. But you are *completely* blocking 208-224, as there is no permit statement for them. I am sorry, I never intended that page to be USED by anyone, it was strictly there for historical/reference purposes. Philippe, if you are going to use something like a modern ACL112, please check out Sean's later posts in the NANOG archive. I shall update the page soon with a correct version of 112, and a corrected/updated version of my filter from the merit page. Sorry if anyone else has used this filter.
Philippe Strauss, ingenieur reseau/systemes, Urbanet SA
TTFN, patrick P.S. I am no way implying this is Sean's fault. The web page is an early, untested version and I really never meant for anyone to actually USE it. In fact, there is no link to the list anywhere on any of my other pages or anything like that. Philippe must have attended one of my classes or something, where I specifically stated it was an early, broken version. -- I Am Not An Isp - www.ianai.net ISPF, The Forum for ISPs by ISPs, <http://www.ispf.com> "Think of it as evolution in action." - Niven & Pournelle (No, I still don't have enable. ;-)
On Fri, Jun 18, 1999 at 12:55:16AM -0700, I Am Not An Isp wrote:
At 11:37 PM 6/16/99 +0200, Philippe Strauss wrote:
The exact access list is the one Sean described on this list in 1995, available at http://www.ianai.net/filters/Sprint-ACL112
Something I had forgotten was pointed out to me by a friend. THAT LIST CONTAINS ERRORS - YOU ARE DENYING VALID ROUTES. And I do not mean just those with masks longer than 19 bits.
Specifically, from http://www.cctec.com/maillists/nanog/historical/9509/msg00107.html, we see:
! allow M =< /18 in 206/8-239/8 (1100 111x *, 1110 xxxx *) ! (allow mask bits in first 18 bits) ! 1100111x == {206,207} ! 1110xxxx == {208-239} ! access-list 112 permit ip 206.0.0.0 1.255.255.255 0.0.0.0 255.255.192.0 access-list 112 permit ip 239.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0
Which *should* be:
! allow M =< /18 in 206/8-239/8 (1100 111x *, 1110 xxxx *) ! (allow mask bits in first 18 bits) ! 1100111x == {206,207} ! 1101xxxx == {208,224} ! 1110xxxx == {224-239} ! access-list 112 permit ip 206.0.0.0 1.255.255.255 0.0.0.0 255.255.192.0 access-list 112 permit ip 208.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0 access-list 112 permit ip 224.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0
Oh ok, quiet a nice chunk of adresse space left on the floor there :-)
(Ignoring the fact that /19s were just allowed in 206/8 in the line before. :)
This was a very early rev of 112, posted by Sean here on NANOG. (The earliest I could find, in fact.) First of all, you are blocking even /19s in all but 206/8, allowing /18s. But you are *completely* blocking 208-224, as there is no permit statement for them.
I am sorry, I never intended that page to be USED by anyone, it was strictly there for historical/reference purposes.
Yes, I've used it because it was the only version of Sean's ACL112 I've found. My goal was just to experiment about how isp's desaggregate ip space relative to how assigning authorities distribute it. I've deployed this ACL on a stub AS, with a default route pointing to one of my transit provider.
Philippe, if you are going to use something like a modern ACL112, please check out Sean's later posts in the NANOG archive.
OK, thanks for the advice. Will look the archive. But for production, I stick to your ACL190. Anyone having references about how assigning authorities claim to aggregate address space? (I know that RIPE never allocater longer than /20 in 195.0.0.0/8) ACL112 take various assumption, were are the reference information about that?
I shall update the page soon with a correct version of 112, and a corrected/updated version of my filter from the merit page. Sorry if anyone else has used this filter.
Philippe Strauss, ingenieur reseau/systemes, Urbanet SA
TTFN, patrick
P.S. I am no way implying this is Sean's fault. The web page is an early, untested version and I really never meant for anyone to actually USE it. In fact, there is no link to the list anywhere on any of my other pages or anything like that. Philippe must have attended one of my classes or something, where I specifically stated it was an early, broken version.
Altavista found it for me :-) Try ACL112 and look the result. Time to write a robot.txt :-)) Thanks for you time.
-- I Am Not An Isp - www.ianai.net ISPF, The Forum for ISPs by ISPs, <http://www.ispf.com> "Think of it as evolution in action." - Niven & Pournelle (No, I still don't have enable. ;-)
-- Philippe Strauss, ingenieur reseau/systemes, Urbanet SA philippe.strauss@urbanet.ch tel +41 21 623 30 20 --
At 11:29 PM 6/20/99 +0200, Philippe Strauss wrote:
On Fri, Jun 18, 1999 at 12:55:16AM -0700, I Am Not An Isp wrote:
I am sorry, I never intended that page to be USED by anyone, it was strictly there for historical/reference purposes.
Yes, I've used it because it was the only version of Sean's ACL112 I've found. My goal was just to experiment about how isp's desaggregate ip space relative to how assigning authorities distribute it.
Funny, I wonder why you didn't get the original NANOG post - the URL to which I copied in my last post.
Philippe, if you are going to use something like a modern ACL112, please check out Sean's later posts in the NANOG archive.
OK, thanks for the advice. Will look the archive.
Actually, I did a brief perusal of the archives on www.nanog.org and didn't find the final version. Does anyone have a copy I can post on the web site?
But for production, I stick to your ACL190.
Thanx, but there is a minor error in that one too. :) Don't use the 192.0.0.0/8 line. (Not that it should hurt anything, but don't use it anyway.) I'll be putting up a better one in a little while.
Anyone having references about how assigning authorities claim to aggregate address space? (I know that RIPE never allocater longer than /20 in 195.0.0.0/8) ACL112 take various assumption, were are the reference information about that?
If you go to the URL I copied in my last post and look at the threads surrounding it, Sean's logic is partially exposed in posts to this very list - as well as other peoples' reactions to his logic. (Please note that I am in no way claiming to know why Sean did something, just pointing out that he posted some reasons to NANOG that might clarify his reasoning.)
Altavista found it for me :-) Try ACL112 and look the result. Time to write a robot.txt :-))
Heh. Those damned robots. :)
Philippe Strauss, ingenieur reseau/systemes, Urbanet SA
TTFN, patrick -- I Am Not An Isp - www.ianai.net ISPF, The Forum for ISPs by ISPs, <http://www.ispf.com> "Think of it as evolution in action." - Niven & Pournelle (No, I still don't have enable. ;-)
participants (4)
-
Dan Hollis -
I Am Not An Isp -
Michael P. Lucking -
Philippe Strauss