Re: Heads up: Long AS-sets announced in the next few days
On Wed, 2 Mar 2005, Hank Nussbacher wrote:
At 02:49 AM 02-03-05 +0100, Daniel Roesen wrote:
On Wed, Mar 02, 2005 at 01:27:31AM +, James A. T. Rice wrote:
What exactly are you attempting to do here? Those announcements will get
dropped on the floor at least in this AS right away:
route-map peers-in deny 5
match as-path 109
AS-Sets, not AS-Paths...
An example of which I received recently:
Feb 27 19:54:16: %BGP-6-ASPATH: Long AS path 20965 1299 3320 15589 15589
5397
{33,109,145,293,559,816,1103,1273,1275,1752,1853,1930,2042,2200,2497,2500,2914,3257,3265,,3352,3425,3549,4691,4697,4716,4725,5511,5539,5609,5623,6175,6435,6453,6762,6830,6939,7580,7660,8447,8472,8763,9264,10566,12779,12793,12859,13944,14277,15897,17715,17965,24136,24895,25358,29377,29686,31103,32266}
received from 2001:798:201B:10AA::1: More than configured MAXAS-LIMIT
different, but related to:
Feb 1 20:47:01.608: %BGP-6-ASPATH: Long AS path 3356 6770
8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282
8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282
8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282
8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282
8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282
8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282 8282
received from x.y.a.b: More than configured MAXAS-LIMIT
hey, 8282/Fido, perhaps you don't really need a 100 as as-path? :)
-Chris
Re: Heads up: Long AS-sets announced in the next few days
On Wed, 2 Mar 2005, Christopher L. Morrow wrote:
On Wed, 2 Mar 2005, Hank Nussbacher wrote:
At 02:49 AM 02-03-05 +0100, Daniel Roesen wrote:
On Wed, Mar 02, 2005 at 01:27:31AM +, James A. T. Rice wrote:
What exactly are you attempting to do here? Those announcements will get
dropped on the floor at least in this AS right away:
route-map peers-in deny 5
match as-path 109
AS-Sets, not AS-Paths...
An example of which I received recently:
Feb 27 19:54:16: %BGP-6-ASPATH: Long AS path 20965 1299 3320 15589 15589
5397
{33,109,145,293,559,816,1103,1273,1275,1752,1853,1930,2042,2200,2497,2500,2914,3257,3265,,3352,3425,3549,4691,4697,4716,4725,5511,5539,5609,5623,6175,6435,6453,6762,6830,6939,7580,7660,8447,8472,8763,9264,10566,12779,12793,12859,13944,14277,15897,17715,17965,24136,24895,25358,29377,29686,31103,32266}
received from 2001:798:201B:10AA::1: More than configured MAXAS-LIMIT
different, but related to:
Feb 1 20:47:01.608: %BGP-6-ASPATH: Long AS path 3356 6770
received from x.y.a.b: More than configured MAXAS-LIMIT
hey, 8282/Fido, perhaps you don't really need a 100 as as-path? :)
uhm, back in my hole... this is a month ago :)
Re: High volume WHOIS queries
At 06:00 PM 01-03-05 -0500, Larry J. Blunk wrote: ftp://ftp.arin.net/info/asn.txt Lists AS number, the whois AS name, and POC handle for each AS. Jeff If you are also interested in AS info outside the ARIN region, the following file may be of interest -- http://bgp.potaroo.net/as1221/asnames.txt Or this: http://netgeo.caida.org/aslatlong.txt -Hank
Re: High volume WHOIS queries
At 03:01 AM 3/2/2005, Hank Nussbacher wrote: At 06:00 PM 01-03-05 -0500, Larry J. Blunk wrote: ftp://ftp.arin.net/info/asn.txt Lists AS number, the whois AS name, and POC handle for each AS. Jeff If you are also interested in AS info outside the ARIN region, the following file may be of interest -- http://bgp.potaroo.net/as1221/asnames.txt Or this: http://netgeo.caida.org/aslatlong.txt Interestingly, the Caida data lacks AS numbers issued in the last several months, while the data is present in the arin.net and potaroo.net listings. Not sure where Caida gets its data, but the other sources would seem to be better for the project the original poster had in mind. It's also more than a bit odd, IMO, to assign a latitude and longitude to AS numbers. While some networks are well localized, many others span continents. As such, the value of that part of the caida data set seems nebulous.
Re: AOL scomp
On Tue 01 Mar 2005 (22:36 -0500), Joe Maimon wrote: Barry Shein wrote: On March 1, 2005 at 14:17 [EMAIL PROTECTED] (Jim Segrave) wrote: I don't understand this complaint - we process AOL TOS Notifications daily and I find perhaps 1 in a hundred or so are not valid complaints. Here about 99% are not valid or interesting. Which is to say, I had one small burst once caused by an infected customer machine which we got shut off fast and fixed. The rest are virtually all just people on mailing lists hosted here sending each and every completely on-topic posting to TOS. I suppose I should figure out some way to track them so I can boot them off those lists since AOL removes all identifying information. Apparently the ratio of valid/invalid AOL notifications is a usefull indicator on the cleanliness of the relevant network. Or alternatively, some networks have few users who communicate with AOL customers - they aren't currently big-time in the Netherlands - and the ratio of valid to invalid complaints has sweet FA to do with anything else. We don't set up mail forwarding for residential customers so that's another non-issue. -- Jim Segrave [EMAIL PROTECTED]
Re: Why do so few mail providers support Port 587?
Date: Mon, 28 Feb 2005 16:54:23 -0500 From: Nils Ketelsen [EMAIL PROTECTED] To: nanog@merit.edu Subject: Re: Why do so few mail providers support Port 587? [ ... ] I do not know about your E-Mail Policy, but normally it is either allowed to use an external mailserver or not. If it is allowed, I can as well allow Port 25 outgoing. If it is not I will block 25 and 587. Our corporate policy is that if you want to send mail with a @ourdomain address, you have to use our mailserver. On that machine we can rewrite usernames etc. But I have lots of users who also work at other places - to give you a hint, many of my users are researchers over here, but teachers at different places. So it's *not* in my employers best interest to disallow them *any* means of mailing with a @non-ourdomain address if that @non-ourdomain site allows them to do so via some other means then port 25... Port 587 on the other hand is meant for submission by clients. The security implications of allowing my users to contact such a port are very very low. If someone won't secure his mailserver on port 587, that's something different, but substantially different than if it were insecure on port 25... An interesting theory. What is the substantial difference? For me the security implications of allowing the user to bypass our mailsystem on port 25 and allowing the user to bypass our mailsystem on port 587 are not as obvious as they maybe are to you. Anything listening on port 587 - as has been said many times over in this discussion - should not blindly relay. It should demand authentication from the user and only when those are satisfactory relay. That was and is what port 587 is meant for. Port 25 has a much too diverse role in the way mail delivery is handled. But you can generally classify that it's used for inter-site communications and intra-site submission. Port 587 is for submissium, intra-site and extra-site. Just because you only allow port 80 inbound to the machines which are supposed to be running webservers doesn't mean you only allow outbound port 80 traffic to those same machines ? You would allow outbound port 80 traffic to the whole world... Nils Regards, JP Velders
More on Vonage service disruptions...
advancedIPpipeline is running another article this morning in their series of articles covering the Vonage service disruptions that [allegedly] invlove an ISP port blocking SIP connectitity between Vonage's client equipment and Vonage's servers. While there is a bit more decriptive detail in this article involving the nature of the service interruptions, Vonage's CEO, Jeffrey Citron, is trying to make a [in my opinion] weak argument that this type of traffic blocking is akin to censorship. http://www.advancedippipeline.com/news/60404589 The silliness of the censorship argument aside, an interesting snippet within this article started me thinking abut the slippery slope which might ensue if any type of legislation is enacted which would attempt to prohibit an ISP from blocking traffic in an effort to keep it [unwanted traffic] from traversing their network: 'It'd be unfortunate to have to pass a law [against port blocking and other types of interference], but we may have to,' Citron said. Though he said he has previously testified against the need for port-blocking regulation, Citron may now change that tune, especially if more network operators start using port-blocking or other techniques to selectively control Internet traffic. It looks to me like this is going to open up a huge can of worms. On one hand, you have ISP's who own their own infrastructure and have every right to prohibit traffic from traversing their network which does not conform to their AUP, business practices, technical standards, etc., or provide revenue. By the same token, and specifically when it comes to things like VoIP, we have these issues involving PUC's, FCC regulations, equal access rights, etc. IANAL (or a policy wonk), and I hope I'm wrong, but it certainly looks like things could get pretty ugly. - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED]
RE: More on Vonage service disruptions...
Those are good points. Someone last week mentioned what I thought was a great list of priorities for an ISP: 1. Keep the network running 2. Remove those violating policies 3. Route packets (or something along those lines) A 30/50/90 kbps unicast stream isn't going to affect #1. I don't think any policies involved in #2 would cover a VoIP service either. That should leave #3 as the default for this traffic. I can picture a DDOS where infected Windows machines could send bogus SIP traffic to Vonage servers; in this case temporary blocking might be needed/justified. But until that happens, blocking SIP is just wrong. Another thing for an ISP considering blocking VoIP is the fact that you're cutting off people's access to 911. That alone has got to have some tough legal ramifications. I can tell you that if my ISP started blocking my Vonage, my next cell phone call would be my attorney... Chuck Church Lead Design Engineer CCIE #8776, MCNE, MCSE Netco Government Services - Design Implementation Team 1210 N. Parker Rd. Greenville, SC 29609 Home office: 864-335-9473 Cell: 703-819-3495 [EMAIL PROTECTED] PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x4371A48D -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fergie (Paul Ferguson) Sent: Wednesday, March 02, 2005 9:46 AM To: nanog@merit.edu Subject: More on Vonage service disruptions... advancedIPpipeline is running another article this morning in their series of articles covering the Vonage service disruptions that [allegedly] invlove an ISP port blocking SIP connectitity between Vonage's client equipment and Vonage's servers. While there is a bit more decriptive detail in this article involving the nature of the service interruptions, Vonage's CEO, Jeffrey Citron, is trying to make a [in my opinion] weak argument that this type of traffic blocking is akin to censorship. http://www.advancedippipeline.com/news/60404589 The silliness of the censorship argument aside, an interesting snippet within this article started me thinking abut the slippery slope which might ensue if any type of legislation is enacted which would attempt to prohibit an ISP from blocking traffic in an effort to keep it [unwanted traffic] from traversing their network: 'It'd be unfortunate to have to pass a law [against port blocking and other types of interference], but we may have to,' Citron said. Though he said he has previously testified against the need for port-blocking regulation, Citron may now change that tune, especially if more network operators start using port-blocking or other techniques to selectively control Internet traffic. It looks to me like this is going to open up a huge can of worms. On one hand, you have ISP's who own their own infrastructure and have every right to prohibit traffic from traversing their network which does not conform to their AUP, business practices, technical standards, etc., or provide revenue. By the same token, and specifically when it comes to things like VoIP, we have these issues involving PUC's, FCC regulations, equal access rights, etc. IANAL (or a policy wonk), and I hope I'm wrong, but it certainly looks like things could get pretty ugly. - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED]
RE: More on Vonage service disruptions...
One the points that I left unsaid, however, is that there may be many, many reasons -- both technically and business-wise -- why an ISP would want to port- filter, or for a better generalization, suppress some traffic. For instance, blocking p2p traffic, or a known worm, whatever. And there very likely may be busine$$ reasons, as well. A corrollary: Is it a denial of service to suppress (dampen) a BGP route when it flaps excessively? Or perhaps an bloack-hole a RBL entry? Most would say not, certainly depending on the reason (self- and Internt-preservation and stability), but certainly someone could arguably make a federal case out of it (levity implied) or similar suppresssions or blocking of traffic. VoIP brings these issues to the forefront. In any event, it's going to be interesting to see how this evolves. - ferg -- Church, Chuck [EMAIL PROTECTED] wrote: Those are good points. Someone last week mentioned what I thought was a great list of priorities for an ISP: 1. Keep the network running 2. Remove those violating policies 3. Route packets (or something along those lines) A 30/50/90 kbps unicast stream isn't going to affect #1. I don't think any policies involved in #2 would cover a VoIP service either. That should leave #3 as the default for this traffic. I can picture a DDOS where infected Windows machines could send bogus SIP traffic to Vonage servers; in this case temporary blocking might be needed/justified. But until that happens, blocking SIP is just wrong. Another thing for an ISP considering blocking VoIP is the fact that you're cutting off people's access to 911. That alone has got to have some tough legal ramifications. I can tell you that if my ISP started blocking my Vonage, my next cell phone call would be my attorney... Chuck Church Lead Design Engineer CCIE #8776, MCNE, MCSE Netco Government Services - Design Implementation Team 1210 N. Parker Rd. Greenville, SC 29609 Home office: 864-335-9473 Cell: 703-819-3495 [EMAIL PROTECTED] PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x4371A48D -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED]
Is anyone actually using OER to do traffic shaping/balancing?
Hit me offlist if you have experience with this actually working for you. -Drew
Re: AOL scomp
On Wed, 2 Mar 2005, Suresh Ramasubramanian wrote: Well - there's a way out, sort of. 1. Route .forwarded email out a separate IP (besides cutting down on accepting and forwarding spam) or 2. Find some way - like an X-Forwarded-For header, that AOL can tag on. --srs Your third option is best. (Excuse the signature-pun. :) SRS does not require SPF, and provides auditability for forwarded mail: http://spf.pobox.com/srs.html -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: More on Vonage service disruptions...
Church, Chuck wrote: Another thing for an ISP considering blocking VoIP is the fact that you're cutting off people's access to 911. That alone has got to have some tough legal ramifications. I can tell you that if my ISP started blocking my Vonage, my next cell phone call would be my attorney... Vonage is not supposed to be a Primary Line Service. IIRC, I got a big flyer with my welcome kit that basically said this is a Communications service, not a Telephone service, and it outlined the differences. What is more stable where you are, your broadband connection or your telephone line to your LEC? (if you still have one). I know in my case at home, the phone line was much more reliable, then my cable modem. I can count the times on 1 hand that I had been without Dial tone in the last 3 years (And I live in a rural area), but my cable modem connection goes out at least once a month. So if My cable modem goes out, I would be effectively without 911 also. As my ISP @ home is not a regulated entity, the only person I can complain to is them, or else take my business elsewhere. Even if the ISP in question is a LEC, normally the ISP side of the house is unregulated. The LEC providesthe circuit, and the ISP provides the bandwidth / services on that circuit. If you ISP decided to block VOIP, your cell phone call should be to their competition to order service from them, and vote with your dollars. Or at least to your ISP to call up and complain. Just my opinion, IANAL (I don't even play one on TV), etc... -Patrick -- Patrick Muldoon Network/Software Engineer INOC (http://www.inoc.net) PGPKEY (http://www.inoc.net/~doon) Key ID: 0x370D752C (A)bort, (R)etry, (P)retend this never happened?
Re: AOL scomp
Date: Wed, 2 Mar 2005 10:25:56 +0530 From: Suresh Ramasubramanian [EMAIL PROTECTED] On Tue, 01 Mar 2005 09:28:31 -0500, Vinny Abello [EMAIL PROTECTED] wrote: I can attest that we do not see the same here as you are seeing (1 in 100). I'd agree more with the 1/3 being stupid AOL users reporting regular messages that were either forwarded from their own account that we host to Well - there's a way out, sort of. 1. Route .forwarded email out a separate IP (besides cutting down on accepting and forwarding spam) or 2. Find some way - like an X-Forwarded-For header, that AOL can tag on. There aready ARE such headers... Resent-From:, Resent-To:, ... --srs -- Suresh Ramasubramanian ([EMAIL PROTECTED]) --- Gregory Hicks| Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3400 San Jose, CA 95134 | Internet: [EMAIL PROTECTED] I am perfectly capable of learning from my mistakes. I will surely learn a great deal today. A democracy is a sheep and two wolves deciding on what to have for lunch. Freedom is a well armed sheep contesting the results of the decision. - Benjamin Franklin The best we can hope for concerning the people at large is that they be properly armed. --Alexander Hamilton
RE: More on Vonage service disruptions...
Yeah, I forgot about the regulation thing. I suppose I'd give the ISP a call first, but I'd expect it to be working within a few hours. But now that cable modem providers themselves are providing VoIP/dialtone, wouldn't those be regulated by the FCC? I know that my cable modem ISP (Charter) has been much more reliable the last few months, as they're doing a bunch of upgrades regarding redundancy. I believe this is to support their new VoIP service. But it still seems to me that blocking someone from making a 911 call would be a lawsuit waiting to happen. Chuck -Original Message- Even if the ISP in question is a LEC, normally the ISP side of the house is unregulated. The LEC providesthe circuit, and the ISP provides the bandwidth / services on that circuit. If you ISP decided to block VOIP, your cell phone call should be to their competition to order service from them, and vote with your dollars. Or at least to your ISP to call up and complain. Just my opinion, IANAL (I don't even play one on TV), etc... -Patrick -- Patrick Muldoon Network/Software Engineer INOC (http://www.inoc.net) PGPKEY (http://www.inoc.net/~doon) Key ID: 0x370D752C (A)bort, (R)etry, (P)retend this never happened?
ingress filter
Hi all I used ingress-loose-template from cisco and applied to my bgp ingress filter. I got the following part of the log files and not sure it is right filter or not Can you help? BGP: 1.2.3.4 rcvd UPDATE about 168.187.178.0/24 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 167.231.51.0/24 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 147.182.199.0/24 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.200.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.208.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.216.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.224.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.232.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.240.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.248.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.200.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.208.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.216.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.224.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.232.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.240.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.248.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.200.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.208.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.216.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.224.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.232.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.240.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.248.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 142.137.192.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 158.222.4.0/24 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 170.210.200.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 163.25.90.0/23 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 163.25.92.0/22 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 163.25.112.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 144.106.82.0/24 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 166.114.156.0/24 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 144.106.82.0/24 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 166.114.156.0/24 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 163.25.90.0/23 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 163.25.92.0/22 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 163.25.112.0/21 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 153.2.228.0/24 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 129.66.96.0/24 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 136.210.48.0/22 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 146.178.26.0/24 -- DENIED due to: filter; BGP: 1.2.3.4 rcvd UPDATE about 153.96.100.0/24 -- DENIED due to: filter;
Re: AOL scomp
Otherwise, I think that it can be helpful in identifying issues. We use it to help advise us with respect to the IADB accreditation database, and what we have found is that yes, there are a lot of complaints for legitimate opt-in mail, but a demonstrable change in *volume* (rather than the valid:invalid complain ratio) can often notify us very early on about a problem mailing by someone listed in IADB. Due to the nature of the senders listed in IADB, typically a what's going on with this?? inquiry will result very quickly in a problem customer of the sender's either getting a clue or getting the boot. Anne Anne P. Mitchell, Esq. President/CEO Institute for Spam and Internet Public Policy http://www.isipp.com http://www.isipp.com/iadb.php Professor of Law, Lincoln Law School of SJ
Re: Heads up: Long AS-sets announced in the next few days
Gert Doering wrote: 2005-03-04: 14:00 UTC: 10-element AS-set 14:30 UTC: withdrawal 16:00 UTC: 25-element AS-set 16:30 UTC: withdrawal Please do not announce AS-sets that contain 5539. We are not part of your experiment, and we don't want to see our AS appear in other people's router error messages. Ok, no problem: we will not include AS 5539 in any of the AS-sets we announce. Regards, Lorenzo
Re: More on Vonage service disruptions...
Yeah, I forgot about the regulation thing. I suppose I'd give the ISP a call first, but I'd expect it to be working within a few hours. But now that cable modem providers themselves are providing VoIP/dialtone, wouldn't those be regulated by the FCC? The phone service is, the ISP isn't. Cableco phone service is not the same as what Vonage provides. Vonage style VoIP is unflatteringly but accurately called parasitic, it sits on top of someone else's network connection without supporting that connection at all, competing with any other IP traffic on the connection, with traffic going back to a switch wherever the VoIP company is. Cableco services use dedicated bandwidth on the cable separate from your normal Internet connection to connect back to their own switch which is typically on the cableco's own network. It's engineered as phone service and is designed to have performance and reliability much more like regular phone service than often-flaky VoIP. The particular case that Vonage has been complaining about is apparently an ISP owned by a small rural telco. Rural telcos tend to have very low rates (since your local calling area is small) but high costs (since they have few customers spread over a large area), with the difference made up by universal service funds. A large part of the USF money is access fees on each minute of incoming or outgoing phone calls, so if you use VoIP rather than POTS, the revenue they lose is a lot more than the $20/mo or whatever the local phone rates are. The quality of management at those telcos varies a lot (mine is pretty good, but others can barely find their own shoelaces) and it's not at all surprising that one of them would panic and block applications that are siphoning off their access minutes. The solution is to rationalize USF so it's paid at reasonable rates to whoever is providing service to high-cost customers, but the political obstacles to doing so are high. Western Wireless after a lot of arguing got USF money to provide cell service to underserved or unserved rural areas, but I've never heard of VoIP going that route. Since you first have to admit you're a phone company to apply for the USF gravy train, you can see why parasitic VoIP providers might feel a little conflicted. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor A book is a sneeze. - E.B. White, on the writing of Charlotte's Web
Comcast Contact. (was: RE: AOL scomp)
Pardon my interruption of the ongoing discussion of SMTP trust models and FUSSPs (which I think is very important BTW), but if there is somebody from Comcast here that can help us solve an immediate related issue, please contact me or one of my postmasters off list? Normal channels have been attempted unsuccessfully, for a problem that has been repeating itself every few days for the past two months. --chuck goolsbee digital.forest inc, seattle, wa http://www.forest.net [EMAIL PROTECTED] - [EMAIL PROTECTED] - 206-838-1630 xt2001 - AIM:chuckgoolsbee or [EMAIL PROTECTED] - [EMAIL PROTECTED] - 877-720-0483 xt 2002 Thanks. --
RE: More on Vonage service disruptions...
Subject: Re: More on Vonage service disruptions... Yeah, I forgot about the regulation thing. I suppose I'd give the ISP a call first, but I'd expect it to be working within a few hours. But now that cable modem providers themselves are providing VoIP/dialtone, wouldn't those be regulated by the FCC? A few quick observations here (my own, personal opinion): To paraphrase an earlier comment a 90K stream is not an issue but what about 10,000's of them? In the circuit switched arena, the LEC's compensate each other for either originating (toll free) or terminating traffic (LD) in a regulated environment. Thus there is some business reason to build the network out to handle the level traffic. That is not the case here (with VoIP), as most ISP's are paying for transport, peering connections, backhaul circuits, internal network bandwidth, etc. The IP Phone providers may be paying THEIR ISP, but the $$'s don't nescessarily flow down to the ISP that the customer is connected to. That end user's ISP must now pay more for transit, plus beef up their internal network infrastructure to handle the additional traffic. That would result in having to raise rates, perhaps making the previously viable, dirt cheap, VoIP look like not so competitive a choice (vs. traditional dialtone) to the end user anymore. A question to ponder - what would happen to your network , from both a technical and financial perspective if all of your customers circuit switched voice traffic suddenly became ip?
Re: More on Vonage service disruptions...
At 09:46 AM 3/2/2005, you wrote: advancedIPpipeline is running another article this morning in their series of articles covering the Vonage service disruptions that [allegedly] invlove an ISP port blocking SIP connectitity between Vonage's client equipment and Vonage's servers. While there is a bit more decriptive detail in this article involving the nature of the service interruptions, Vonage's CEO, Jeffrey Citron, is trying to make a [in my opinion] weak argument that this type of traffic blocking is akin to censorship. Actually, anticompetitive, and restraint-of-trade come in as better arguments. They go along with blocking port 587/110, keeping users from getting at legitimate, well-run remote mail servers. The end user paid for packet service, and the Internet generally permits any protocol to be run. ISPs legitimately block traffic at various protocol levels to deal with security and abuse matters. That's unlikely with VOIP. Blocking for dealing with security issues is one matter. Blocking to purposely harm competition is another, and will indeed open a can of worms if it persists.
RE: More on Vonage service disruptions...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A question to ponder - what would happen to your network , from both a technical and financial perspective if all of your customers circuit switched voice traffic suddenly became ip? Offer a Quality of Service product to enhance voice over IP services. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (FreeBSD) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQFCJgYSTs2s3OoD6D8RArMaAKCUp8d94CdTl8LTfQX8Mr4A0ae39QCfRQY0 daj961eow3trG4AFE9W9uBo= =twQA -END PGP SIGNATURE-
RE: More on Vonage service disruptions...
[EMAIL PROTECTED] wrote: Subject: Re: More on Vonage service disruptions... Yeah, I forgot about the regulation thing. I suppose I'd give the ISP a call first, but I'd expect it to be working within a few hours. But now that cable modem providers themselves are providing VoIP/dialtone, wouldn't those be regulated by the FCC? A few quick observations here (my own, personal opinion): To paraphrase an earlier comment a 90K stream is not an issue but what about 10,000's of them? In the circuit switched arena, the LEC's compensate each other for either originating (toll free) or terminating traffic (LD) in a regulated environment. Thus there is some business reason to build the network out to handle the level traffic. That is not the case here (with VoIP), as most ISP's are paying for transport, peering connections, backhaul circuits, internal network bandwidth, etc. The IP Phone providers may be paying THEIR ISP, but the $$'s don't nescessarily flow down to the ISP that the customer is connected to. That end user's ISP must now pay more for transit, plus beef up their internal network infrastructure to handle the additional traffic. That would result in having to raise rates, perhaps making the previously viable, dirt cheap, VoIP look like not so competitive a choice (vs. traditional dialtone) to the end user anymore. A question to ponder - what would happen to your network , from both a technical and financial perspective if all of your customers circuit switched voice traffic suddenly became ip? I think you answered your own question. ISP's would have to raise rates, and voip may suddenly be not as attractive a choice for phone service. It seems to me that market forces will handle this problem rather nicely on their own. Right now VoIP providers and users are getting a bit of a free lunch. It's certain not to last. Andrew
RE: More on Vonage service disruptions...
Ah, and therein lies the rub. Any sort of QoS frob that is implemented for VoIP (or any other traffic for that matter) _must_ be truly honored end-to-end, and at every intermediate hop in between, for it to be guaranteed -- otherwise when traffic that you may designate as higher quality is handed off to another administrative domain that does not honor your traffic classifications, all bets are off. If you do not own the end-to-end network infrastructure, there is no way to guarantee any preferential handling of any particular subset of traffic. - ferg (who has been down this QoS road a few times before) -- Jeff Rosowski [EMAIL PROTECTED] wrote: A question to ponder - what would happen to your network , from both a technical and financial perspective if all of your customers circuit switched voice traffic suddenly became ip? Offer a Quality of Service product to enhance voice over IP services. -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED]
Re: Heads up: Long AS-sets announced in the next few days
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2005-03-02, at 19.38, James A. T. Rice wrote: This seems to suggest that you are just picking ASns at random to inject into the paths, and that you don't have a set of ASs which you have the assignees permission to use. Would't this then actually equate to resource hijacking along the lines of prefix hijacking? Who will be the first to hit the RIRs? - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.1 iQA/AwUBQiYNZ6arNKXTPFCVEQL/sgCdHCBV87HM9jIgNATJhpW5aON/1TwAniAR i1p06marP5ra05ey9YcxX90f =W+rc -END PGP SIGNATURE-
RE: More on Vonage service disruptions...
At 01:24 PM 3/2/2005, you wrote: Subject: Re: More on Vonage service disruptions... Yeah, I forgot about the regulation thing. I suppose I'd give the ISP a call first, but I'd expect it to be working within a few hours. But now that cable modem providers themselves are providing VoIP/dialtone, wouldn't those be regulated by the FCC? A few quick observations here (my own, personal opinion): To paraphrase an earlier comment a 90K stream is not an issue but what about 10,000's of them? Did you (the ISP) sell customers a service saying they'd get 384Kbps upstream, 2Mbps downstream, or some such? And now you say that you can't handle that traffic load? False advertising? In the circuit switched arena, the LEC's compensate each other for either originating (toll free) or terminating traffic (LD) in a regulated environment. Thus there is some business reason to build the network out to handle the level traffic. That is not the case here (with VoIP), as most ISP's are paying for transport, peering connections, backhaul circuits, internal network bandwidth, etc. The IP Phone providers may be paying THEIR ISP, but the $$'s don't nescessarily flow down to the ISP that the customer is connected to. ISPs charge for a service of pushing packets around, and make commitments about the amount of that traffic. That it's digitized voice in those packets isn't really the ISP's business. If you can't meet your commitments to your customers for bandwidth, you need to buy more. Of course you oversell your bandwidth, but that's NOT your customer's problem, it's yours. That end user's ISP must now pay more for transit, plus beef up their internal network infrastructure to handle the additional traffic. That would result in having to raise rates, perhaps making the previously viable, dirt cheap, VoIP look like not so competitive a choice (vs. traditional dialtone) to the end user anymore. If the user is instead playing an interactive game with a friend in another city, do you wish to block that too? How about a PC-to-PC video chat? How about remote corporate offices using VPNs to push lots of traffic around? What are you selling your customers? If your rates don't cover your costs, then your business model is broken. You made a commitment to customers for an amount of bandwidth, and now the customers are actually starting to use it. The problem is one for your board room. If you built your network assuming the only traffic would be Email (to your own servers) and Web (which you cache on your own servers) then you are in for trouble. The Internet is not email and web. That many users are only recently learning that is not their problem. A question to ponder - what would happen to your network , from both a technical and financial perspective if all of your customers circuit switched voice traffic suddenly became ip? You raise good points, but I'd encourage you to decouple them from VOIP, as most any application could cause the same.
Re: AOL scomp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yo Joe! On Tue, 1 Mar 2005, Joe Maimon wrote: Apparently the ratio of valid/invalid AOL notifications is a usefull indicator on the cleanliness of the relevant network. Or it just may tell you the clue level of the recipients. I run a mail server that only sends alerts to paying customers. These customers pay several hundred dollars a year for these alerts. The subject line and body text are clearly tagged as to the sedning source. AOL users STILL report it as spam! I have tried to get AOL to whitelist our server but no luck. RGDS GARY - --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFCJhJR8KZibdeR3qURAkJsAKCORAdYmHPYM3rbUEaGxFuJ6KkdUACfYVZF PIlSidJJwnYT5hoSxa1nur8= =S6CI -END PGP SIGNATURE-
So, anyone still using Redbus?
Ouch . . . http://www.theregister.co.uk/2005/03/01/rebdus_power_failure/. Sincerely, Joe Johson www.JoeLovesDreamweaver.com [EMAIL PROTECTED]
Re: Heads up: Long AS-sets announced in the next few days
James A. T. Rice wrote: This seems to suggest that you are just picking ASns at random to inject into the paths, and that you don't have a set of ASs which you have the assignees permission to use. In which case please keep AS8330, AS8550, and AS8943 out of your experiments too. Using not yet allocated ASns out of RIPEs asn-blocks would have been more sensible, IMHO. James, we are not picking ASes at random. The AS-set announcements are part of new techniques we are developing for ISPs who wish to discover how their prefixes are seen by the rest of the Internet. We believe this will come to be a useful tool for operators. However, since this is still work in progress, and in scientific research there is no room for second place, I can't really reveal any more than that at the moment. I would like to point out, though, that our research group does have a proven track record in the field network discovery (examples available on request), and has created software useful to the operator community such as BGPlay [1][2]. That said, if you want us to exclude those ASes from our AS-sets, then we will do so. Regards, Lorenzo [1] http://www.ris.ripe.net/bgplay/ [2] http://bgplay.routeviews.org/bgplay/
Re: So, anyone still using Redbus?
Sure, the other two buildings still work. Hex has had a history of power problems. I'm in Sovereign and it's been OK so far. Of course we have other buildings as anything can break (e.g. 25 Broadway) We host ecommerce sites turning over million of pounds, pay redbus a significant amount of money for their service sounds like they need to spend some of those millions on site redundacy brandon
Re: More on Vonage service disruptions...
The subject is of most concern at the edge. There are multiple long-haul providers, but often the consumer has only one option for multi-megabit connectivity. The entity currently enjoying the edge monopoly attempts to create vertical service alignment, to maximize profit. They DON'T want to provide packet data service, they want to provide ALL services (control content, filter, etc). This is not a technical matter, it's senior staff maximizing rate of return. To diverge from VoIP, an interesting situation will present itself in the future. Verizon is installing FTTH. Data offerings in their present service area are: 5, 15, and 30Mbps downstream. http://www22.verizon.com/fiosforhome/channels/fios/root/package.asp These speeds would support broadcast quality video delivery (even HD quality) if properly implemented. As hot a topic as voice is, the total money involved is decreasing. Video services, however, still represent a huge revenue stream. Will Verizon be a pure pipe provider? Or, will they attempt to control services? It would be nice to see Comcast get some meaningful competition. Till now, they could never find the money to upgrade or maintain their RF plant, but they had money available to pursue acquisition of Disney... As troublesome as VoIP may (appear) to be, imagine video. Very high duty-cycle, multi-megabit streams. 36ccs, so to speak. But, content creators could sell directly to end users. Potentially, no cable company, no TV networks. Perhaps even the studio structure will collapse. A lot depends on how well the FTTH providers, and their long-haul backbone partners do their job. Whether they embrace disruptive change, or resist it as an annoyance to their routine.
Re: More on Vonage service disruptions...
Actually, anticompetitive, and restraint-of-trade come in as better arguments. They go along with blocking port 587/110, keeping users from getting at legitimate, well-run remote mail servers. The end user paid for packet service, and the Internet generally permits any protocol to be run. ISPs legitimately block traffic at various protocol levels to deal with security and abuse matters. That's unlikely with VOIP. Blocking for dealing with security issues is one matter. Blocking to purposely harm competition is another, and will indeed open a can of worms if it persists. The anticompettive argument is pretty dangerous. What if ISP A has VoIP serice offering and is provisioning QoS for their VoIP service. At the same time they are not providing any QoS for competing services or even degrade service quality for competitors via bandwidth management. From the ISPs perspective it makes perfect sense to beef up bandwidth to offer VoIP to be able to carry traffic from paying VoIP subscribers. But it doesn't make sense to beef up bandwidth to support the competition. What it'll come down to is a definition of what services you average ISP provides. What is internet access, a raw pipe to that indiscriminately moves any packet from point A to point B? Obviously not, since there are already restrictions on running servers, blocking of smtp, etc. So it is perfectly reasonable, IMHO, for an ISP to regulate bandwidth availability to please the majority of paying customers. Adi
Re: More on Vonage service disruptions...
So...how much of the revenue stream is built around the actual facilities (i.e. copper, fiber, etc) ownership monopoly? Shouldn't senior staff recognize the short-sightedness of building one revenue stream from two distinct sources: one content delivery and one plant ownership? Sell access first for a profit and then add ala carte services for a profit, don't mix them. Brad Swanson [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert M. Enger Sent: Wednesday, March 02, 2005 1:57 PM To: Fergie (Paul Ferguson); nanog@merit.edu Subject: Re: More on Vonage service disruptions... The subject is of most concern at the edge. There are multiple long-haul providers, but often the consumer has only one option for multi-megabit connectivity. The entity currently enjoying the edge monopoly attempts to create vertical service alignment, to maximize profit. They DON'T want to provide packet data service, they want to provide ALL services (control content, filter, etc). This is not a technical matter, it's senior staff maximizing rate of return. To diverge from VoIP, an interesting situation will present itself in the future. Verizon is installing FTTH. Data offerings in their present service area are: 5, 15, and 30Mbps downstream. http://www22.verizon.com/fiosforhome/channels/fios/root/package.asp These speeds would support broadcast quality video delivery (even HD quality) if properly implemented. As hot a topic as voice is, the total money involved is decreasing. Video services, however, still represent a huge revenue stream. Will Verizon be a pure pipe provider? Or, will they attempt to control services? It would be nice to see Comcast get some meaningful competition. Till now, they could never find the money to upgrade or maintain their RF plant, but they had money available to pursue acquisition of Disney... As troublesome as VoIP may (appear) to be, imagine video. Very high duty-cycle, multi-megabit streams. 36ccs, so to speak. But, content creators could sell directly to end users. Potentially, no cable company, no TV networks. Perhaps even the studio structure will collapse. A lot depends on how well the FTTH providers, and their long-haul backbone partners do their job. Whether they embrace disruptive change, or resist it as an annoyance to their routine.
Re: Internet Email Services Association
* [EMAIL PROTECTED] (Todd Vierling) [Tue 01 Mar 2005, 19:18 CET]: On Tue, 1 Mar 2005 [EMAIL PROTECTED] wrote: [..] These core operators sign up to a multilateral mail peering agreement and provide email transit services for other operators. The next layer is the non-core email service providers who have bilateral mail peering agreements with one or more core email transport providers. Contrary to what you said before, this *IS* the UUCP model in a nutshell. It has been done before, it does not scale, and it does not fit the way business works today. It looks more like the way the GPRS roaming world has been set up by a few telcos. I don't think that's how you necessarily want to shape your e-mail roaming agreements, let alone *all* e-mail exchanges. -- Niels. -- The idle mind is the devil's playground
Re: AOL scomp
On Wed, 2 Mar 2005 11:15:51 -0500 (EST), Todd Vierling [EMAIL PROTECTED] wrote: Your third option is best. (Excuse the signature-pun. :) SRS does not require SPF, and provides auditability for forwarded mail: http://spf.pobox.com/srs.html In which case dont futz about with SES (thats yet another name for SRS i think, I prefer to think I'm the only SRS around) - use BATV instead. Its specced for exactly what #3 says. srs -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: Is anyone actually using OER to do traffic shaping/balancing?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Drew Weaver wrote: | Hit me offlist if you have experience with this actually | working for you. I'd be interested in seeing a summary of responses on-list if you wouldn't mind. - -- ~ /\ ~ \ / ASCII RIBBON CAMPAIGN ~ XAGAINST HTML MAIL ~ / \ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCJkkf25hr1at2zS8RArbbAKDR1Ys2nXMSeoCHwOOy7ZkDtNfnTgCgwSnT UtVsAWHrshN44V44n/nYa0Y= =Unp1 -END PGP SIGNATURE-
Localizing traffic using BGP
Hello all, BGP design question. My scenario is very much like an online gaming company with servers on multiple continents. Details : 1. I have datacenters/servers in many POPs globally. 2. I am a stub AS with multiple ISPs available at each POP. 3. I do not have the resources to buy dedicated fiber to link these POPs, so my backbone is essentially a bunch of VPN tunnels. 4. I own a /21. Of which I announce /24's. 5. I have a mechanism to allocate client sessions to any ONE of the POPs based on network performance (which is what I want to optimize). Questions : I presently announce different /24's out of different POPs to localize traffic. All these prefixes are announced from the same AS number. This obviously can't be best practice. Are there any published BCPs or RFCs tackling this issue ? Is it recommened that I get multiple AS numbers and announce symmetrically from each smaller AS ? Or should I announce inconsistently from different locations ? Thanks!
Re: More on Vonage service disruptions...
Patrick Muldoon wrote: What is more stable where you are, your broadband connection or your telephone line to your LEC? (if you still have one). I know in my case at home, the phone line was much more reliable, then my cable modem. I can count the times on 1 hand that I had been without Dial tone in the last 3 years (And I live in a rural area), but my cable modem connection goes out at least once a month. You are starting with a faulty assumption - that you *know* when your phone service has been interrupted. Unless you have some sort of special dialtone test going 24x7x365, you have no way of knowing when your phone service was unavailable except if that unavailability coincided with a time when you tried to place a call. If it coincided with a time when someone tried to dial into you, they most likely didn't realize that their inability to reach you was due to a service interruption and probably didn't notify you about the problem if/when they were able to reach you at a later time. Where I am (in the geographic center of Silicon Valley) we have had power interruptions significant enough to reset digital clocks at least 5 times in the past 12 months. I suspect that POTS has been similarly interrupted even if I don't have any direct evidence of those interruptions. jc
RE: More on Vonage service disruptions...
On Wed, 2 Mar 2005, Fergie (Paul Ferguson) wrote: Ah, and therein lies the rub. Any sort of QoS frob that is implemented for VoIP (or any other traffic for that matter) _must_ be truly honored end-to-end, and at every intermediate hop in between, for it to be guaranteed -- otherwise when traffic that you may designate as higher quality is handed off to another administrative domain that does not honor your traffic classifications, all bets are off. If you do not own the end-to-end network infrastructure, there is no way to guarantee any preferential handling of any particular subset of traffic. So, set your Rate-Limiting of SIP traffic to 1 packet per second for the network that YOU control and then offer your VoIP subscribers a different QOS profile at a higher cost. Bingo, problem solved. The economy will work itself out. -- Vice President of N2Net, a New Age Consulting Service, Inc. Company http://www.n2net.net Where everything clicks into place! KP-216-121-ST
RE: Heads up: Long AS-sets announced in the next few days
Ok, I realize I might have given the wrong impression here. Sorry. So here's what we are doing: by artificially inserting ASes into the AS-set of an announcement, the ISP that makes the announcement can control where the announcement is propagated and thus discover paths followed by its announcements that are not usually visible, giving it a more complete knowledge of network topology in the vicinity. Please just clarify the following point: do you intend to advertise paths containing AS numbers belonging to other entities on the public Internet without the permission of the owners of those AS numbers? You admit that you don't know what the consequences of this injection will be. It seems to me that there are enough issues with this type of experimentation *with* the permission of the AS numbers you plan to use. But the ethical issues with using them without such permission seems to me to be insurmountable. DS
Re: Localizing traffic using BGP
Well, the most specific prefix wins in the forwarding selection process, but I won't make any comments on best current practice since best is somewhat relative to the idea of max-aggregation but this reference might help: G. Huston Request for Comments: 3221 Commentary on Inter-Domain Routing in the Internet ftp://ftp.rfc-editor.org/in-notes/rfc3221.txt [snip] 5.4 Lack of Common Operational Practices There is considerable evidence of a lack of uniformity of operational practices within the inter-domain routing space. This includes the use and setting of prefix filters, the use and setting of route damping parameters and level of verification undertaken on BGP advertisements by both the advertiser and the recipient. There is some extent of 'noise' in the routing table where advertisements appear to be propagated well beyond their intended domain of applicability, and also where withdrawals and advertisements are not being adequately damped close to the origin of the route flap. This diversity of operating practices also extends to policies of accepting advertisements that are more specific advertisements of existing provider blocks. [snip] - ferg -- Ashe Canvar [EMAIL PROTECTED] wrote: Hello all, BGP design question. My scenario is very much like an online gaming company with servers on multiple continents. Details : 1. I have datacenters/servers in many POPs globally. 2. I am a stub AS with multiple ISPs available at each POP. 3. I do not have the resources to buy dedicated fiber to link these POPs, so my backbone is essentially a bunch of VPN tunnels. 4. I own a /21. Of which I announce /24's. 5. I have a mechanism to allocate client sessions to any ONE of the POPs based on network performance (which is what I want to optimize). Questions : I presently announce different /24's out of different POPs to localize traffic. All these prefixes are announced from the same AS number. This obviously can't be best practice. Are there any published BCPs or RFCs tackling this issue ? Is it recommened that I get multiple AS numbers and announce symmetrically from each smaller AS ? Or should I announce inconsistently from different locations ? Thanks! -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED]
