Re: [swinog] Experiences with Foundry Bigiron-gear
Gunther Stammwitz asks a very reasonable question: At the moment we're using Cisco 12000 gear in our network and now I'd like to buy another But here he makes a big mistake: router What about replacing this with the word box? :-) in order to increase our redundancy. Another provided pointed at his foundry bigiron 8000 and told me how well it is running. Okay.. What he didn't know where the technical facts like pps or where the asic is (on the line- or management card) and so on but he said that the machine can sustain a dos attack of up to a gigabit without problems. Anyone here who has experience with the Bigiron series and would like to share some thoughts? Viktor Steinmann writes: BigIron is a Switch - not a router... O.k. - maybe Foundry says, it's a router. But when you try to do some advanced routing on that box - forget it... Neil J McRae writes: It's a switch not a router IMO. If you want a router talk to Juniper. My first take is who cares? If it does what you need at a decent price go for it. My second take is: Buy a NetIron rather than a BigIron - probably the same hardware but it's marketed as a router. Just keep telling everybody that you have a GSR, so that your colleagues still take you seriously. The architecture of the latest NetIron is quite nicely described in a recent marketing blurb: http://www.foundrynet.com/products/routers/netiron/ni40g.html?referrer=simons-swinog-post:-) Extract: The NetIron 40G dual-stack line modules are optimized for IPv4 and IPv6 packet formats and deliver wire-speed performance for both protocols. Each NetIron 40G line module supports as many as 512,000 IPv4 routes (four times the size of the Internet today) or 128,000 IPv6 routes in the module's hardware-based, pre-populated forwarding engine. So the forwarding engines are on the modules. How resistant the boxes are to various kinds of DoS I don't know - it certainly looks hard to overwhelm the forwarding plane just by sending small packets at it, because the total box capacity is 320 Mpps, which seems to mean 40 Mpps per linecard. I seem to remember that the much older NetIrons I used to be familiar with had flow-based forwarding, so they were susceptible to be overwhelmed by single-small-packet flows (aggressive address scans), which was worrying. But it's very well possible that the new ASICs have something more similar to regular CEF. The other question is how well you can protect the control plane against DoS traffic. As to my own experience with the new BigIrons: I don't have any, but: A few years ago we used two NetIron 400 boxes (very similar to the BigIron 4000 I think) for our first Gigabit link (a 2.5Gbps STM-16c Geneva-Zurich) - rather than using GSRs or Junipers, to make the experiment more interesting. I must say that I really liked the boxes, especially given the price. There were a few issues with the performance of their first generation POS cards (which were eventually solved by them being upgraded to newer hardware), and the speed of integration of new software features was glacial (but since we all have Cisco we are used to that already :-). But in the end performance was excellent, price and port density too, and last not least Cisco started being much more interested in our account. From looking at the NetIron 40G specs, I'd say give those a try. The BigIron 8000 probably has an older generation of ASICs. The BigIron MG8 looks similar to the NetIron 40G, although the ASICs may be different - for instance they never talk about IPv6, while the NI40G supports that in the ASIC. By the way we now use Cisco Catalyst 6500 (if you want to call it a switch)/7600 OSR (if you need a router) in our backbone, and we're generally quite happy with them. We like the cost-effective upgrade path to 10GE (Foundry has that one too), and they do mostly everything we need. -- Simon. ___ swinog mailing list [EMAIL PROTECTED] http://lists.init7.net/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Experiences with Foundry Bigiron-gear
Jeroen Massar adds to the unfounded router/switch FUD: If you are desperatly still wanting anything from Foundry then indeed go for a NetIron, this is what AMS-IX uses. But do note, they don't do routing. What do you mean they don't do routing? I already conceded that Real Men don't call them a router. If you get over this, it's quite hard to say they don't route. OK, hopefully the AMS-IX one doesn't route, because the AMS-IX should be a layer-2 affair. Our old NI400s did OSPF, BGP-4, PIM-SM quite nicely. Took them a while to implement MP-BGP (for IPv4 Multicast) but eventually they added that too. Also review the tech-l list of the last year to see that these boxes have stabilized a bit, with a lot of effort from Foundry, over the last year. Before that they where not much good ... If you want Routing get a Juniper. Oh and also keep in mind that one day you might want to do IPv6 ;) And guess what Foundry doesn't and Cisco does kind-of and Juniper does quite well... Have you checked out http://www.foundrynet.com/products/routers/netiron/ni40g.html?referrer=stupid-simon-still-arguing-with-real-men ? It talks very clearly about hardware forwarding for IPv6 packets. It even states how many entries the forwarding tables on the line cards can take (512k IPv4 or 128k IPv6 - the or hints at the fact that they have TCAM-based forwarding, so hopefully they can also support combinations in-between, like 384k IPv6+32k IPv6 prefixes). -- Simon. ___ swinog mailing list [EMAIL PROTECTED] http://lists.init7.net/cgi-bin/mailman/listinfo/swinog
Re: [swinog] OT: Bluewin SMTP proxy?
Jeroen Massar writes: On Tue, 2004-11-09 at 18:30 +0100, Philipp Morger wrote: On Tue, Nov 09, 2004 at 16:28:00 +0100, Jeroen Massar wrote: On Tue, 2004-11-09 at 16:15 +0100, Philipp Morger wrote: well, you sound like a candidate for propagating SPF in your DNS :) http://spf.pobox.com/mechanisms.html#ip6 8--- ip6 Could someone with IPv6 experience please provide some input? ---8 well, check http://www.ozonehouse.com/mark/spf/draft-lentczner-spf-00.txt SNIP ipv4 parts IP6 = ip6 : ip6-network [ ip6-cidr-length ] ip6-cidr-length = / 1*DIGIT ip6-network = as per [RFC 3513], section 2.2, e.g. 2001:DB8::CD30 Let's see, thus you have ip6:2001:db8::/32 in your SPF record? I don't think that is a nice parsable format. Looks very parsable to me. Should at least be something like: ip6:[2001:db8::/32] then, otherwise it is quite ambiguous, eg: ip6::::192.0.2.0/24 would not really work IMHO. Why? What are the different possible interpretations that make this ambiguous? Note that the [...] syntax was introduced for URLs, where there is in fact an ambiguity without the brackets, namely that if you have e.g. http://2001:620::8080/ then you don't know whether that means HTTP to port 80 on the host with IPv6 address 2001:620::8080, or to port 8080 on the host with IPv6 address 2001:620::. [...] When they have solved it, Maybe there's nothing to solve here... I will add these SPF records of course as I think it is a good way of at least halting down some spam... Then again most UE I receive is virusses and then anti-virus reports from misconfigured anti-virus tools and after that a little bit of spam. All of which gets taken care of by SA and Clam ;) -- Simon. ___ swinog mailing list [EMAIL PROTECTED] http://lists.init7.net/cgi-bin/mailman/listinfo/swinog
[swinog] Reply-to: header [was: Re: WAN link provider]
Marcel Prisi writes: Whoops ... reply-to was not the Good Thing (tm) ... Sorry all :-) So can we finally get rid of the Reply-to: [EMAIL PROTECTED] please? It only generates confusion and embarrassment, and I think we should be able to rely on people being able to use their mailer's reply to all feature when they want to write followups. -- Simon. ___ swinog mailing list [EMAIL PROTECTED] http://lists.init7.net/cgi-bin/mailman/listinfo/swinog
Re: [swinog] BGP and IPv6
Pascal Gloor writes: as I'm currently trying to write BGP multiprotocol support for OpenBSD's bgpd I would like to know which is the common setup. Mainly I'm intrested if you are using a shared IPv4 session or one session per protocol? I personally prefer IPv4 prefixes over IPv4 and IPv6 prefixes over IPv6. It keeps your setup clear and avoids any mix of protocols, etc... We do the same here - separate sessions with IPv4 prefixes exchanged over IPv4, IPv6 prefixes over IPv6. As Pascal said, it's easier to set up and debug, although it does seem slightly wasteful. -- Simon. ___ swinog mailing list [EMAIL PROTECTED] http://lists.init7.net/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Rechtsradikale spam mails
Yes. See the discussion over at [EMAIL PROTECTED] Apparently this mail flood leverages the Sober.G virus/worm. -- Simon. ___ swinog mailing list [EMAIL PROTECTED] http://lists.init7.net/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Congratulations to DE-CIX
20 Gb/s is impressive! Still it's a bit less than what's shifted at LINX or AMS-IX: http://www.linx.net/tools/stats/index.thtml http://www.ams-ix.net/about/stats.html For LINX I understand that it must have very high traffic because all the big ISPs from outside Europe have a tendency to set up their base in London, at least initially. The fact that AMS-IX has more traffic than DE-CIX has always puzzled me though. -- Simon. ___ swinog mailing list [EMAIL PROTECTED] http://lists.init7.net/cgi-bin/mailman/listinfo/swinog
[swinog] Announcement: IPv6 Summit, Zurich, Technopark, 3 June 2004
[resent because I don't think this was actually distributed-- SL.] Like last year, the Swiss IPv6 Task Force and SICTA are organizing a business-oriented event: what: IPv6 Summit Switzerland - Get Ready for IPv6! when: Thursday 3 June 2004, 0830-1700 (+apero) where: Zurich, Technopark, main auditorium For more information, including the draft program and an on-line registration form, see: http://www.sicta.ch/content/content_renderer.php?id=304link_type=1lan=1cms=bcid=113s=1 In the late afternoon (1600-1900) on the day before the summit (Wednesday 2 June), there will be an in-depth tutorial on IPv6 given by Silvia Hagen, author of not one but TWO books on IPv6 (http://www.sunny.ch/publications/f_ipv6_select.htm). This should be an excellent opportunity to get up to speed on IPv6. I'll be at the summit along with a couple other colleagues from SWITCH (the education research network) and hope that there will be more network operator folks to chat with! We're also there to help you configure IPv6 if you bring a suitable laptop computer. Wireless connectivity (including IPv4 :-) will be available all over the summit area at no extra charge. -- Simon. ___ swinog mailing list [EMAIL PROTECTED] http://lists.init7.net/cgi-bin/mailman/listinfo/swinog
[swinog] IPv6 peering at CIXP
[This may be my last IPv6-related spam^H^H^H^Hannouncement for today :-] We can peer IPv6 over the CIXP now. Note that CIXP use a separate VLAN for IPv6, so the procedure is not quite the same as at the TIX. So far our only IPv6 peering there is with the RIPE RIS route collector. Of course we'd like to exchange some actual IPv6 traffic there, too... Regards, -- Simon. SWITCH (AS559) ___ swinog mailing list [EMAIL PROTECTED] http://lists.init7.net/cgi-bin/mailman/listinfo/swinog
Re: [swinog] Announcement
With our network present at both CIXP and TIX, I (personally) think having two exchange points is a good thing - the fact that they are independently operated means that (1) they make good backups for each other and (2) there is competition, which good for customers (according to prevalent economic theory :-). As for the question whether Switzerland [is] big enough to run 2 big exchange points? - well, in some way it obviously is, since there *are* two exchange points. Of course there may be a good business case for reasonably-priced connectivity to exchange point A for operators who are already present at exchange point B (and vice versa). It shouldn't be too hard to build this, the question is by whom. The exchange points (A and B) might be interested. Carriers who are already at both A and B might be interested. But in many cases I think those players won't do it because they would see this as competition to existing services of their own. It would be even nicer if reasonably-priced connectivity to both A and B were available at various points along the route(s) of such an A-B connection (which happens to pass most major cities in Switzerland). -- Simon. -- [EMAIL PROTECTED] Maillist-Archive: http://www.mail-archive.com/swinog%40swinog.ch/
[swinog] Access to new I-Root server instance at CIXP
-BEGIN PGP SIGNED MESSAGE- The good folks at CIXP and at Autonomica AB have deployed an anycast instance of one of the DNS root servers at CERN, namely I.ROOT-SERVERS.NET [192.36.148.17]. If you are at present CIXP, you can simply peer with the server cluster at AS8674. If you aren't at CIXP, but have a peering with SWITCH (AS559), we can offer to provide you transit to this I-Root instance at CERN. That means that we'll announce the routes we receive from AS8674 to you, and announce your customer routes on to AS8674. If you are an AS559 peer and you're interested, please let us ([EMAIL PROTECTED]) know, so that we can document this properly. If you don't peer with us, you should be able to reach this or another close root server instance through one of your transit providers. If you are present at CIXP, please consider setting up a peering with AS8674 directly (contact: [EMAIL PROTECTED]). Note that good connectivity to the DNS root servers doesn't noticeably improve performance, because queries to root servers are quite rare except in error cases. But access to at least one root server is really important for DNS to work, so having an instance topologically close to your network gives you that warm fuzzy feeling. Regards, - -- Simon. SWITCH NOC http://www.switch.ch/network/noc/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (SunOS) Comment: Processed by Mailcrypt 3.5.6 and Gnu Privacy Guard http://www.gnupg.org/ iQCVAwUBQHMMAcWd1pKOV86ZAQFmtAP/ezG7Px/QJ2XqZ/W4tbvNTgJHvWG7okCr x5GDm6jdgSpSTV7Yxe6CvIt30wQ2ydzWeRMof+iIXAPnaneMe7IOCtWZRXnkGV+o BxdNZlhQaG+yU0gq5olJdduSBiIgYJjtk8h6ALp38WjbgtalcVqA7vK4yVPimGVB dgTFelPHKps= =sKEC -END PGP SIGNATURE- -- [EMAIL PROTECTED] Maillist-Archive: http://www.mail-archive.com/swinog%40swinog.ch/
Re: [swinog] SwiNOG-8 Meeting, Last minute feature announcement!!!!
Pascal Gloor writes: After some coordination efforts we're proud to announce that SwiNOG-8 will be the first SwiNOG meeting WITH WirelessLAN With Wireless LAN included in the registration fee, you mean? :-) There was Wireless LAN (Swisscom Mobile PWLAN) at the last meeting in the Kursaal, but as far as I know only one person used it. I use this as an example when I explain to my Swisscom friends why their approach is doomed. If you get 90 ISP folks in a room and (almost) none of them uses your nice WLAN service, then you are doing something wrong. Many thanks to The NET the Wireless sponsor (http://www.thenet.ch - http://wlan.thenet.ch) Those prices certainly look MUCH more reasonable than Swisscom's. Dont forget to take your WLAN devices :-) I can take a few extra PCMCIA WLAN cards. Contact me if you want to borrow one for the meeting. Regards, -- Simon. -- [EMAIL PROTECTED] Maillist-Archive: http://www.mail-archive.com/swinog%40swinog.ch/
Re: [swinog] Lambdanet ready to peer @TIX
Viktor Steinmann writes: No offense, but isn't LambdaNet the company that has gone broke last week? (Insolvenz) I think it is. (Other parts of Lambdanet (Spain and France) have been acquired by Cogent.) There is some information about the status of this on lambdanet.de's home page: http://lambdanet.de/index.php?sid=7fe85c2937ed6ad201d27db41051f8fep=314l=1 According to how I read this, the company will remain operational in all aspects (including acquiring new customers), but controlled by an Insolvenzverwalter. We set up a peering with them yesterday - the configuration went smoothly, and we see many routes and significant traffic flow. I wish them good luck in getting back to a regular situation soon! -- Simon. -- [EMAIL PROTECTED] Maillist-Archive: http://www.mail-archive.com/swinog%40swinog.ch/
Re: [swinog] Current IP+ martians-filter
195.7.0.0/19 le 24 ip prefix-list martians seq 701 deny 195.13.32.0/19 le 24 ip prefix-list martians seq 702 deny 195.20.96.0/19 le 24 ip prefix-list martians seq 703 deny 195.22.128.0/19 le 24 ip prefix-list martians seq 704 deny 195.24.64.0/19 le 24 ip prefix-list martians seq 705 deny 195.26.0.0/19 le 24 ip prefix-list martians seq 706 deny 195.35.64.0/18 le 24 ip prefix-list martians seq 707 deny 195.38.0.0/19 le 24 ip prefix-list martians seq 708 deny 195.39.192.0/18 le 24 ip prefix-list martians seq 709 deny 195.42.224.0/19 le 24 ip prefix-list martians seq 710 deny 195.43.32.0/19 le 24 ip prefix-list martians seq 711 deny 195.46.32.0/19 le 24 ip prefix-list martians seq 712 deny 195.47.192.0/18 le 24 ip prefix-list martians seq 713 deny 195.49.128.0/17 le 24 ip prefix-list martians seq 714 deny 195.66.0.0/19 le 24 ip prefix-list martians seq 715 deny 195.68.192.0/18 le 24 ip prefix-list martians seq 716 deny 195.69.64.0/18 le 24 ip prefix-list martians seq 717 deny 195.69.128.0/17 le 24 ip prefix-list martians seq 718 deny 195.72.96.0/19 le 24 ip prefix-list martians seq 719 deny 195.78.32.0/19 le 24 ip prefix-list martians seq 720 deny 195.80.224.0/19 le 24 ip prefix-list martians seq 721 deny 195.85.192.0/18 le 24 ip prefix-list martians seq 722 deny 195.128.32.0/19 le 24 ip prefix-list martians seq 723 deny 195.128.96.0/19 le 24 ip prefix-list martians seq 724 deny 195.128.160.0/19 le 24 ip prefix-list martians seq 725 deny 195.128.224.0/19 le 24 ip prefix-list martians seq 726 deny 195.135.192.0/18 le 24 ip prefix-list martians seq 727 deny 195.137.192.0/18 le 24 ip prefix-list martians seq 728 deny 195.140.128.0/17 le 24 ip prefix-list martians seq 729 deny 195.149.64.0/18 le 24 ip prefix-list martians seq 730 deny 195.149.192.0/18 le 24 ip prefix-list martians seq 731 deny 195.177.64.0/18 le 24 ip prefix-list martians seq 732 deny 195.177.192.0/18 le 24 ip prefix-list martians seq 733 deny 195.190.128.0/19 le 24 ip prefix-list martians seq 734 deny 195.190.224.0/19 le 24 ip prefix-list martians seq 735 deny 195.206.96.0/19 le 24 ip prefix-list martians seq 736 deny 195.214.192.0/18 le 24 ip prefix-list martians seq 737 deny 195.225.32.0/19 le 24 ip prefix-list martians seq 738 deny 195.225.64.0/18 le 24 ip prefix-list martians seq 739 deny 195.225.128.0/17 le 24 ip prefix-list martians seq 740 deny 195.234.128.0/17 le 24 ip prefix-list martians seq 741 deny 195.242.224.0/19 le 24 ip prefix-list martians seq 742 deny 195.245.192.0/18 le 24 ip prefix-list martians seq 743 deny 195.246.192.0/19 le 24 ip prefix-list martians seq 1 permit 0.0.0.0/0 le 32 end -- Simon Leinen [EMAIL PROTECTED] SWITCH http://www.switch.ch/misc/leinen/ Computers hate being anthropomorphized. -- [EMAIL PROTECTED] Maillist-Archive: http://www.mail-archive.com/swinog%40swinog.ch/
Re: [swinog] CERN (2nd)
Pascal Gloor writes: Seems CERN/CIXP has similar problems again. at least CERN - VTX session is flapping all the time. As www.cixp.ch seems unreachable I cannot check if others also have troubles. anyone peering at CIXP can confirm this? No. All our peerings have been stable except for the AS4589 one which flapped around 09:55 (23 minutes ago). Our peering with AS513 (CERN) is over a dedicated link and has been stable for three weeks. Note that we're in building 513 on the CERN campus; maybe the situation is different if you're in the other data centre in the city. -- Simon. AS559 (SWITCH) -- [EMAIL PROTECTED] Maillist-Archive: http://www.mail-archive.com/swinog%40swinog.ch/
Re: [swinog] SwiNOG-6 announcement / Call for presentations
On Tue, 25 Feb 2003 10:44:56 +0100, Pascal Gloor [EMAIL PROTECTED] said: If some other people object to have a presentation about GSM, it will be dropped (democracy :-)). In this case I object to having a presentation about GSM at the next meeting. I'd much rather hear the talk Andre offered to give on prefix filtering (which we also do by the way). -- Simon. -- [EMAIL PROTECTED] Maillist-Archive: http://www.mail-archive.com/swinog%40swinog.ch/
Re: [swinog] swinog.ch NS Servers
On Wed, 29 Jan 2003 13:38:46 +, Daniel Lorch [EMAIL PROTECTED] said: Not afraid of DNS-poisoning? If any of the above DNS would be 0wned and would send falsified data for swinog.ch, the page could be hijacked to point somewhere else. More servers = more risk. Well, yes, but wouldn't one eventually notice when the different NSes give different results? (Unless they are all hacked; and that would require more effort when there are more servers - assuming they don't all run the same software). RFC2182 [1], Section 5, is very clear about this: More servers also increase the likelihood that one server will be misconfigured, or malfunction, without being detected. That's true. But the difficulty of detecting a misconfiguring/ malfunctioning slave start as soon as there is more than one (or zero) of them. It gets significantly more when you start having slaves that are outside your administrative domain. But once you've gone down that path, one could argue that if you can detect misconfigurations and malfunctions in *one* externally operated slave, then you can also detect them in several; as long as you know who they are. Getting problems fixed once they have been detected is another matter, especially when you don't know the other operators well. Fortunately in this case you can at least be sure that they all read the SwiNOG mailing list! Oh and even more :) On the other hand, having large numbers of servers adds little benefit, while adding costs. At the simplest, more servers cause packets to be larger, so requiring more bandwidth. This may seem, and realistically is, trivial. However there is a limit to the size of a DNS packet, and causing that limit to be reached has more serious performance implications. We're aware of that, and we're still safely below 400 bytes. -- Simon. -- [EMAIL PROTECTED] Maillist-Archive: http://www.mail-archive.com/swinog%40swinog.ch/
Re: [swinog] swinog.ch NS Servers
On Wed, 29 Jan 2003 15:15:40 +, Daniel Lorch [EMAIL PROTECTED] said: Ok, I admit -- I'm annoying. In a nutshell: It's worse now; problem not solved. Maybe we should ask ourselves what problem we want to solve. The former situation was that there were two name servers for swinog.ch sharing infrastructure (even if they had redundant upstreams, there were actual failures of the underlying fiber network that took both out at the same time). So people couldn't resolve swinog.ch names, although some of the things under swinog.ch were functioning perfectly. That problem will have been solved now (at soon as the swinog.ch delegation has been changed). Solution: Increase TTL, remove unnecessary secondary DNSes. Increasing the TTLs is a fine idea, but there will always be situations when a cached record has eventually timed out, and if you cannot reach any authoritative name server, you'll be hosed. You will agree that we shouldn't make TTLs *infinitely* large, because we still want the possibility of changing addresses in finite time for some reasons (think of emergency situations). -- Simon. -- [EMAIL PROTECTED] Maillist-Archive: http://www.mail-archive.com/swinog%40swinog.ch/
DNS TTLs [was: Re: [swinog] swinog.ch NS Servers]
On Wed, 29 Jan 2003 13:38:46 +, Daniel Lorch [EMAIL PROTECTED] said: Why didn't you just increase the TTL? The current TTL of 1800 is far too low, causing unecessary traffic and latency, as it does not stay long enough in the ISP's caches. It is common to use TTL's around 172800 (2 days), at least for static addresses. If your server is down for more than 2 days, you're out of business anyway. Long TTLs are fine, but they also define how fast changes in the zone (changes for existing names in the zone to be exact) propagate through the Internet. In some cases you want to be able to change a given name faster than that; for example if a given IP address is under persistent attack (such as the address of www1.whitehouse.gov a while ago) or is otherwise DOSed. There is a nice paper studying the impact of TTL values on DNS traffic and response times: DNS Performance and the Effectiveness of Caching, by Jaeyeon Jung, Emil Sit, Hari Balakrishnan, Robert Morris (yes, *that* Morris :-), Internet Measurement Workshop 2001 (IMW 2001): http://nms.lcs.mit.edu/papers/dns-imw2001.ps.gz The gist is that caching at the delegation points (NS records and their associated A records) is what provides most benefit, while the impact of low-TTL A records isn't that bad. So if you want to be able to quickly modify things *within* your zone, but you still want to benefit from DNS caching, use a smaller TTL for most records (maybe using the $TTL directive), but specify larger TTLs for the NS records and the A records for the names that the NS records point to. The swinog.ch zone is now configured that way. Regards, -- Simon. -- [EMAIL PROTECTED] Maillist-Archive: http://www.mail-archive.com/swinog%40swinog.ch/
Re: [swinog] New worm / port 1434
We see a lot of this traffic too, and I found quite a few infected machines at customer sites. Some filters are in place, and our CERT has been asked to raise this issue with the customers in question. Seems to be a virus spreading through Microsoft SQL Server's Monitoring service; possibly using one of the vulnerabilities documented in http://www.nextgenss.com/advisories/mssql-udp.txt -- Simon. -- [EMAIL PROTECTED] Maillist-Archive: http://www.mail-archive.com/swinog%40swinog.ch/
Re: [swinog] update for webpage for the route viewer...
Salut Pascal, the official way to spell SWITCH is all-capitals... Thanks for your work on the route viewer, it's a useful tool! Regards, -- Simon. -- [EMAIL PROTECTED] Maillist-Archive: http://www.mail-archive.com/swinog%40swinog.ch/
