Re: What application runs on port 8094?
On Wed, 17 Aug 2005, Aaron Glenn wrote: On 8/17/05, Joe Shen [EMAIL PROTECTED] wrote: Hi, Using netflow based monitor tool, I noticed there is a lot of traffic on 8094/UDP and 4662/TCP( both exceed 1Gbps, and exist all the time) What application use that port? Is there any P2P application use UDP as transportation protocol? eMule uses 4662. quick google search (which I hope you already did before posting) turns up nothing interesting for 8094 (I'm thinkin BitTorrent, personally) Since the traffic was 8094/UDP it is definitely not BitTorrent, who uses TCP transport. /leg
Re: FCC Issues Rule Allowing FBI to Dictate Wiretap-Friendly Design for In ternet Services
On Sun, 7 Aug 2005 [EMAIL PROTECTED] wrote: Agreed. However, in this case it matches a fature I've wanted for years. Being able to mirror packets to a different port is pretty common for managed switches, and is rather useful sometimes in tracking abuse and similar. I *want* the same capability for my routers. ...but your particular routers already have this capability, and it's been there for quite a while too, haven't you read the documentation? :) http://www.juniper.net/techpubs/software/junos/junos71/swconfig71-services/html/flow-monitoring-config17.html /leg
Re: BCP regarding TOS transparancy for internet traffic
On Wed, 25 May 2005, Eric A. Hall wrote: On 5/25/2005 2:50 PM, Saku Ytti wrote: Beatiful idea, how in practice do you suggest this is done, how will my router know if it should just ignore the TOS bytes or do expedited forwarding as configured for given value of TOS byte? VLANs? Different route paths? Any of a dozen other ways to limit special processing to the networks that have paid for it and dump everybody else into the best-effort pool? So what you are saying is basically that ISPs should NOT offer any premium service at all over their internet access products, and only do so over dedicated provider-based VPNs, be it on L2 or L3 (MPLS/2547)? How about VoIP, should we build a parallell internet for that if we want to actually treat the traffic preferentially? If not, how do you propose we do NOT honor the traffic that we have NOT gotten paid for but that someone has merely tagged with a DSCP they know we will treat better? I.e. my customer with two offices who run their own IPSec tunnel between, should in other words no longer be able to pay me for improved delivery without buying a full VPN offering from me (which they don't really need, or want)? /leg
Re: BCP regarding TOS transparancy for internet traffic
On Wed, 25 May 2005, Eric A. Hall wrote: On 5/25/2005 3:42 PM, Lars Erik Gullerud wrote: I.e. my customer with two offices who run their own IPSec tunnel between, should in other words no longer be able to pay me for improved delivery without buying a full VPN offering from me (which they don't really need, or want)? If they don't need or want special handling what are they paying for? But since they are paying for it, perhaps its up to you to figure out how to deliver on your promise. But here is what you don't seem to understand - I DO deliver on my promise. Said customer's packets WILL get special handling, my backbone routers will happily put whatever packets they tag with a non-BE DSCP in the appropriate queues as the packet traverses the network. Or if they prefer, we can even tag it FOR them on the access router they are connected to. Where's the offloaded complexity you refer to? The general population, who does NOT pay for that privilege, gets the BE-treatment, which is what they pay for. And that requires a rewrite of the DSCP/TOS for said traffic, otherwise how do you prevent packets from the general population filling up the queues you have reserved for the customers who pay you more? Rewrite-to-BE is pretty commonplace these days you know. If I understand you correctly, you are saying this service (which a lot of ISPs offer, and a lot of customers pay them for), has no right to exist, and everyone should go out and buy provider-based VPNs or dedicated L2 connectivity instead. The thing is - not all customers WANT a provider-based VPN. And if customers want something, you can be sure providers are selling it. And yet, getting somebody to pay for something/nothing (as the case may be) doesn't come with a license to manhandle everybody else's traffic. Sure it does. There is this new thing called the marketplace. If you pay me for special treatment, I will give you special treatment. If you don't, then I will carry your traffic according to the terms in your contract, which, in the case of best-effort service, is best-effort service. If you are unhappy with the service, you can buy a different service, or choose a different supplier. That being said, I don't believe ANYONE has ever complained about their packets being manhandled by the DSCP being rewritten to BE - even customers seem to understand that you get what you pay for, and special treatment in the form of QoS costs more money. /leg
Re: Stupid Ipv6 question...
On Fri, 2004-11-19 at 16:36, Stephen Sprunk wrote: /127 prefixes are assumed for point-to-point links, and presumably an organization will divide up a single /64 for all ptp links -- unless they have more than 9,223,372,036,854,775,808 of them. While that would seem logical for most engineers, used to /30 or /31 ptp links in IPv4 (myself included), that does not in fact seem to be the way things are currently done in IPv6, unless something changed (again) while I wasn't paying attention... /64 is the minimum subnet size, even for ptp-links - there was even an RFC published relating to the use of /127's (or, should I say, the recommendation to don't to that), namely RFC3627 (aka Use of /127 Prefix Length Between Routers Considered Harmful). But, you can still get 65536 ptp links out of a single /48 of course. I'm sure Pekka or others will jump in here and correct me if this is now out-of-date info. :) /leg
RE: optics pricing (Re: Weird GigE Media Converter Behavior)
On Tue, 31 Aug 2004, Simon Lyall wrote: On Mon, 30 Aug 2004, Mark Borchers wrote: Everybody's entitled to their opinion, but this excerpt from http://www.ietf.org/ietf/IPR//VRRP-CISCO does not seem to me to portend predatory pricing: However it does make an open source (and certainly a free) implimentation very difficult to do. Then there's always the option to implement something else. Hm, where can I order a CARP license again...? http://www.openbsd.org/lyrics.html#35 /leg
Re: Poor connectivity to new b.root-servers.net address?
On Wed, 4 Feb 2004, Erik-Jan Bos wrote: Looks OK from SURFnet (AS1103) through Level3: [...] Hm - both through 3561 (CW) and 3549 (GBLX) in Europe (tracing from source-IP's on our border routers from the respective providers' netblocks, and our own IP's), we have no connectivity. Both paths go via Level3. /leg
Re: Root Server Operators (Re: What *are* they smoking?)
On Tue, 2003-09-16 at 18:50, William Allen Simpson wrote: Please note that the people running the root nameservsers are a different set from the people who run the .com and .net nameservers. True, these days, at least in part. Since the latest zone for .net (and maybe .com according to the announcement) contains data that * indicates existance for domains that actually do not exist, and * incorrect addresses for domains that exist, but are not using the name service of netSOL cum verisign, it is arguably not a valid zone file. Therefore, any root server operators should refuse the improper zone file. Whether the .net and .com zone files are valid or not is really irrelevant for your argument - since the zone file served by the root servers is only for the . zone, not the .net or .com zones any more. The zone file the _root servers_ hold IS therefore a valid zone file. Whatever junk Verisign puts into the com. and net. zones does not implicate the . zone servers at all. /leg
Re: GLBX ICMP rate limiting (was RE: Tier-1 without their ownbackbone?)
On Thu, 2003-08-28 at 17:37, Steve Carter wrote: I speak for Global Crossing when I say that ICMP rate limiting has existed on the Global Crossing network, inbound from peers, for a long time ... we learned our lesson from the Yahoo DDoS attack (when they were one of our customers) back in the day and it was shortly thereafter that we implemented the rate limiters. Over the past 24 hours we've performed some experimentation that shows outbound rate limiters being also of value and we're looking at the specifics of differentiating between happy ICMP and naughty 92 byte packet ICMP and treating the latter with very strict rules ... like we would dump it on the floor. This, I believe, will stomp on the bad traffic but allow the happy traffic to pass unmolested. I think I can safely say that GBLX is beyond looking at the specifics of dropping 92-byte ICMP's, and are in fact doing it. And have not really bothered telling their customers about it either. We happen to use GBLX as one of our upstreams, and have a GigE pipe towards them. Since MS in their infinite wisdom seem to use 92-byte ICMP Echos in the Windows tracert.exe without having any option to use another protocol and/or packetsize, this certainly has generated several calls to OUR support desk today, by customers of ours claiming your routing is broken, traceroutes aren't getting anywhere!. Although I obviously understand the reasons, it WOULD be nice if if a supplier would at least take the trouble to inform us when they start applying filters to customer traffic, so our helpdesk would be prepared to answer questions about it. We are not a peer, but a paying customer after all. Oh, and it is not rate-limiting causing this, it is most definitely 92-byte filters. traceroute -P icmp www.gblx.net 92 from a decent OS will drop, any other packetsize works like a charm. /leg
Re: UPS failure modes (was: fire at NAC)
On Thu, 2003-05-29 at 18:31, Robert Boyle wrote: I had a little 2000VA rackmount Liebert UPS catch fire in 1997 and another new and improved Liebert model almost catch fire about a year later. Both were operating well within specified input, load, and temperature parameters. I haven't really trusted them since.I bought dual MGE UPSes for our datacenter in 2002. I figured if Es can flip them on and off randomly and massively overload them all in an environment which is 95 degrees F, then they should hold up nicely for us when lightly loaded at 65 degrees F. :) I am personally of the opposite opinion, we have never had any issues with our Liebert UPS'es, however we have had a few MGE's blow up. I can't comment on their small UPS models though, I think the smallest MGE or Liebert we have is 10KVA. The worst of the cases was an installation where we had dual 40KVA MGE UPS'es installed, both of whom failed critically within 48 hours of each other. Despite all the fail-safe circuitry they were bought with, they failed HARD (and yes, they had sparks and smoke coming out of them), and not even the bypass features worked. Since the second failed before the first one had been completely restored (it was being investigated to find the root cause of this critical failure), things went very black, and electricians had a pretty hectic time as they had to manually bypass the UPS'es completely and feed grid power directly to the facility. Unfortunately these two were bought at the same time (and came from the same production batch), so they had the same fault - which was apparently a bad shipment of capacitors which started to leak fluid after a period of time. Due to some unfortunate design choices in the MGE's, these capacitors happened to be placed directly above the main controller circuitry, and the leaky capacitors eventually caused the whole thing to short, in a rather spectacular way I might add. And yes, the bypass failed as well, we were explained the reason for this by the engineers from MGE although I can't say I remember the details (electricity really isn't my field :). That being said, after the replacement of the fried components, the engineers from MGE came on-site and rebuilt the entire bypass system in these two boxes some time later, at no charge of course - and we have not had any problems with them in the two years they have now been in operation after this incident. /leg
Re: is this true or... ?
On Sat, 2003-03-29 at 02:24, David Schwartz wrote: The laws require an intent to conceal the origin or destination. NAT would not count, as the intent is to share a scarce resource, not to conceal the origin or destination -- the origin is only concealed to the extent necessary to accomplish the sharing. I disagree - I could point you to a bunch of companies who are running NAT _precisely_ to conceal origin or destination. Not because they are short of address space (since a lot of them even do 1:1 NAT), but because they feel it adds to their security measures to obscure and conceal their internal addressing and topology. Don't forget all the self-appointed security experts out there with very varying degrees of clue. I would imagine that type of setup would be very hard to argue falls outside the text of this bill. /leg
Re: route filtering in large networks
On Thu, 2003-03-13 at 04:47, Richard A Steenbergen wrote: Personally I don't think it's too hard to setup some scripts scripts which can apply updated bogon and other important prefix-list updates globally. Rancid and about 15 lines of shell script should do you just fine. If you're lucky enough to have Juniper's, you can use the same prefix-list to filter both routes and packets. Sorry to break in here with something as inappropriate as a technical comment but... Actually, you can't. But it is a common error people do on J boxes. If you use prefix-lists in your routing policy on the Js, they will only match the exact prefix-length specified, not longer prefixes from within it. If you want to match prefixes of any given length within say, a /8 (a typical entry in a bogon list), you have to use route-lists (route-filter statements), which can not be used in your packet filters (firewall config)... /leg
Re: no ip forged-source-address
On Wed, 2002-10-30 at 16:44, [EMAIL PROTECTED] wrote: Therefore, would it be a reasonable suggestion to ask router vendors to source address filtering in as an option[1] on the interface and then move it to being the default setting[2] after a period of time? This appeared to have some success with reducing the number of networks that forwarded broadcast packets (as with no ip directed-broadcast). [snip] [1] For example, an IOS config might be: interface fastethernet 1/0 no ip forged-source-address Well, this already exists, doesn't it? Try the following on your customer-facing interface: ip verify unicast source reachable-via rx [2] Network admins would still have the option of turning it off, but this would have to be explicitly configured. I have a feeling that having strict uRPF as the default setting on an interface would be very badly received by a lot of ISP's. I know I certainly wouldn't like it very much. Is it really the job of router vendors to protect the net from lazy/incompetent/ignorant network admins? /leg
Re: Internet vulnerabilities
Uhm it seems to me people are trying to make this whole AS112-thing sound more complex than it really is... We use the BGP anycast-method in our backbone, and have been doing so for a long time. Basically, we have multiple caching DNS-servers scattered around our network, but all of them use the same IP-adress (well, actually two - since customers expect to configure a primary and a secondary DNS on their computers). The DNS resolvers all run zebra and identify themselves as a private AS, announcing two single host routes (the two DNS resolver-IP's) to the border-router they are connected to. Our customers' DNS queries will be routed to the nearest available server, by the same mechanisms as any other hot-potato routing setup (i.e. MEDs). This works beautifully since we are only dealing with DNS UDP packets. (The servers do also have a unique IP adress for management traffic etc, and these are normally routed in the IGP - but they do not respond to DNS traffic on this IP). That way, we have both load-balancing (customer queries are spread out to the servers who are closest to the customer) and redundancy - if one resolver fails, BGP will use the next available route to get to this prefix. The only difference with the AS112 setup is the fact that you are doing it across several AS'es instead of just inside a single one, but the principle is the same - and just as simple. This is an extremely simple anycast setup for DNS servers, and potentially other simple UDP-based services, we have been using it for a couple of years, and it works beautifully. No new protocols, no complex setups, just normal BGP operation. I even think someone wrote a very good paper on setting up DNS resolvers this way once, though I can't remember where I saw it. --Lars Erik On Friday 05 July 2002 15:05, Marshall Eubanks wrote: On Fri, 5 Jul 2002 13:36:49 +0100 (BST) Stephen J. Wilcox [EMAIL PROTECTED] wrote: Doesnt announcing the same routing prefix into BGP from multiple locations do the same thing without needing a new range or enhancement in IGMP etc ? We do this in IGP currently.. Steve As I see it, the problems with doing this in BGP are - it's static - no failover. If AS 701 and AS 1239 are both announcing a route to foo, and your preferred route is through AS701, and the AS701 foo goes down, then you do not automatically switch over to the AS1239 foo, even if you could reach it. - there is no way to have multiple anycast addresses within an AS - load balancing is tough These may all be solved, though... it's hard to tell without a protocol description. Regards Marshall Eubanks On Fri, 5 Jul 2002, Barry Raveendran Greene wrote: FYI - for those scratching their heads on anycast . I just pushed out a paper on anycast by Chris Metz. Good foundation material. http://www.cisco.com/public/cons/isp/essentials/ip-anycast-cmetz-03.pdf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Woodcock Sent: Friday, July 05, 2002 4:56 AM To: Marshall Eubanks Cc: [EMAIL PROTECTED] Subject: Re: Internet vulnerabilities But the only IPv4 anycast that I know of does use MSDP : http://www.ietf.org/internet-drafts/draft-ietf-mboned-anycast-rp-08.t xt Is there a different proposal ? What's the RFC / I-D name ? You seem to be confusing anycast with something complicated. It's not a protocol, it's a method of assigning and routing addresses. -Bill
