Re: What is multihoming was (design of a real routing v. endpoint id seperation)
OK... As entertaining as the debate on the definition of multihomed host is so far, I'd like to point out that on NANOG, we are generally NOT concerned with that term. The term that we are most interested in is multihomed network. I would submit that host multihoming is irrelevant to the charter of NANOG and that the definition of a multihomed network is a network or collection of networks that meet the definition of an autonomous system (whether an ASN is assigned to them or not) which are topologically adjacent to more than one network or collection of networks which each meet the definition of an autonomous system, but, are not, themselves, a single autonomous system or part of the same autonomous system as the network in question. To attempt to translate that into English: Autonomous System: One or more networks which are topologically contiguous and share a common routing policy. Whether an ASN is assigned to an Autonomous System or not is a different matter. If an autonomous system is topologically adjacent to two or more other autonomous system, then, the networks within that autonomous system can generally be said to be multihomed for the purposes of discussions on NANOG. Technically, the AS is multihomed, but, we often use the term network to mean AS or network. Owen pgpjv0ZMZNrfL.pgp Description: PGP signature
Re: Scalability issues in the Internet routing system
Alexei Roudnev wrote: You do not need to forward 100% packets on line card rate; forwarding 95% packets on card rate and have other processing (with possible delays) thru central CPU can work good enough.. heh. in the words of Randy, i encourage my competitors to build a router this way. reality is that any big, fast router is forwarding in hardware - typically an ASIC or some form of programmable processor. the lines here are getting blurry again .. Moore's Law means that packet-forwarding can pretty much be back in software in something which almost resembles a general-purpose processor - or maybe more than a few of them working in parallel (ref: http://www-03.ibm.com/chips/news/2004/0609_cisco.html). if you've built something to be 'big' and 'fast' its likely that you're also forwarding in some kind of 'distributed' manner (as opposed to 'centralized'). as such - if you're building forwarding hardware capable of (say) 25M PPS and line-rate is 30M PPS, it generally isn't that much of a jump to build it for 30M PPS instead. i don't disagree that interfaces / backbones / networks are getting faster - but i don't think its yet a case of Moore's law becoming a problem - all that happens is one architects a system far more modular than before - e.g. ingress forwarding separate from egress forwarding. likewise, FIB table growth isn't yet a problem either - generally that just means put in more SRAM or put in more TCAM space. IPv6 may change the equations around .. but we'll see .. cheers, lincoln.
Re: Scalability issues in the Internet routing system
likewise, FIB table growth isn't yet a problem either - generally that just means put in more SRAM or put in more TCAM space. IPv6 may change the equations around .. but we'll see .. IPv6 will someday account for as many IPv4 networks as would exist then, and IPv6 prefixes are twice as large as IPv4 (64 bits prefix vs 32 bits prefix+address, remainder 64 bits addresses on IPv6 are strictly local), so despite a 3x cost increase (1 32 bit table for IPv4, 2 for IPv6) on memory structures and 2x increase on lookup engine(2 engines would be used for IPv6, one for IPv4), the same techonology that can run IPv4 can do IPv6 at the same speed. As this is not a usual demand today, even hardware routers limit the forwarding table to the sum of IPv4 and IPv6 prefixes, and forward IPv6 at half the rate of IPv4. Rubens
Re: Scalability issues in the Internet routing system
On Wed, Oct 26, 2005 at 12:10:39PM -0200, Rubens Kuhl Jr. wrote: likewise, FIB table growth isn't yet a problem either - generally that just means put in more SRAM or put in more TCAM space. IPv6 may change the equations around .. but we'll see .. IPv6 will someday account for as many IPv4 networks as would exist then, and IPv6 prefixes are twice as large as IPv4 (64 bits prefix vs 32 bits prefix+address, remainder 64 bits addresses on IPv6 are strictly local), so despite a 3x cost increase (1 32 bit table for IPv4, 2 for IPv6) on memory structures and 2x increase on lookup engine(2 engines would be used for IPv6, one for IPv4), the same techonology that can run IPv4 can do IPv6 at the same speed. As this is not a usual demand today, even hardware routers limit the forwarding table to the sum of IPv4 and IPv6 prefixes, and forward IPv6 at half the rate of IPv4. s/64/128/ ...and total, complete, non-sense. please educate yourself more on reality of inet6 unicast forwarding before speculating. Thank you. James
Re: Scalability issues in the Internet routing system
Forwarding is in line cards not because of CPU issues, but because of BUS issues. It means, that card can be software based easily. Anyway, as I said - it is only small, minor engineering question - how to forward having 2,000,000 routes. If internet will require such router - it will be crearted easily. Today we eed 160,000 routes - and it works (line cards,m software, etc - it DO WORK). - Original Message - From: Lincoln Dale [EMAIL PROTECTED] To: Alexei Roudnev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Daniel Senie [EMAIL PROTECTED] Sent: Wednesday, October 26, 2005 2:42 AM Subject: Re: Scalability issues in the Internet routing system Alexei Roudnev wrote: You do not need to forward 100% packets on line card rate; forwarding 95% packets on card rate and have other processing (with possible delays) thru central CPU can work good enough.. heh. in the words of Randy, i encourage my competitors to build a router this way. reality is that any big, fast router is forwarding in hardware - typically an ASIC or some form of programmable processor. the lines here are getting blurry again .. Moore's Law means that packet-forwarding can pretty much be back in software in something which almost resembles a general-purpose processor - or maybe more than a few of them working in parallel (ref: http://www-03.ibm.com/chips/news/2004/0609_cisco.html). if you've built something to be 'big' and 'fast' its likely that you're also forwarding in some kind of 'distributed' manner (as opposed to 'centralized'). as such - if you're building forwarding hardware capable of (say) 25M PPS and line-rate is 30M PPS, it generally isn't that much of a jump to build it for 30M PPS instead. i don't disagree that interfaces / backbones / networks are getting faster - but i don't think its yet a case of Moore's law becoming a problem - all that happens is one architects a system far more modular than before - e.g. ingress forwarding separate from egress forwarding. likewise, FIB table growth isn't yet a problem either - generally that just means put in more SRAM or put in more TCAM space. IPv6 may change the equations around .. but we'll see .. cheers, lincoln.
Re: Scalability issues in the Internet routing system
On Wed, 26 Oct 2005 08:53:50 PDT, Alexei Roudnev said: Anyway, as I said - it is only small, minor engineering question - how to forward having 2,000,000 routes. If internet will require such router - it will be crearted easily. Today we eed 160,000 routes - and it works (line cards,m software, etc - it DO WORK). Forwarding packets is only half the story. Building a routing table is the other half. Route flaps. Even if you have an algorithm that's O(n), 2M routes will take 12.5 times as long to crunch as 160K. If your routing protocol is O(n**2) on number of routes, that's about 150 times as much. Such a router is probably buildable. I'm not at all convinced that it's easy to do so at a price point acceptable for most sites that currently have full routing tables. pgpO2OmBqsQQA.pgp Description: PGP signature
Re: open jabber server and conference room for nanog-arin meeting
after working around some kind of wierd arp problem with my isp, folks using abovenet to reach this jabber server will no longer see timeouts. the room is available all week ([EMAIL PROTECTED]) in case some of us who came to nanog are staying for arin and want to, um, jabber. the server will remain open until something bad happens, so feel free to register, create rooms persistent or otherwise, etc. -- Paul Vixie
Re: Scalability issues in the Internet routing system
On Oct 26, 2005, at 12:12 PM, [EMAIL PROTECTED] wrote: On Wed, 26 Oct 2005 08:53:50 PDT, Alexei Roudnev said: Anyway, as I said - it is only small, minor engineering question - how to forward having 2,000,000 routes. If internet will require such router - it will be crearted easily. Today we eed 160,000 routes - and it works (line cards,m software, etc - it DO WORK). Forwarding packets is only half the story. Building a routing table is the other half. Route flaps. Even if you have an algorithm that's O(n), 2M routes will take 12.5 times as long to crunch as 160K. If your routing protocol is O (n**2) on number of routes, that's about 150 times as much. Such a router is probably buildable. I'm not at all convinced that it's easy to do so at a price point acceptable for most sites that currently have full routing tables. There are definitely performance challenges to overcome. Of course, most route processors are underpowered compared to the existing state of the art for processors so there is some wiggle room. With both Cisco and Juniper we have a nice period of hang time as brand new new routes get installed. Both vendors are playing with layers of abstraction to improve things once up and operational but increasing the amount of time to bring a device online is factor which influences purchasing decisions as well. It does seem appropriate to consider Gigabit sized routing/forwarding table interconnects and working on TCP performance optimization for BGP specifically, if any improvement remains. Combine those things with a chunky CPU and you are left with pushing data as fast as possible into the forwarding plane (need speedy ASIC table updates here). Another thing, it would be interesting to hear of any work on breaking the router code into multiple threads. Being able to truly take advantage of multiple processors when receiving 2M updates would be the cats pajamas. Has anyone seen this? I suppose MBGP could be rather straightforward, as opposed to one big table, in a multi-processor implementation. Regards, Blaine
Re: shim6 @ NANOG (forwarded note from John Payne)
John, On Thu, Oct 27, 2005 at 02:08:50AM +1000, Geoff Huston wrote: From: John Payne [EMAIL PROTECTED] Subject: shim6 @ NANOG Date: Wed, 26 Oct 2005 09:11:45 -0400 Public thanks to Dave, Geoff, Vijay, Ted and Jason for their involvement in bringing shim6 to the NANOG conference. The messages I heard were: 1) Traffic engineering, traffic engineering and traffic engineering - do NOT put this in the hands of the end system, this needs to be site level, or at the very least the site needs to be able to override the end system's decisions. 2) The first hit is of critical importance to content providers (many of whom couldn't legitimately justify a /32). Hunting through DNS to find a locator that works won't fly. 3) It was good to hear in a widespread forum that shim6 is not expected to be THE only multihoming solution. However, we were left uninformed as to where the other work is going on. Thanks. I'd also like to thank Geoff, Jason, Vijay, Ted, and everyone to participated in the BOF. I found the session to be quite productive, and I hope that it will form the foundation for an ongoing dialog. The IAB is hoping to do the next IAB BOF at APRICOT, so with any luck, see you all there. Thanks again all, Dave pgpsscZ7R1Z7A.pgp Description: PGP signature
Re: Scalability issues in the Internet routing system
Blaine Christian wrote: It does seem appropriate to consider Gigabit sized routing/forwarding table interconnects and working on TCP performance optimization for BGP specifically, if any improvement remains. Combine those things with a chunky CPU and you are left with pushing data as fast as possible into the forwarding plane (need speedy ASIC table updates here). I guess you got something wrong here. Neither BGP nor TCP (never has been) are a bottleneck regarding the subject of this discussion. Another thing, it would be interesting to hear of any work on breaking the router code into multiple threads. Being able to truly take advantage of multiple processors when receiving 2M updates would be the cats pajamas. Has anyone seen this? I suppose MBGP could be rather straightforward, as opposed to one big table, in a multi-processor implementation. You may want to read this thread from the beginning. The problem is not the routing plane or routing protocol but the forwarding plane or ASIC's or whatever. Both have very different scaling properties. The forwarding plane is at an disadvantage here because at the same time it faces growth in table size and less time to perform a lookup . With current CPU's you can handle a 2M prefix DFZ quite well without killing the budget. For the forwarding hardware this ain't the case unfortunatly. -- Andre
Re: Scalability issues in the Internet routing system
On Wed, 26 Oct 2005, Andre Oppermann wrote: Blaine Christian wrote: It does seem appropriate to consider Gigabit sized routing/forwarding table interconnects and working on TCP performance optimization for BGP specifically, if any improvement remains. Combine those things with a chunky CPU and you are left with pushing data as fast as possible into the forwarding plane (need speedy ASIC table updates here). I guess you got something wrong here. Neither BGP nor TCP (never has been) are a bottleneck regarding the subject of this discussion. i think he's describing initial table gather/flood and later massage of that into FIB on cards ... which relates to his earlier comment about 'people still care about how fast initial convergence happens' (which is true) Another thing, it would be interesting to hear of any work on breaking the router code into multiple threads. Being able to truly take advantage of multiple processors when receiving 2M updates would be the cats pajamas. Has anyone seen this? I suppose MBGP could be rather straightforward, as opposed to one big table, in a multi-processor implementation. You may want to read this thread from the beginning. The problem is not the routing plane or routing protocol but the forwarding plane or ASIC's it's actually both... convergence is very, very important. Some of the conversation (which I admit I have only watched spottily) has covered this too. or whatever. Both have very different scaling properties. The forwarding plane is at an disadvantage here because at the same time it faces growth in table size and less time to perform a lookup . With current CPU's you can handle a 2M prefix DFZ quite well without killing the budget. For the really? are you sure about that? are you referrinng to linecard CPU or RIB-FIB creation cpu? (be it monolithic design or distributed design) forwarding hardware this ain't the case unfortunatly. this could be... I'm not sure I've seen a vendor propose the cost differentials though.
Re: Scalability issues in the Internet routing system
Another thing, it would be interesting to hear of any work on breaking the router code into multiple threads. Being able to truly take advantage of multiple processors when receiving 2M updates would be the cats pajamas. Has anyone seen this? I suppose MBGP could be rather straightforward, as opposed to one big table, in a multi-processor implementation. You may want to read this thread from the beginning. The problem is not the routing plane or routing protocol but the forwarding plane or ASIC's or whatever. Both have very different scaling properties. The forwarding plane is at an disadvantage here because at the same time it faces growth in table size and less time to perform a lookup . With current CPU's you can handle a 2M prefix DFZ quite well without killing the budget. For the forwarding hardware this ain't the case unfortunatly. Hi Andre... I hear what you are saying but don't agree with the above statement. The problem is with the system as a whole and I believe that was the point Vladis, and others, were making as well. The forwarding plane is only one part of the puzzle. How do you get the updates into the forwarding plane? How do you get the updates into the router in the first place and how fast can you do that? I have seen at least one case where the issue did not appear to be the ASICs but getting the information into them rapidly. If you go and create a new ASIC without taking into account the manner in which you get the data into it you probably won't sell many routers grin. BTW, I do agree that spinning new ASICs is a non-trivial task and is certainly the task you want to get started quickly when building a new system. I did read your comment on BGP lending itself to SMP. Can you elaborate on where you might have seen this? It has been a pretty monolithic implementation for as long as I can remember. In fact, that was why I asked the question, to see if anyone had actually observed a functioning multi-processor implementation of the BGP process. Regards, Blaine
Re: Scalability issues in the Internet routing system
Blaine Christian wrote: Another thing, it would be interesting to hear of any work on breaking the router code into multiple threads. Being able to truly take advantage of multiple processors when receiving 2M updates would be the cats pajamas. Has anyone seen this? I suppose MBGP could be rather straightforward, as opposed to one big table, in a multi-processor implementation. You may want to read this thread from the beginning. The problem is not the routing plane or routing protocol but the forwarding plane or ASIC's or whatever. Both have very different scaling properties. The forwarding plane is at an disadvantage here because at the same time it faces growth in table size and less time to perform a lookup . With current CPU's you can handle a 2M prefix DFZ quite well without killing the budget. For the forwarding hardware this ain't the case unfortunatly. Hi Andre... I hear what you are saying but don't agree with the above statement. The problem is with the system as a whole and I believe that was the point Vladis, and others, were making as well. The forwarding plane is only one part of the puzzle. How do you get the updates into the forwarding plane? How do you get the updates into the router in the first place and how fast can you do that? I have seen at least one case where the issue did not appear to be the ASICs but getting the information into them rapidly. If you go and create a new ASIC without taking into account the manner in which you get the data into it you probably won't sell many routers grin. Sure, if you have a bottleneck at FIB insertion you fail much earlier. I'd say if that happens it's an engineering oversight or a design tradeoff. However I don't think this is the choke point in the entire routing table size equation. Depending on the type of prefix churn you don't have that many transactions reaching the FIB. Most far-away churn doesn't change the next hop for example. Local churn, when direct neighbors flap, mostly just changes the nexthop (egress interface). In a high performant ASIC/TCAM whatever FIB a nexthop change can be done quite trivially. Prefix drop can be handled by marking it invalid and garbage collecting it later. Prefix insertions may either salvage an invalidated prefix or have to be re-inserted. The insertion time depends on the algorithms of the FIB table implementation. For all practical purposes a FIB can be designed to be quite speedy in this regard without busting the budget. The link speed between two DFZ routers has seldomly been the limit for initial routing table exchanges. Neither has TCP. It is mostly dominated by the algorithm choice and CPU of the RIB processor on both ends. BTW, I do agree that spinning new ASICs is a non-trivial task and is certainly the task you want to get started quickly when building a new system. It is non-trivial for its prefix storage size and ultra-fast lookup times. Longest prefix match is probably the most difficult thing to scale properly as a search always must be done over a number of overlapping prefixes. To scale this much better and remove the bottleneck you may drop the 'overlapping' part or the 'longest-match' part and the world suddenly looks much brighter. This is the crucial thing that got forgotten during the IPng design phase which brought us IPv6. So far we have learned that limiting the number of IPv[46] prefixes in the DFZ is not an option for commercial and socio-technical reasons. That leaves only the other option of changing the routing lookup to something with better scaling properties. I did read your comment on BGP lending itself to SMP. Can you elaborate on where you might have seen this? It has been a pretty monolithic implementation for as long as I can remember. In fact, that was why I asked the question, to see if anyone had actually observed a functioning multi-processor implementation of the BGP process. I can make the SMP statement with some authority as I have done the internal design of the OpenBGPd RDE and my co-worker Claudio has implemented it. Given proper locking of the RIB a number of CPU's can crunch on it and handle neighbor communication indepently of each other. If you look at Oracle databases they manage to scale performance with factor 1.9-1.97 per CPU. There is no reason to believe we can't do this with the BGP 'database'. -- Andre
Re: Scalability issues in the Internet routing system
I did read your comment on BGP lending itself to SMP. Can you elaborate on where you might have seen this? It has been a pretty monolithic implementation for as long as I can remember. In fact, that was why I asked the question, to see if anyone had actually observed a functioning multi-processor implementation of the BGP process. I can make the SMP statement with some authority as I have done the internal design of the OpenBGPd RDE and my co-worker Claudio has implemented it. Given proper locking of the RIB a number of CPU's can crunch on it and handle neighbor communication indepently of each other. If you look at Oracle databases they manage to scale performance with factor 1.9-1.97 per CPU. There is no reason to believe we can't do this with the BGP 'database'. Neat! So you were thinking you would leave the actual route selection process monolithic and create separate processes per peer? I have seen folks doing something similar with separate MBGP routing instances. Had not heard of anyone attempting this for a global routing table with separate threads per neighbor (as opposed to per table). What do you do if you have one neighbor who wants to send you all 2M routes though? I am thinking of route reflectors specifically but also confederation EIBGP sessions. I think you hit the nail on the head regarding record locking. This is the thing that is going to bite you if anything will. I have heard none of the usual suspects speak up so I suspect that either this thread is now being ignored or no one has heard of an implementation like the one you just described.
New Rules On Internet Wiretapping Challenged
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://www.washingtonpost.com/wp-dyn/content/article/2005/10/25/AR2005102501807.html or By Arshad Mohammed Washington Post Staff Writer Wednesday, October 26, 2005; Page D01 New federal wiretapping rules that would make it easier for law enforcement to monitor e-mails and Internet-based phone calls were challenged by privacy, high-tech and telecommunications groups in federal court yesterday. The groups argued that the rules would force broadband Internet service providers, including universities and libraries, to pay for redesigning their networks to make them more accessible to court-ordered wiretaps. The groups also said the Federal Communications Commission rules, scheduled to take effect in May 2007, could erode civil liberties and stifle Internet innovation by imposing technological demands on developers. It's simply a very bad idea for privacy and for free speech for the government to design any technology, much less the Internet, to be surveillance-friendly, said Lee Tien, a senior staff lawyer with the Electronic Frontier Foundation, a nonprofit privacy rights group. The government was trying to build tentacles of control throughout telecommunications networks, Tien said. The FCC rules make broadband Internet providers and voice over Internet protocol companies subject to a 1994 federal law that requires telecom companies to assist law enforcement agencies in carrying out court-ordered wiretaps. The Communications Assistance for Law Enforcement Act requires telecom carriers to design their networks so they can quickly intercept communications and deliver them to the government when presented with a court order. In adopting the rules, the FCC said it wanted to ensure the government could carry out wiretaps as more communications move from the traditional telephone system to the Internet. It is clearly not in the public interest to allow terrorists and criminals to avoid lawful surveillance by law enforcement agencies, the commission wrote in its order. Opponents argued the law was tailored for a simpler, earlier era of traditional telephone service and could cripple the evolution of the Internet by forcing engineers to design products so they can be easily monitored by the government. The 1994 law will have a devastating impact on the whole model of technical innovation on the Internet, said John Morris, staff counsel for the Center for Democracy and Technology in Washington, which filed an appeal of the rules with the U.S. Court of Appeals for the District of Columbia Circuit yesterday. The Internet evolves through many tens of thousands, or hundreds of thousands, of innovators coming up with brand new ideas, he said. That is exactly what will be squelched. Morris said his group did not dispute the idea that the government should be able to carry out court-ordered wiretaps, but rather argued that the 1994 law was a blunt instrument ill-suited for the Internet age. He said the matter should be referred to Congress, which can tailor the obligations to the Internet context as opposed to importing the very clumsy [telephone system] obligations and imposing them on the Internet. The American Council on Education, a higher-education trade group, separately asked the court Monday to review the rules. We fear that doing what they want will require every router and every switch in an IT system to be replaced, said Terry W. Hartle, the council's senior vice president. He estimated that the upgrades could cost colleges and universities $6 billion to $7 billion. Our quarrel with them is fairly specific, Hartle said. We are concerned about the cost, and the complexity, and the schedule on which they want this accomplished. Spokesmen for the FCC and the Justice Department declined comment on the court challenges. - --- end --- ...Raising my hand. My question is on Terry Hartle's comments, maybe someone with more insight into this could help clear my confusion. Why would it require to replace every router and every switch when my understanding is, FCC is looking to install *additional* gateway(s) to monitor Internet-based phone calls and emails. I can see some sort of network redesign happening in order to accodomate this but replacing every router and every switch sounds too drastic, unless I mis-understood it. Please, I'm not advocating this change but just trying to understand the impact from an operation standpoint. Any insight will be appreciated. regards, /virendra -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDX/AApbZvCIJx1bcRAktgAKDzp+GaIDlpp5vdYT61jOWzEciClACfRkkW uQBPWQSzNpsw1M80tUQgWdI= =4t1U -END PGP SIGNATURE-
Re: Scalability issues in the Internet routing system
Alexei Roudnev wrote: Forwarding is in line cards not because of CPU issues, but because of BUS issues. i respectfully disagree. centralized forwarding only gets you so far on the performance scale. distributed forwarding is a (relatively) simple way to scale that performance. just take a look at any 'modern' router (as in, something this century) with a requirement of (say) 10M PPS. sure - there are reasons why one DOES have to go to a distributed model - 'bus limitations' as you say .. but i'd more classify those as phsycal chip-packaging limitations - how many pins you can put on a chip, how 'wide' the memory-bus needs to be as the PPS goes up. It means, that card can be software based easily. once again - disagree. it _may_ be that it means that forwarding can be in software - but for the most part the determining factor here is what is the PPS required for the function. i've previously posted a categorization of requirements in a router based on their function -- see http://www.merit.edu/mail.archives/nanog/2005-09/msg00635.html i think _software-based_ works for /some/ types of router functions - but nowhere near all - and certainly not a 'core' router this century. Anyway, as I said - it is only small, minor engineering question - how to forward having 2,000,000 routes. If internet will require such router - it will be crearted easily. Today we eed 160,000 routes - and it works (line cards,m software, etc - it DO WORK). if you're looking at routers based on their classification, clearly there isn't a requirement for all types of routers to have a full routing table. but for a 'core router' and 'transit/peering routers', the ability to work with a full routing-table view is probably a requirement - both now, and into the future. there have been public demonstrations of released routers supporting upwards of 1.5M IPv4+IPv6 prefixes and demonstrations on routing churn convergence time. http://www.lightreading.com/document.asp?doc_id=63606 contains one such public test. cheers, lincoln. - Original Message - From: Lincoln Dale [EMAIL PROTECTED] To: Alexei Roudnev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Daniel Senie [EMAIL PROTECTED] Sent: Wednesday, October 26, 2005 2:42 AM Subject: Re: Scalability issues in the Internet routing system Alexei Roudnev wrote: You do not need to forward 100% packets on line card rate; forwarding 95% packets on card rate and have other processing (with possible delays) thru central CPU can work good enough.. heh. in the words of Randy, i encourage my competitors to build a router this way. reality is that any big, fast router is forwarding in hardware - typically an ASIC or some form of programmable processor. the lines here are getting blurry again .. Moore's Law means that packet-forwarding can pretty much be back in software in something which almost resembles a general-purpose processor - or maybe more than a few of them working in parallel (ref: http://www-03.ibm.com/chips/news/2004/0609_cisco.html). if you've built something to be 'big' and 'fast' its likely that you're also forwarding in some kind of 'distributed' manner (as opposed to 'centralized'). as such - if you're building forwarding hardware capable of (say) 25M PPS and line-rate is 30M PPS, it generally isn't that much of a jump to build it for 30M PPS instead. i don't disagree that interfaces / backbones / networks are getting faster - but i don't think its yet a case of Moore's law becoming a problem - all that happens is one architects a system far more modular than before - e.g. ingress forwarding separate from egress forwarding. likewise, FIB table growth isn't yet a problem either - generally that just means put in more SRAM or put in more TCAM space. IPv6 may change the equations around .. but we'll see .. cheers, lincoln.
Re: New Rules On Internet Wiretapping Challenged
Vicky Rode wrote: ...Raising my hand. My question is on Terry Hartle's comments, maybe someone with more insight into this could help clear my confusion. Why would it require to replace every router and every switch when my understanding is, FCC is looking to install *additional* gateway(s) to monitor Internet-based phone calls and emails. In a datacenter you have lines coming in and lines going out. And you have internal equippment. You have to eavesdrop on all of this because the supposed terrorist might come in via ssh and use a local mail programme to send his email. So you have to eavesdrop on all incoming lines because you dont know where he comes in. Via aDSL? via cable modem? Via a glass fiber? And you have to monitor all internal switches because you dont know which host he might have hacked. Guess a cheap switch with 24 ports a 100 Mbit. That makes 2.4 Gig. You have to watch all of these. They can all send at the same time. Your switch might have 1 Gig uplink. But that uplink is already in use for your uplink and it does not even support 2.4 Gig. How about switches used in datacenters with 48 ports, 128 ports, ... Where do you get the capacity for multiple Gigs just for eavesdropping? On the other hand - most switches have a port for debugging. But this port can only listen on one port not on 24 or even 48 of them. So you have to invent a new generation of switches. How about the routers? They are even more complicated than a switch. As everybody should know by now - every router can be hacked. So your monitoring must be outside the router. The gouvernment will offer you an *additional* gateway. I wonder what that beast will look like. It must be able to take all input you get from a glass fiber. Or do they ask us to get down with our speed so they have time to eavesdrop. I can see some sort of network redesign happening in order to accodomate this but replacing every router and every switch sounds too drastic, unless I mis-understood it. Please, I'm not advocating this change but just trying to understand the impact from an operation standpoint. Yes, it is drastic. But if they want to eavesdrop that is the only way to do it. Any insight will be appreciated. regards, /virendra Here in germany we accidently have found out why east germany had to finally give up: They installed equippement to eavesdrop and tape on every single telefone line. They could not produce enough tapes to keep up with this :) Not to mention what happened when they recycled the tapes and did not have the time to first erase them :) Kind regards, Peter and Karin -- Peter and Karin Dambier Public-Root Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-179-108-3978 (O2 Genion) +49-6252-750308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr http://www.kokoom.com/iason
Re: Scalability issues in the Internet routing system
IPv6 will someday account for as many IPv4 networks as would exist
then, and IPv6 prefixes are twice as large as IPv4 (64 bits prefix vs
32 bits prefix+address, remainder 64 bits addresses on IPv6 are
strictly local), so despite a 3x cost increase (1 32 bit table for
IPv4, 2 for IPv6) on memory structures and 2x increase on lookup
engine(2 engines would be used for IPv6, one for IPv4), the same
techonology that can run IPv4 can do IPv6 at the same speed. As this
is not a usual demand today, even hardware routers limit the
forwarding table to the sum of IPv4 and IPv6 prefixes, and forward
IPv6 at half the rate of IPv4.
s/64/128/
...and total, complete, non-sense. please educate yourself more on reality
of inet6 unicast forwarding before speculating. Thank you.
From RFC 3513(Internet Protocol Version 6 (IPv6) Addressing Architecture):
For all unicast addresses, except those that start with binary value
000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format.
If Interface ID is 64 bits large, prefix would be 64 bits max,
wouldn't it ? Usually it will be somewhere between 32 bits and 64
bits.
As for 000 addresses:
Unassigned (see Note 1 below) 1/256
Unassigned 0001 1/256
Reserved for NSAP Allocation 001 1/128 [RFC1888]
Unassigned 011/64
Unassigned 1 1/32
Unassigned0001 1/16
1. The unspecified address, the loopback address, and the IPv6
Addresses with Embedded IPv4 Addresses are assigned out of the
binary prefix space.
Embedded IPv4 can be forwarded using IPv4 lookup, and all other 000
cases can be handled in slow-path as exceptions. IANA assignment
starts at 001 and shouldn't get to any of the 000 sections.
One interesting note though is Pekka Savola's RFC3627:
Even though having prefix length longer than /64 is forbidden by
[ADDRARCH] section 2.4 for non-000/3 unicast prefixes, using /127
prefix length has gained a lot of operational popularity;
Are you arguing in the popularity sense ? Is RFC 3513 that apart from
reality ? An October 2005(this month) article I
found(http://www.usipv6.com/6sense/2005/oct/05.htm) says Just as a
reminder, IPv6 uses a 128-bit address, and current IPv6 unicast
addressing uses the first 64 bits of this to actually describe the
location of a node, with the remaining 64 bits being used as an
endpoint identifier, not used for routing., same as RFC 3513.
Limiting prefix length to 64 bits is a good thing; it would be even
better to guarantee that prefixes are always 32 bits or longer, in
order to use exact match search on the first 32 bits of the address,
and longest prefix match only on the remaining 32 bits of the prefix
identifier.
Rubens
Re: Scalability issues in the Internet routing system
One interesting note though is Pekka Savola's RFC3627: Even though having prefix length longer than /64 is forbidden by [ADDRARCH] section 2.4 for non-000/3 unicast prefixes, using /127 prefix length has gained a lot of operational popularity; Are you arguing in the popularity sense ? Is RFC 3513 that apart from reality ? An October 2005(this month) article I found(http://www.usipv6.com/6sense/2005/oct/05.htm) says Just as a reminder, IPv6 uses a 128-bit address, and current IPv6 unicast addressing uses the first 64 bits of this to actually describe the location of a node, with the remaining 64 bits being used as an endpoint identifier, not used for routing., same as RFC 3513. I'd have to say that RFC 3513 is out of touch with reality here, yes. As far as I know current routers with hardware based forwarding look at the full 128 bits - certainly our Juniper routers do. Limiting prefix length to 64 bits is a good thing; it would be even better to guarantee that prefixes are always 32 bits or longer, in order to use exact match search on the first 32 bits of the address, and longest prefix match only on the remaining 32 bits of the prefix identifier. Longer prefixes than 64 bits are already in use today (as an example, we use /124 for point to point links). It would be rather hard for a router vendor to introduce a new family of routers which completely broke backwards compatibility here, just in order to be RFC 3513 compliant. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
