Relationship between DNS requests and server's CPU load
Hi, I want to know, is there any research or analysis on relationship between DNS server load ( e.g. CPU load, Memory utilized) and incoming DNS resolution requests ? Besides those research on name system architecture and cache policy, is there any guideline on planing or optimizing domain name service system ? thanks in advance. Joe Cool Things Happen When Mac Users Meet! Join the community in Boston this July: www.macworldexpo.com
Relationship between DNS requests and server's CPU load
Hi, I want to know, is there any research or analysis on relationship between DNS server load ( e.g. CPU load, Memory utilized) and incoming DNS resolution requests ? Besides those research on name system architecture and cache policy, is there any guideline on planing or optimizing domain name service system ? thanks in advance. Joe Cool Things Happen When Mac Users Meet! Join the community in Boston this July: www.macworldexpo.com
RE: 802.17 RPR and L2 Ethernet interoperablity (Ethernet over RPR)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Sam: We're using the Cisco ML cards in the 15454's. The inbound port from the switch is just a .1Q trunk. The ML cards do the Q-in-Q encapsulation of all frames coming inbound, although this is just one configuration scenario that happened to work well for our application. These particular cards can take any frame up to 9000 bytes, so pre-encapsulated traffic types such a Q-in-Q or MPLS frames are no problem. We have not seen any issues with encapsulated types, but of course, your mileage may vary. Mike > -Original Message- > From: Sam Stickland [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 07, 2004 3:28 AM > To: Michael Smith > Cc: [EMAIL PROTECTED] > Subject: RE: 802.17 RPR and L2 Ethernet interoperablity (Ethernet > over RPR) > > Thanks for the reply. Pretty much everyone has told me that it's > vendor specific, although the implementation mentioned below sounds > nice. Any chance of naming that vendor? > > One question about this, the Q-in-Q tunnelling would have to take > place on the switch connected to the ring - what happens if the > packet has already been placed in a dot1Q tunnel? I haven't really > worked much with dot1Q tunneling - are their any know problems with > extra tags? (aside from MTU issues, but I imagine most rings will > support at least 9bytes) > > Sam > > On Tue, 6 Jul 2004, Michael Smith wrote: > > > Hello: > > > > I think this is pretty provider-specific. However, we are doing > > this right now with a particular vendor using their flavor of > > RPR. The ring uses Q in Q tunneling in the core and all switches > > communicate directly to one another using .1Q encapsulated > > frames. > > > > Mike > > > > > -Original Message- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > > Behalf > > Of > > > [EMAIL PROTECTED] > > > Sent: Tuesday, July 06, 2004 11:50 AM > > > To: [EMAIL PROTECTED] > > > Subject: 802.17 RPR and L2 Ethernet interoperablity (Ethernet > > > over > > RPR) > > > > > > > > > Hi, > > > > > > This is probably a fairly simply question, I'm probably just > > > not quite groking the layers involved here. > > > > > > If I had the following setup: > > > > > > Endstation A -- Switch A === RPR Ring === Switch B -- > > > Endstation B > > > > > > could there be a VLAN setup such that Endstations A and B are > > > both in > > it, > > > and can communicate as if they are on the same LAN segment? > > > (And I > > mean > > > natively. ie. not using an MPLS VPN). ie. Will the switches > > > involved tranlate the different framing formats in use? Is this > > > vendor > > dependent? > > > > > > Sam > > > > > > > > > > -BEGIN PGP SIGNATURE- Version: PGP 8.0.3 iQA/AwUBQOwTjZzgx7Y34AxGEQITygCfVnf2TwHWTM2RKIOlwpWxv2CCop8AoMxK tLDj65xi20rBuWtR6to8uMDq =JWVZ -END PGP SIGNATURE-
RE: 802.17 RPR and L2 Ethernet interoperablity (Ethernet over RPR)
On Wed, 7 Jul 2004, Sam Stickland wrote: > That was my worry - the definition of most. 99% of switches or 60%? This > isn't actually a standard is it, so I presume this behaviour is expected, > but not required? The only way to make sure is to try, but with my (I guess) average insight in ethernet headers I don't see how a double tagged packet would be treated differently by a non Q-in-Q aware switch as long as there is no MTU issue. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
RE: 802.17 RPR and L2 Ethernet interoperablity (Ethernet over RPR)
On Wed, 7 Jul 2004, Mikael Abrahamsson wrote: > > On Wed, 7 Jul 2004, Sam Stickland wrote: > > > One question about this, the Q-in-Q tunnelling would have to take place on > > the switch connected to the ring - what happens if the packet has already > > been placed in a dot1Q tunnel? I haven't really worked much with dot1Q > > tunneling - are their any know problems with extra tags? (aside from MTU > > issues, but I imagine most rings will support at least 9bytes) > > Most switches will only see the outer tag and will thus be transparent for > Q-in-Q:ed packets. That was my worry - the definition of most. 99% of switches or 60%? This isn't actually a standard is it, so I presume this behaviour is expected, but not required? Sam
Re: Proxy scanning for spam
On Tue 06 Jul 2004 (11:08 +0100), Stephen J. Wilcox wrote: > > On Mon, 5 Jul 2004, Christopher J. Wolff wrote: > > > > > Hello, > > > > If I have a network segment connected to a BGP peer, is there a way that I > > can hang a box of some kind off of that segment that will sniff out and > > block malicious/spam email before it hits the customers? > > policy route your port 25 at an adjacent box.. use some sort of iptables rules > to translate the ip address of the box and that will work also. make sure no-one is running a mailserver that expects to do TLS authentication or similar. -- Jim Segrave [EMAIL PROTECTED]
Re: China deploys Internet protocol version 9 network
> Professor Hualin Qian of the Computer Network Information > Center of the Chinese Academy of Sciences I was a guest at CNNIC/CAS in Beijing twice in 2001, where I met Hualin, and see him from time to time at ICANN functions. The address space allocated to China is less than what MIT has, and the necessity, let alone the utility, of forcing encoding into ASCII (any algorithm), and forcing encoding from a particular profoundly broken glyph catalogue (without intermediate mappings), for written Chinese in a specific byte-indifferent standard network infrastructure application, is not helpful for Chinese network users. So yeah, NAT-on-a-China-scale is something reasonable to look into, as is rational relief from, or useful accomodation to, the other problem. Existance of well-known problems however, does not prove necessity, or utility, let alone implementation and adoption of, a particular claim to a solution. Eric
RE: 802.17 RPR and L2 Ethernet interoperablity (Ethernet over RPR)
On Wed, 7 Jul 2004, Sam Stickland wrote: > One question about this, the Q-in-Q tunnelling would have to take place on > the switch connected to the ring - what happens if the packet has already > been placed in a dot1Q tunnel? I haven't really worked much with dot1Q > tunneling - are their any know problems with extra tags? (aside from MTU > issues, but I imagine most rings will support at least 9bytes) Most switches will only see the outer tag and will thus be transparent for Q-in-Q:ed packets. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
RE: 802.17 RPR and L2 Ethernet interoperablity (Ethernet over RPR)
Thanks for the reply. Pretty much everyone has told me that it's vendor specific, although the implementation mentioned below sounds nice. Any chance of naming that vendor? One question about this, the Q-in-Q tunnelling would have to take place on the switch connected to the ring - what happens if the packet has already been placed in a dot1Q tunnel? I haven't really worked much with dot1Q tunneling - are their any know problems with extra tags? (aside from MTU issues, but I imagine most rings will support at least 9bytes) Sam On Tue, 6 Jul 2004, Michael Smith wrote: > Hello: > > I think this is pretty provider-specific. However, we are doing this > right now with a particular vendor using their flavor of RPR. The ring > uses Q in Q tunneling in the core and all switches communicate directly > to one another using .1Q encapsulated frames. > > Mike > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of > > [EMAIL PROTECTED] > > Sent: Tuesday, July 06, 2004 11:50 AM > > To: [EMAIL PROTECTED] > > Subject: 802.17 RPR and L2 Ethernet interoperablity (Ethernet over > RPR) > > > > > > Hi, > > > > This is probably a fairly simply question, I'm probably just not quite > > groking the layers involved here. > > > > If I had the following setup: > > > > Endstation A -- Switch A === RPR Ring === Switch B -- Endstation B > > > > could there be a VLAN setup such that Endstations A and B are both in > it, > > and can communicate as if they are on the same LAN segment? (And I > mean > > natively. ie. not using an MPLS VPN). ie. Will the switches involved > > tranlate the different framing formats in use? Is this vendor > dependent? > > > > Sam > > > > >
Re: China deploys Internet protocol version 9 network
> > China's New Generation Of Ipv9 Network Technology Ready > So they have a nationalized MAC registry? Seems like China has nothing at all but a few people in China know the power of marketing... http://www.theregister.co.uk/2004/07/06/ipv9_hype_dismissed/ . . . Professor Hualin Qian of the Computer Network Information Center of the Chinese Academy of Sciences described IPv9 as a research project that turned out to have serious practical shortcomings and little support. . . . 'nuff said... --Michael Dillon
