Re: can the memory technology save the routing table size scalability problem?
On Jan 8, 2008 9:25 PM, yangyang. wang <[EMAIL PROTECTED]> wrote: > As we known, the DFZ RIB size expand rapidly. It may be resolved via router > architecture improvement, such as adding memory chips or compressing RIB. or > via changing routing and addressing scheme, which one will be the long-term > essential approach? There are at least 2 problems to be addressed (given that you believe 'too many routes will crush the dfz routers')... both number of routes and speed/number of updates. So, adding more MEMORY (pick your type DRAM/SRAM/bah) is only solving one of the problems. Additionally, most moderm DFZ-placed platforms aren't necessarily 'RAM' limited, some of the limits exist in hardware forwarding elements (TCAM/CAM/ASIC systems). Anyway, Suresh's followup has a decent info as well, you might locate the RRG and RAM/RAWs working group meeting outputs as well: (report) http://tools.ietf.org/html/rfc4984 -Chris
Re: can the memory technology save the routing table size scalability problem?
You could try this recent nanog thread for some ideas Route table growth and hardware limits...talk to the filter http://www.merit.edu/mail.archives/nanog/msg02822.html srs On Jan 9, 2008 7:55 AM, yangyang. wang <[EMAIL PROTECTED]> wrote: > As we known, the DFZ RIB size expand rapidly. It may be resolved via router > architecture improvement, such as adding memory chips or compressing RIB. or > via changing routing and addressing scheme, which one will be the long-term > essential approach? -- Suresh Ramasubramanian ([EMAIL PROTECTED])
can the memory technology save the routing table size scalability problem?
As we known, the DFZ RIB size expand rapidly. It may be resolved via router architecture improvement, such as adding memory chips or compressing RIB. or via changing routing and addressing scheme, which one will be the long-term essential approach?
Re: Using x.x.x.0 and x.x.x.255 host addresses in supernets.
--- [EMAIL PROTECTED] wrote: "Wayne E. Bouchard" <[EMAIL PROTECTED]> writes: > So my oppinion is don't hesistate to use it until you find a real, > reproducible problem. Tell that to your call center manager. :-) -- I've been using them for several years and no problems. We assign about a /15s worth of DHCP in /23s and use the middle .255 and .0 with zero calls of trouble. The first and last .0 and .255 in the /23 aren't used due to DHCP software silliness. scott
Re: [admin] Using the NANOG list as a paging mechanism
On Jan 8, 2008 7:22 PM, Deepak Jain <[EMAIL PROTECTED]> wrote: > > > They're almost always short, and have Subject: lines that indicate > > what they're about, so it's easy to skip over them based on the > > Subject: line, and Gmail thinks I have 6.5GB of remaining quota space > > so it's not even worth the effort of deleting them. Sometimes > > they're even about issues like getting through the AOL email-rejection > > loop that are useful to multiple people. It's operational and de > > minimus. > > > Its operational and de minimus and sometimes the most simple way to > arrange something... e.g. a mail filter/blackhole and no obvious contact > phone number (e.g. the remote website is affected by the blackhole, etc). > > This is not a suggestion that NANOG should be carte-blanche a paging > service, but in the few cases it appears, it doesn't seem to be > clue-deprived requests that often. > Hi Deepak, Agreed, and both that are described contain content, or at least that's the way I'm reading your reply. We are specifically pointing out the paging messages that contain nothing but an empty request for "someone from xyz to contact $foo" for an unknown reason. I think it's fair for us to ask for some content if we're going to see these requests forwarded to ~9k users. Best Regards, Martin Hannigan NANOG MLC Member
Re: [admin] Using the NANOG list as a paging mechanism
They're almost always short, and have Subject: lines that indicate what they're about, so it's easy to skip over them based on the Subject: line, and Gmail thinks I have 6.5GB of remaining quota space so it's not even worth the effort of deleting them. Sometimes they're even about issues like getting through the AOL email-rejection loop that are useful to multiple people. It's operational and de minimus. Its operational and de minimus and sometimes the most simple way to arrange something... e.g. a mail filter/blackhole and no obvious contact phone number (e.g. the remote website is affected by the blackhole, etc). This is not a suggestion that NANOG should be carte-blanche a paging service, but in the few cases it appears, it doesn't seem to be clue-deprived requests that often. Deepak Jain AiNET
Re: [admin] Using the NANOG list as a paging mechanism
Normally these requests are looking for somebody who's operational and has a clue, and therefore aren't intended for me (:-), but IMHO they're_really_ not a problem. They're almost always short, and have Subject: lines that indicate what they're about, so it's easy to skip over them based on the Subject: line, and Gmail thinks I have 6.5GB of remaining quota space so it's not even worth the effort of deleting them. Sometimes they're even about issues like getting through the AOL email-rejection loop that are useful to multiple people. It's operational and de minimus.
Re: Using x.x.x.0 and x.x.x.255 host addresses in supernets.
I am astounded at seeing this discussion. I have not seen this much disavowing of CIDR addressing since 2003 or before. At least these arguments against .0 and .255 IPv4 addresses are based on perceived cost of operations, not ignorance of effective network number vs effective host number. Now, if we can get Microsoft to really support TCP/IP, we can make much progress. Of course, ubiquitous deployment of IPv6 will fix all that. Especially on proxied enterprise networks, use all the addresses available base on the effective network address having host number of 0 and the broadcast address being an effective host address of all ones. We have had much success with this approach for some large customer networks. Also, if your router OS works in a classful manner, tell the vendor to fix it. We got CIDR years and years ago. Note, the referenced Microsoft article uses the phrase, "the client may have difficulty communicating", not will. On Jan 8, 2008, at 4:12 PM, David Schwartz wrote: Historically, .0 and .255 have been avoided because a lot of servers (windows) wouldn't work using that as a host address or would flag it as invalid if you tried to connect to it or a myriad of other problems. Note that this was a limitation of the host, not anything to do with the network or any of the network equipment. This issue has not existed with any prevelance for quite some time and almost everything of recent manufacture is quite happy to be assigned in a supernet as well as on the .0 and .255 addresses. So my oppinion is don't hesistate to use it until you find a real, reproducible problem. -Wayne I have seen networks where traffic to these addresses was filtered in an attempt to mitigate broadcast address amplification. Typically, end users filter their inbound Internet traffic to their own addresses. They know they don't use .0 or .255 addresses and they found this is a quick way to prevent any nodes on their internal network from being used as amplifiers without having to audit/fix their entire internal network. As we know, the "workaround" may remain in their edge router(s) long after it has outlived its usefulness. A few years ago, I noticed that an ISP blocked all traffic from its customers bound for any .0 or .255 address to prevent drones from flooding those addresses. I doubt this is typical, but I bet it's still around in at least a few places. If you're seriously considering using these addresses, these are other possible issue you need to consider. DS James R. Cutler [EMAIL PROTECTED]
RE: Using x.x.x.0 and x.x.x.255 host addresses in supernets.
> Historically, .0 and .255 have been avoided because a lot of servers > (windows) wouldn't work using that as a host address or would flag it > as invalid if you tried to connect to it or a myriad of other > problems. Note that this was a limitation of the host, not anything to > do with the network or any of the network equipment. > > This issue has not existed with any prevelance for quite some time and > almost everything of recent manufacture is quite happy to be assigned > in a supernet as well as on the .0 and .255 addresses. > > So my oppinion is don't hesistate to use it until you find a real, > reproducible problem. > > -Wayne I have seen networks where traffic to these addresses was filtered in an attempt to mitigate broadcast address amplification. Typically, end users filter their inbound Internet traffic to their own addresses. They know they don't use .0 or .255 addresses and they found this is a quick way to prevent any nodes on their internal network from being used as amplifiers without having to audit/fix their entire internal network. As we know, the "workaround" may remain in their edge router(s) long after it has outlived its usefulness. A few years ago, I noticed that an ISP blocked all traffic from its customers bound for any .0 or .255 address to prevent drones from flooding those addresses. I doubt this is typical, but I bet it's still around in at least a few places. If you're seriously considering using these addresses, these are other possible issue you need to consider. DS
Re: Using x.x.x.0 and x.x.x.255 host addresses in supernets.
"Wayne E. Bouchard" <[EMAIL PROTECTED]> writes: > So my oppinion is don't hesistate to use it until you find a real, > reproducible problem. Tell that to your call center manager. :-) ---rob
Re: Using x.x.x.0 and x.x.x.255 host addresses in supernets.
Historically, .0 and .255 have been avoided because a lot of servers (windows) wouldn't work using that as a host address or would flag it as invalid if you tried to connect to it or a myriad of other problems. Note that this was a limitation of the host, not anything to do with the network or any of the network equipment. This issue has not existed with any prevelance for quite some time and almost everything of recent manufacture is quite happy to be assigned in a supernet as well as on the .0 and .255 addresses. So my oppinion is don't hesistate to use it until you find a real, reproducible problem. -Wayne On Tue, Jan 08, 2008 at 05:45:36AM -0800, Joshman at joshman dot com wrote: > Hello all, > As a general rule, is it best practice to assign x.x.x.0 and x.x.x.255 as > host addresses on /23 and larger? I realize that technically they are valid > addresses, but does anyone assign a node or server which is a member of a /22 > with a x.x.x.0 and x.x.x.255? Is it just a manner of preference on whether > or not to use them, or are there functional reasons you shouldn't; either > with rfc 1918 addresses or public addresses. > Thanks in advance, > J > > > - > Never miss a thing. Make Yahoo your homepage. --- Wayne Bouchard [EMAIL PROTECTED] Network Dude http://www.typo.org/~web/
Re: Using x.x.x.0 and x.x.x.255 host addresses in supernets.
> At Inter.Net, we specifically excluded .0 and .255 from our DSL pools > so as to not screw up the day of people running outdated Windows > software any more than it was already screwed up. According to Microsoft KB 281507 http://support.microsoft.com/default.aspx?scid=kb;en-us;281579 even "XP Home" and "Server 2003 Standard" are affected. Could anyone share some pointers to test results or any other listing of broken and correct IP stacks regarding this issue? Andras
Re: Using x.x.x.0 and x.x.x.255 host addresses in supernets.
Jon Lewis <[EMAIL PROTECTED]> writes: > On Tue, 8 Jan 2008, Joe Provo wrote: > >>> Until you assign a .255/32 to a router loopback interface and then find >>> that you can't get to it because some silly router between you and it >>> thinks '.255? that's a broadcast address.' >> >> See the qualifier "where you don't care that broken or archaic systems >> cannot reach them". If you have brokenness on your internal systems >> then yes, you'd be shooting yourself in the foot. > > Until you shoot yourself in the foot, how would you know you have such > brokenness on your internal systems? That silly router happened to be > a 7206 running (IIRC) 12.1T code. > > Unless you really don't care about the brokenness, or really want to > root it all out, I'd avoid using .0 and .255 IPs. At Inter.Net, we specifically excluded .0 and .255 from our DSL pools so as to not screw up the day of people running outdated Windows software any more than it was already screwed up. At some point you have to weigh the relative costs of 0.78% waste in IP address space vs. technician time to troubleshoot the lossage. With due respect to jzp, I'll err on the side of saving myself the bucks. ---Rob
Re: Using x.x.x.0 and x.x.x.255 host addresses in supernets.
On Tue, 8 Jan 2008, Joe Provo wrote: Until you assign a .255/32 to a router loopback interface and then find that you can't get to it because some silly router between you and it thinks '.255? that's a broadcast address.' See the qualifier "where you don't care that broken or archaic systems cannot reach them". If you have brokenness on your internal systems then yes, you'd be shooting yourself in the foot. Until you shoot yourself in the foot, how would you know you have such brokenness on your internal systems? That silly router happened to be a 7206 running (IIRC) 12.1T code. Unless you really don't care about the brokenness, or really want to root it all out, I'd avoid using .0 and .255 IPs. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Using x.x.x.0 and x.x.x.255 host addresses in supernets.
On Tue, Jan 08, 2008 at 09:50:13AM -0500, Jon Lewis wrote: > On Tue, 8 Jan 2008, Joe Provo wrote: > > >Yes. Efficient address utilization is a Good Thing. > > > >>I realize that technically they are valid addresses, but does anyone > >>assign a node or server which is a member of a /22 with a x.x.x.0 > >>and x.x.x.255? > > > >Great for router interfaces, loops, etc where you don't care that > >broken or archaic systems cannot reach them, and where the humans > >interacting with them should have no issues. > > Until you assign a .255/32 to a router loopback interface and then find > that you can't get to it because some silly router between you and it > thinks '.255? that's a broadcast address.' See the qualifier "where you don't care that broken or archaic systems cannot reach them". If you have brokenness on your internal systems then yes, you'd be shooting yourself in the foot. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: Using x.x.x.0 and x.x.x.255 host addresses in supernets.
On Tue, 8 Jan 2008, Joe Provo wrote: Yes. Efficient address utilization is a Good Thing. I realize that technically they are valid addresses, but does anyone assign a node or server which is a member of a /22 with a x.x.x.0 and x.x.x.255? Great for router interfaces, loops, etc where you don't care that broken or archaic systems cannot reach them, and where the humans interacting with them should have no issues. Until you assign a .255/32 to a router loopback interface and then find that you can't get to it because some silly router between you and it thinks '.255? that's a broadcast address.' Been there...had to change the loopback IP. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Using x.x.x.0 and x.x.x.255 host addresses in supernets.
On Tue, Jan 08, 2008 at 05:45:36AM -0800, Joshman at joshman dot com wrote: > Hello all, > As a general rule, is it best practice to assign x.x.x.0 and > x.x.x.255 as host addresses on /23 and larger? Yes. Efficient address utilization is a Good Thing. > I realize that technically they are valid addresses, but does anyone > assign a node or server which is a member of a /22 with a x.x.x.0 > and x.x.x.255? Great for router interfaces, loops, etc where you don't care that broken or archaic systems cannot reach them, and where the humans interacting with them should have no issues. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: Using x.x.x.0 and x.x.x.255 host addresses in supernets.
On Jan 8, 2008, at 8:45 AM, Joshman at joshman dot com wrote: As a general rule, is it best practice to assign x.x.x.0 and x.x.x. 255 as host addresses on /23 and larger? I realize that technically they are valid addresses, but does anyone assign a node or server which is a member of a /22 with a x.x.x.0 and x.x.x.255? Is it just a manner of preference on whether or not to use them, or are there functional reasons you shouldn't; either with rfc 1918 addresses or public addresses. I like to use them for critical service machines, since many versions of Windows will not send packets to them, so they are protected from most (but not all!) botnets. -- TTFN, patrick
Using x.x.x.0 and x.x.x.255 host addresses in supernets.
Hello all, As a general rule, is it best practice to assign x.x.x.0 and x.x.x.255 as host addresses on /23 and larger? I realize that technically they are valid addresses, but does anyone assign a node or server which is a member of a /22 with a x.x.x.0 and x.x.x.255? Is it just a manner of preference on whether or not to use them, or are there functional reasons you shouldn't; either with rfc 1918 addresses or public addresses. Thanks in advance, J - Never miss a thing. Make Yahoo your homepage.
RE: Assigning IPv6 /48's to CPE's?
I can give you a couple of pointers for DSL CPEs that support IPv6: http://www.billion.com/product/adsl/bipac7402r2.php http://www.cisco.com/en/US/products/ps6202/index.html The former is intended for residential users while the latter is intended for SOHO and teleworkers. The 870 cisco series supports IPv6 with the "Cisco IOS Software Features on Cisco 870 Series Routers-Advanced Security Feature Set". I'm not aware of prices though. I guess it depends on local dealers in each region. Regards Miguel > -Mensaje original- > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En > nombre de John Dupuy > Enviado el: lunes, 07 de enero de 2008 22:28 > Para: NANOG list > Asunto: Re: Assigning IPv6 /48's to CPE's? > > > It should probably be pointed out: > > Asking for practical advice on choosing /48 vs. /56 on a > residential broadband CPE is largely unanswerable. > > Why? > > Because I don't know of any residential broadband CPEs that > support IPv6. > > I want to be wrong about that. Seriously. Send me a link to > one. I want to be wrong. (And by residential, I mean a > CPE/router/firewall that costs less than $150US.) > > IMO, the only answers so far: > > businesses get /48 > dialup gets /64 > > (by default anyway; there are always exceptions) > > John > ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
