Calling TeliaSonera - time to implement prefix filtering
We're currently receiving the following prefix from TeliaSonera on one of our IP transit links in Oslo: 62.0.0.0/8 *[BGP/170] 4d 22:23:07, localpref 100 AS path: 1299 29049 I AS 29049 is: aut-num:AS29049 as-name:Delta-Telecom-AS descr: Delta Telecom LTD. descr: International Communication Operator descr: Azerbaijan Republic and *of course* they don't own 62.0.0.0/8. TeliaSonera: It's about time you started implementing prefix filtering on your customer links. Our other transit providers do this. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Calling TeliaSonera - time to implement prefix filtering
I think he was saying that Delta Telecom don't *own* 62.0.0.0/8 and therefore shouldn't be advertising it. Following that Telia shouldn't be accepting the route and then re-announcing it to peers ... Exactly. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Calling TeliaSonera - time to implement prefix filtering
I think he was saying that Delta Telecom don't *own* 62.0.0.0/8 and therefore shouldn't be advertising it. Following that Telia shouldn't be accepting the route and then re-announcing it to peers ... Of course! ... /8? ... Azerbaijan? ... What was I thinking?... Still, it would be better to contact the upstream directly and work back through the peering chain because this kind of thing is usually a result of education deficit, not malice. Probably in theory. In practice, it's not obvious. I *did* get a private response from a Telia person after my posting to Nanog, and this person alerted their routing registry. The 62.0.0.0/8 prefix is now gone - whether as as result of my posting to Nanog or not, I have no means of knowing. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Routing Loop
Does anyone know what i can do to expediate Above.Net to fix this issue quickly. There Noc they said they were checking now for more than 4 hrs I see it differently from here: From here (Oslo, Norway, Level3 as one of our transit providers) it works fine - I can even ping 194.9.82.137. traceroute to 194.9.82.137 (194.9.82.137), 64 hops max, 40 byte packets 1 nethelp-gw (195.1.209.46) 1.037 ms 1.136 ms 1.129 ms 2 ge-0-0-0-10.ar1.skoey.no.catchbone.net (81.0.130.190) 41.408 ms 99.281 ms 18.974 ms 3 ge-0-0-2.cr2.osls.no.catchbone.net (217.8.128.125) 14.076 ms 17.252 ms 16.724 ms 4 c10G-ge-6-1-0.br1.osls.no.catchbone.net (81.0.128.82) 16.408 ms 11.944 ms 17.357 ms 5 213.242.110.25 (213.242.110.25) 20.627 ms 24.517 ms 22.185 ms 6 ae-4-4.ebr2.Dusseldorf1.Level3.net (4.69.135.22) 57.604 ms 53.915 ms 53.915 ms 7 ae-2.ebr1.Amsterdam1.Level3.net (4.69.133.89) 49.335 ms 51.415 ms 54.128 ms 8 ae-1-100.ebr2.Amsterdam1.Level3.net (4.69.133.86) 50.000 ms 53.604 ms 54.647 ms 9 ae-2.ebr2.London1.Level3.net (4.69.132.133) 60.138 ms 57.248 ms 55.036 ms 10 ae-24-56.car3.London1.Level3.net (4.68.116.177) 55.117 ms ae-24-52.car3.London1.Level3.net (4.68.116.49) 60.006 ms ae-24-54.car3.London1.Level3.net (4.68.116.113) 62.998 ms 11 195.50.113.18 (195.50.113.18) 116.916 ms 118.000 ms 116.558 ms 12 217.194.157.226 (217.194.157.226) 630.275 ms 658.066 ms 631.207 ms 13 217.194.157.225 (217.194.157.225) 635.765 ms 654.525 ms 648.362 ms 14 fe2-0-br.nbo.infinet.co.ke (41.207.64.245) 622.878 ms 617.356 ms 643.694 ms 15 ge0-2-pdsn.nbo.infinet.co.ke (41.207.64.254) 623.575 ms 620.682 ms 755.128 ms 16 uu-194-009-082-137.uunet.co.ke (194.9.82.137) 703.257 ms 696.020 ms 709.526 ms % ping 194.9.82.137 PING 194.9.82.137 (194.9.82.137): 56 data bytes 64 bytes from 194.9.82.137: icmp_seq=0 ttl=107 time=683.480 ms 64 bytes from 194.9.82.137: icmp_seq=1 ttl=107 time=681.910 ms 64 bytes from 194.9.82.137: icmp_seq=2 ttl=107 time=684.992 ms 64 bytes from 194.9.82.137: icmp_seq=3 ttl=107 time=703.734 ms 64 bytes from 194.9.82.137: icmp_seq=4 ttl=107 time=676.809 ms Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: ISP's who where affected by the misconfiguration: start using IRR and checking your BGP updates
I've only dealt with a handful of the bigger networks, but every transit BGP session I've ever been the customer role on has been filtered by the provider. From memory and in no particular order, that's UUNet, Level3, Digex, Intermedia, Global Crossing, Genuity, Sprint, Above.net, Time Warner, CW, MCI, XO, Broadwing, and a few smaller ones nobody's likely to have heard of. There's at least one reasonably big transit provider that does *not* do prefix filtering: TeliaSonera (AS 1299). They *do* perform as-path filtering, but the effectiveness is disputable... As an ISP providing transit, all of our customers get prefix-filtered. Same here. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: YouTube IP Hijacking
Which means that, by advertising routes more specific than the ones they are poisoning, it may well be possible to restore universal connectivity to YouTube. Well, if you can get them in there Youtube tried that, to restore service to the rest of the world, and the announcements didn't propogate. Some of us block prefixes longer than /24 at our borders (even if our transit providers don't). Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Assigning IPv6 /48's to CPE's?
No, it gives them 16 bits for subnetting. Everybody gets 64 bits for addressing because everybody (except oddballs and enevelope pushers) uses a /64 subnet size. Since 64 bits are more than anyone could ever possibly need for addressing and 16 bits is more than an end site could ever possibly need for subnetting, the /48 is an ideal allocation size. As should be clear from the previous discussion, there are plenty of us who disagree here, and lean towards /56 for end users (typically residential customers) while business users would get a /48 or more based on need. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: v6 subnet size for DSL leased line customers
Personally, I'm not a big fan of DHCPv6. First of all, from a philosophical standpoint: I believe that stateless autoconfiguration is a better model in most cases (although it obviously doesn't support 100% of the DHCP functionality). But apart from that, some of the choices made along the way make DHCPv6 a lot harder to use than DHCP for IPv4. Not only do you lack a default gateway (which is actually a good thing for fate sharing reasons) but also a subnet prefix length and any extra on-link prefixes. So even if you do address configuration with DHCPv6 you need RAs for that other information. Which is probably going to make IPv6 deployment slower in service provider environments. There's also tons of ways to complicate your life by mixing stateless autoconf and DHCPv6, especially since most systems don't support DHCPv6 unless you install additional software. Last but not least, DHCPv6 has a stateful mode that's appropriate for address assignment or prefix delegation, and a stateless mode that's more efficient for the configuration of information that's not client-specific. Unfortunately, it's up to the client to initiate the desired mode. Then there are the M and O bits in RAs that tell you whether to do DHCPv6 but a number of DHCPv6 aficionados look like they want to ignore those bits. Again, this is something that's going to slow down deployment in service provider environments. Providers are comfortable with the IPv4 DHCP model (which is definitely not stateless) and many of us would like to keep this. What this all boils down to is that if you want to deploy DHCPv6 you need to install software on a lot of systems and modify a lot of configurations. If you're going to do all that, it's easier to simply configure this stuff manually. The only downside to that is that it's not compatible with easy renumbering, but then, you need to do more than just automate address assignment to support easy renumbering. Configure this stuff manually may work for a small number of customers. It is highly undesirable (and probably won't be considered at all) in an environment with, say, 1 million customers. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: v6 subnet size for DSL leased line customers
Configure this stuff manually may work for a small number of customers. It is highly undesirable (and probably won't be considered at all) in an environment with, say, 1 million customers. Of course not. But RAs on a subnet with a million customers doesn't work either, nor does DHCP on a subnet with a million customers. It wouldn't be a subnet with a million customers, of course. We would typically have aggregation routers handling 5000 to 3 customers, each connected via (in our case) point to point DSL links. Important point here is that we *don't* want per-customer IPv4 (or IPv6) config on the aggregation routers - this is what we have DHCP servers for. If we're talking about provisioning cable/DSL/FTTH users, that's a completely different thing. Here, DHCPv6 prefix delegation to a CPE which then provides configuration to hosts on its LAN side would be the most appropriate option. However, the specifics of that model need to be worked out as there are currently no ISPs and no CPEs that do that, as far as I know. I agree that DHCPv6 prefix delegation (for instance a /56) to a CPE which provides configuration to hosts on its LAN side sounds like a reasonable model. It requires the customer to have a CPE with actual *router* functionality, as opposed to just a bridge. This is different from today's requirements, but may not be unreasonable. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: v6 subnet size for DSL leased line customers
In places where you need tighter control over the usage of various gateways on a common L2 segment, VRRP probably makes more sense. However, as things currently stand, that means static routing configuration on the host since for reasons passing understanding, DHCP6 specifically won't do gateway assignment. For those of us with lots of IPv4 customers dependent on DHCP, it would be good to know more detail about this point. What is the problem, and are there plans to do anything about it in DHCPv6? Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Juniper M10i sufficient for BGP, or go with M20?
M7i is a very, very attractive lab/spare box, but this company wants carrier class - dual engine M10i are the minimum. An M10i will handle a full routing table just fine. Note that as with other hardware based forwarding boxes memory on the RE is just one of several resources you need to verify. These days I would probably recommend the RE-850, which runs just fine in both M7i and M10i, and comes standard with 1.5 GByte memory. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Juniper M10i sufficient for BGP, or go with M20?
I don't know much about Juniper but I'm about to learn with a new job. If I'm going to take full routes from a couple of upstreams and have a couple of peers will the M10i (768M max) be enough or is the M20 (2048M max) a better choice. Layout here is such that I'd expect to use a single quad gigabit port ethernet blade in each of a pair of M10i/M20 to achieve redundancy. As mentioned in another email, the M10i can use the RE-850 which has 1.5 GByte on the RE. As for the GigE cards: Note that the 4 port GigE PIC for M10i/M7i (PE-4GE-TYPE1-SFP-IQ2) has 1 GigE (full duplex) backplane capacity, thus you will *not* be able to run all 4 ports line rate at the same time. I haven't checked whether the same restriction also applies to the corresponding M20 card. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: How big a network is routed these days?
my organization is considering PI addresses as a way to multihost. Having read the archives regarding disadvantages and alternatives, my question is how big a network must one have to be reasonably sure the BGP routers will accept the route? /24 Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: AS41961 not seen in many networks
now pingable addresses are: 194.60.78.254 194.60.204.254 194.153.114.254 They should be accessible via LambdaNET. Routes inside LambdaNET can be diffrent to each address. Everything looks fine from here (AS 2116), prefixes reachable and addresses pingable. Example traceroute below. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] traceroute to 194.60.78.254 (194.60.78.254), 64 hops max, 60 byte packets 1 nethelp-gw (195.1.209.46) 1.190 ms 1.139 ms 1.144 ms 2 gi1-0-634.ar4.o-d.no.catchbone.net (81.0.129.174) 5.982 ms 6.819 ms 6.617 ms 3 ge-0-2-3-15.cr1.osls.no.catchbone.net (193.75.3.165) 6.138 ms 5.709 ms 6.145 ms 4 c10G-ge-3-0-0.cr2.osls.no.catchbone.net (81.0.128.54) 5.824 ms 6.041 ms 5.841 ms 5 c2488-so-1-3-0.cr1.mejv.se.catchbone.net (193.75.3.239) 13.195 ms 13.066 ms 13.011 ms 6 ge-0-1-0.br1.stcy.se.catchbone.net (81.0.128.210) 13.321 ms 13.379 ms 19.719 ms 7 netnod-ge-a.sto-1-eth020-15.se.lambdanet.net (194.68.123.141) 13.021 ms 13.050 ms 13.328 ms 8 HAN-7-pos720-0.de.lambdanet.net (81.209.190.17) 34.421 ms 36.609 ms 34.856 ms 9 DUS-1-pos012.de.lambdanet.net (217.71.105.126) 39.065 ms 38.768 ms 38.776 ms 10 217.71.96.66 (217.71.96.66) 41.873 ms 41.597 ms 41.889 ms 11 FRA-2-pos600.de.lambdanet.net (217.71.96.102) 42.342 ms 42.251 ms 42.032 ms 12 194.60.78.254 (194.60.78.254) 42.655 ms 42.673 ms 42.662 ms
Re: AS41961 not seen in many networks
And aren't seen through gblx. I also think I can't see those prefixes through verizon. Also not seen via Telia (1299) or Level3 (3356). Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: ISP compliance LEAs - tech and logistics
The guy wants to say, please raise your eyes above the horizon of your plate and view a not yet existing country named europe. Here our infrastructure is a lot more advanced and we have standardized a common eavesdropping api. We have? News to me. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: ISP compliance LEAs - tech and logistics
The guy wants to say, please raise your eyes above the horizon of your plate and view a not yet existing country named europe. Here our infrastructure is a lot more advanced and we have standardized a common eavesdropping api. We have? News to me. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] Institut européen des normes de télécommunication http://portal.etsi.org/docbox/Workshop/GSC/GSC10_RT_Joint_Session/00index.txt I see a list of documents. I see no sign that these documents are standards, nor that they are actually *implemented*. I know for a fact that the service provider I work for has not implemented this on the IP side. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: private ip addresses from ISP
Filtering every last 1918 sourced packet you receive because it might have a DoS is like filtering all ICMP because people can ping flood. If you want to rate limit it, that is reasonable. If you want to restrict it to ICMP responses only, that is also reasonable. If on the other hand you are determined to filter every 1918 sourced packets between AS boundries (including ttl exceed, mtu exceed, and dest unreachable) because an RFC told you you should, you are actually doing your customers a disservice. Well, some of us happen to disagree. I have been very happy to see that both at my previous and at my present employer (large SPs by Norwegian standards), all 1918 traffic is filtered at the borders. We have never had any trouble from customers because of this, and we certainly intend to keep the filters. And yes, we have had these filters in place for several years... Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: GigabitEthernet over 2 x STM-1
I am looking for a device which can transport GigabitEthernet over 2 STM-1 (OC3) SDH connections. Like AXXConnect from AXXessit (a part of the Ericsson Group) can do it. http://www.axxessit.no/nav_web/Solutions/Products/MSPP/AXXCONNECT/axxconnect.htm Does anybody have any other suggestions or any experiences with this type of transport or products from AXXsessit ? We use AxxEdge from the same company to transport GigE over SDH (actually to transport GigE over 7xSTM-1, connecting to STM-16 DWDM). Works for us. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Peering VLANs and MAC addresses
A lot of people are deploying C76xx as peering routers ... rant ... which should be prohibited by law. Actually, C76xx should be prohibited by law. /rant I've done my share of Cisco bashing in the past - but I have to say that 6500/7600 worked pretty well as peering routers at my previous employer. Great capacity, hardware forwarding, hardware ACLs and policing. Handled Gbps sized DDoS attacks just fine. 6500/7600 as MPLS PE routers is another story altogether... Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Scalability issues in the Internet routing system
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. Ours do as well, but essentially, that's because they are internal to our network. Nobody would need that in the shared DFZ part, there I agree with Rubens. I agree about that part too. So although you would need the longer prefixes (right up to /128) in your routing core, you would not necessarily have to have them in your edge routers (as long as they don't directly connect to your core, like Cisco keeps telling us we should do). That's just it - even if you don't need to exchange longer than /64 prefixes with other providers, your routers still need to handle the longer prefixes in hardware (assuming you're using boxes with hardware based forwarding). Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
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]
Re: image stream routers
A collegue smartbits tested a 1GHz pc, with a full feed and 250k simoultaneons flows it managed around 250kpps. This also with freebsd and device polling. It sounds to me like a software based machine can be plenty fast with good code under the hood. Sorry, in today's world of high-end routers 250kpps doesn't qualify as plenty fast. Can your box do linerate Gigabit Ethernet with minimum size packets, on several ports simultaneously? Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: image stream routers
Sorry, in today's world of high-end routers 250kpps doesn't qualify as plenty fast. Can your box do linerate Gigabit Ethernet with minimum size packets, on several ports simultaneously? I didn't say that a 250kpps box was a high-end box. One reliable Mpps is not high-end either, but it can carry quite a lot of Mbps. What is C or M price for a reliable full feed Mpps ? My high-end boxes never manage to impress me with their pps capability before I'm disapointed in their reliability. I usually find that it works better to use routers to forward packets between interfaces, and Unix servers (in my case mostly FreeBSD, but that's beside the point) to run applications. Occasionally I configure a Unix box to actually forward packets. I found Lincoln Dale's characterization the other day of the roles of various routers, http://www.merit.edu/mail.archives/nanog/msg11681.html to be useful. From his list I could imagine using Unix boxes for 3, 4 and 5 - but probably not 1 or 2. Also note that high-end broadband aggregation may have high enough pps that a box with software based forwarding doesn't cut it. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: zotob - blocking tcp/445
If ISPs really wanted to make the Internet better for Corporate America, I guess they'd unplug most of Asia...not block a port here and there (but that isn't exactly acceptable). If I (working for an ISP in Norway) wanted to make the Internet better for my customers, I'd unplug lots of U.S. sites - because that's where most of the spam (and the products the spam advertises) comes from. The problem is in the eye of the beholder. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: FCC Issues Rule Allowing FBI to Dictate Wiretap-Friendly Design for In ternet Services
but every feature has its cost in complexity and resources to build and maintain. resources are finite and complexity has super-linear cost. so i would much prefer that the vendors concentrate on the features *i* want g. and i am quite skeptical of features which non-paying non-customers want. 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. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Boing Boing: Michael Lynn's controversial Cisco security presentation
I guess at this point ISS realizes their reputation is so deep in the shitter that nothing they do could make it worse. Give it a week. :) (It's obvious that the people calling the shots in this circus have either never heard of Skylarov, deCSS, or @Stake/Dan Geer, or have decided to out-do those. In either case, I'm willing to bet a large pizza with everything on it that Monday morning will bring a whole new set of PR miscues into play.. ;) It'll be interesting to see them trying to suppress all the downloads that have been made by people outside the U.S. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?]
Here's a simple mechanism which has not yet been tried seriously. Email server peering. This means that an SMTP server operator only accepts incoming mail from operators with whom they have a bilateral email peering agreement. This has been tried in the X.400 world. I wouldn't exactly say it worked well - and I, for one, have no desire to return to X.400 style email peering. Bilateral agreements have been shown to scale quite well whether you look at BGP peering or the world of business contracts. In any case, the fundamental need here is that for somebody to notify the email administrator that is sending spam and for that administrator to act immediately to cut the flow. The number of agreements needed in the email world is significantly higher than what is needed for BGP. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: BCP regarding TOS transparancy for internet traffic
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? Seems to me these are far more complex solutions than simply rewriting TOS at the borders. And yes, we also rewrite TOS at the borders for Internet traffic. We definitely intend to continue doing this. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Slashdot: Providers Ignoring DNS TTL?
First of all, let's ditch the term PPLB. The usual alternative to per packet load balancing (what's been being talked about here) is per prefix load balancing, which would also be PPLB. The abbreviation is therefore more confusing than anything else. Err. No, that would be worse. Per prefix load balancing is an artifact of the Cisco route cache. The route engine (ie the route table) isn't queried for every packet. Instead the route in the route cache is used. One doesn't configure per prefix load balancing. One configures load balancing, which adds multiple routes into the route table. Modern Cisco routers do not use a route cache, they use a fully populated forwarding table. And load balancing is automatic if you have several equal cost routes. The route cache then causes only one of these routes to be used. On cisco, to enable PPLB, you turn off the route cache. Many modern Cisco routers can perform per-packet load balancing without doing process switching (but this needs to be explicitly configured). On Juniper, you configure it to put multiple routes in the route table. Its actaully more likely to happen on Junipers, because unless you configure additonal policies, you get load balancing on divergent links as well as non-divergent links. On Modern Juniper routers cannot do per-packet load balancing *at all*. It is correct that the configuration statement says per-packet, however it is really per-flow (and this is well documented). See for instance the description of Internet Processor II ASIC load balancing at http://www.juniper.net/techpubs/software/junos/junos70/swconfig70-policy/html/policy-actions-config11.html#1020787 I'm afraid your statements show a certain lack of knowledge about modern router architectures. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Slashdot: Providers Ignoring DNS TTL?
Well, PPLB isn't the end of the world. But PPLB is coming, and the smart people will be prepared for it. They dumb people, well, they're dumb. What can be expected from dumb people? What you seem to be missing is that the *really* smart people will be prepared for it when it actually gets here - and will take advantage of it's lack of arrival in the meantime. I agree with another poster in this thread - I think we will see *less* PPLB in the future, not more. Mostly because other, better methods of bundling several parallel links are more easily available now than they were a few years ago. Example: At my previous employer we sometimes used PPLB on 2 or 4 2 Mbps links to give the customer 4 or 8 Mbps available *for one session*. We could have used multilink PPP - but that required more expensive routers. These parallel links always ran from one PE router to one CPE router. At my current employer we would either use DSL equipment (which bundles the necessary links at a level below and invisble to IP), or Ethernet over SDH (using GFP etc). In both cases the bundling of several parallel links is invisible to IP, and there is no issue of packet reordering. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Slashdot: Providers Ignoring DNS TTL?
In your note below you speak of 'moving on to something else' when PPLB comes. PPLB destabilizes TCP. It elicits erroneous retransmissions, squanders capacity and lowers performance. I would actually dispute this. I agree that PPLB will *occasionally* lead to out-of-order packets, which will lead to lower TCP performance *when it happens*. To many customers this is acceptable as long as PPLB gives them improved performance *most of the time*. And this is what we saw very clearly at my previous employer - PPLB worked very well, and gave clearly increased performance, *most of the time*. As mentioned in another message, I don't really believe PPLB is coming. Instead I believe PPLB is something which is probably being *less* used now than a few years ago, since other link bundling methods are more easily available now (than they were a few years ago) - and these link bundling methods occur at a layer below TCP, and are invisible to TCP (no packet reordering problems). Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Slashdot: Providers Ignoring DNS TTL?
I'd rather expect this sort of behavior with anycasted servers... Where do you see any connection between anycast and ignoring DNS TTL? Or is this just part of your usual rant against anycast DNS service? We use anycast for our caching (recursive) DNS servers. It works well for us, and we certainly intend to continue to use it. The actual DNS software used is Nominum CNS and BIND 9.3.1, both of which honor the DNS TTL. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Slashdot: Providers Ignoring DNS TTL?
But caching servers are usually setup to load balance. Usually, the servers with the same IP address share an ethernet along with multiple routers. So the packets are switched on essentially a per-packet basis. Or possibly a per-arp basis that alters the MAC-based-forwarding behavior of a switch. This is fairly fine grained load balancing. This is complete news to me. Of course, I do not run most of the caching name servers on the Internet, so what do I know. Do you? Would anyone who runs an anycast recursive name server care to supply data points to support or refute Mr. Anderson's assertion? Our recursive name service, using anycast servers, is setup with 3 name servers at 3 different physical locations, with each server connected to a router at the same physical location. Each server handles two different anycast addresses. There is no per-packet load balancing involved. I can't speak for the rest of the net, of course - but our recursive anycast service has worked well for several years. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Slashdot: Providers Ignoring DNS TTL?
While that setup may have worked well, it's not an anycast implementation I would suggest that others follow. Having the same set of servers announcing multiple IP addresses (assuming those addresses are both in the same set of addresses given out to those doing dns lookups) leaves you open to a failure mode where a single server stops responding to queries but doesn't withdraw its routing announcement. If a user sees that server as the closest instance of both DNS server IP addresses, they will see that as a failure of both of their DNS servers. Agreed, that's a possibility. In practice it hasn't really turned out to be a problem for us. A more reliable way of doing this is to have multiple anycast clouds with their own servers, each serving a single service address. That way, an incomplete failure (on query response but no route withdrawl) of a local server for one service address won't have any effect on access to the second service address. Yes, we have been doing some of this also. Part of the problem is the desire to spread the load among the servers: Some of this comes naturally from the different server locations in our network - but with 2 addresses per server we can also balance the load somewhat by announcing either one or two addresses per server. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: djbdns: An alternative to BIND
I had a play with DJBDNS after using BIND for years. Here's why I switched back: - No AXFR support It supports this. No IXFR, no automatic notification of bind slaves (you get to run a separate notify script) ... But yes, it is far easier to use, consumes very low amounts of memory and makes an excellent local resolver cache eoe no roundrobin DNS without a patch (as in it returns all the A records in the same order every time, whereas bind does this in a different order ...) A contrary view from the trenches: Around a year ago we tested DJB dnscache as the recursive DNS server in a high-volume ISP environment - mostly because we were not happy with BIND 9 performance at the time. Our conclusions were: - dnscache used *more* CPU than BIND 9 in our environment, effectively ruling it out - Not possible to get dnscache to listen to more than one IP address unless you introduce hacks/patches - Weird failures reported from users - Annoying installation process with lots of small programs that we don't want or need We then used BIND 8 for a while, due to its better performance than BIND 9. Earlier this year we finally found a BIND 9 configuration and version that worked well for us (but still too low performance). We finally switched to Nominum CNS (two servers) and one BIND 9 server as backup. We really like Nominum CNS, and we're happy. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: djbdns: An alternative to BIND
You need only count the lines of code needed by the daemon/s servicing requests. That is, IMO, bind's only major failing. Too much code, too many little used features (nobody I know needs or wants rndc), and no way to compile without them. If you read Bruce Schneier, as every developer should, you know how important that Amount of code is. Ah, but how do you know what are the little used features? We use rndc a lot, just as we used ndc with BIND 8. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: RIP in Operation
We use RIP extensively on the edges of our network to build a Layer3 routed overlay between 3550/3750 switches and our 6500-based core. At $2k/list for the EMI license PER SWITCH ($4k for 3750s), it just wasn't feasible for us to use EMI just for OSPF when all we were really announcing was a loopback and a /30 connected network. We route filter and tune the RIP times down quite a bit. Meets our needs on the edges. I assume you mean RIPv2, ie. classless. With that caveat, I can certainly see why RIP would be used. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Summary with further Question: Domain Name System protection
1. ISPs use firewall to protect their DNS server; Depends. You don't normally need a full fledged (stateful) firewall. Normal (stateless) router access lists are just fine. 2. ACL on router may be a good solution for protecting DNS servers, the policy could be only pass those packets, whose originate from incustomers' IP address blocks and destinate to UDP port 53 of DNS server; In general, allow only relevant traffic. That may be a bit more than just UDP port 53: You really want to allow TCP based DNS queries also, and your name server probably needs SSH, NTP and similar. 5. 'bogon'in BIND configuration could be used to filter requests from RFC1918 address; Better to do it on the router. 6. Firewall may become bottleneck of DNS server farm in situation of DoS attack or situation of high session rate; Routers with hardware based access lists. No problem. b) Is there any public available performance evaluation on Nominum's product? See Brad Knowles' tests: http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-dns-dnscomp.pdf We currently have the Nominum CNS on trial here, and we are very impressed. It performs much better than BIND 8/9 - our measurements show even greater differences than Brad Knowles' tests. Example: One server running BIND 9 shows more than 30% CPU usage during peak hours, but only 2-3% with Nominum CNS. We also have the issue that BIND 9 seems to start *failing* when it reaches a certain cache size (as in: Some queries are either not answered at all, or they are answered with SERVFAIL). Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Summary with further Question: Domain Name System protection
What I'm not sure about ACL on router is, how to survive DNS server under DoS/DDos attack. We suffered from DoS attack last year, and we found the source IPs of that attack locate in our customers IP address blocks. ACL on router could only filter those traffic not meaningful to DNS server, but how about those DDoS attacking packets? Your router can presumably rate limit the traffic towards the name server to a level the name server can handle. On the name server you can perform further rate limiting on an IP address basis, with for instance FreeBSD ipfw. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Summary with further Question: Domain Name System protection
this should be pushed to the router. don't waste CPU cycles on the Nameserver. Hosts tend to be a faster writeoff cycle than routers in companies I've worked at, therefore getting the benefit of moores law about 25% faster than the routers. Turn on firewalling in the host. If you have a choice between access lists on a software forwarding based router and firewall on a host, this may be a good choice. If your routers have hardware forwarding, I'd go for the router every time... Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: 2511 line break
on a 2511, which i am using as a serial console server for a bunch of boxes, how do i send a break on one of the lines? If you telnet into 2511 port 2000+line#, you can escape to command mode of your telnet client and tell the client to send break. Works here. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
RE: Regional differences in P2P
I don't know of any capped service over here, nobody dares take the first step. Not 10 Mbps but: Telenor, the largest Norwegian service provider, capped their ADSL customers at a ridiculously low 1 Gbyte/month for a while. Presumably they lost sufficient business to other (uncapped) providers that they noticed - the cap has now been removed. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
RE: Regional differences in P2P
Not 10 Mbps but: Telenor, the largest Norwegian service provider, capped their ADSL customers at a ridiculously low 1 Gbyte/month for a while. Presumably they lost sufficient business to other (uncapped) providers that they noticed - the cap has now been removed. What did they do when customer went over the limit? Reduced the speed to 64 kbps (made possible with Juniper ERX and its provisioning system). Thus the customer would not be blocked, but it would be quite noticeable that the cap had been reached. During the period when the 1 Gbyte cap was in effect, the customers could increase the cap - for a fee (I don't remember how much). Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Spyware becomes increasingly malicious
Ok.. but has BSD been attacked on the scale that MS code has? I would argue no, not even close. Do you believe BSD is invulnerable to attack? Hardly.. I don't believe anybody is claiming that. However, the BSD code has been out *and* has been publicly scrutinized for quite a bit longer than Windows. Unless you want to go back to text based browsers and kernals that fit on a floppy, it is extermely difficult to eliminate all vulnerabilities in the code of a sophisticated OS. The more complex the system, the easier it is to break, and with the level of automation currently expected by most users, this requires a very complex build. However, Microsoft creates complexity by design, because they integrate more and more stuff into the basic OS, and because all the various applications gain more features with each new release. Could MS be made more secure, of course. Do I think they are actively working on the problem, yes. Looks to me like they are actively working in two directions: - Trying to make the systems more secure by teaching developers to think about security, etc. - Trying to make the systems less secure, by making them steadily more complex. (And please don't try to tell me the *users* are demanding all the new features that MS put into the systems.) It will be interesting to see which direction wins out in the long run. If Novell or Mac had risen to the top of the OS heap, would they be catching all the viruses now? I think they would. They would certainly be catching viruses. Would they be catching *as many* viruses as MS? We don't know. Really, my point was not to argue this, but that there is no justification for malicious code, that you can't simply pawn it off on MS as being the real problem. However, you can certainly argue that MS is *part of* the problem, or that they have *created* a large part of the problem themselves. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Sipura VoIP phone adapters and DoS against name servers
Get in contact with manufacturing vender for a fix, and then tell us what they did or what they intend to do to remedy the problem. We have already suggested this to the local VoIP provider. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Sipura VoIP phone adapters and DoS against name servers
I guess the real question is why was the local VoIP provider giving the phones your DNS IP? Should they have been using their own DNS server? As to why, we don't know. They *will* be using their own DNS servers soon, however :-) Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: The use of .0/.255 addresses.
This is what happens when your educational system continues to teach classful routing as anything other than a HISTORICAL FOOTNOTE *coughCiscocough*. Yes, it sure would be nice if Cisco would revise some of their CCNA course material and exams. Plenty of classful stuff still left there, I'm afraid. It's kind of stupid when you have to tell fellow workers trying to get a certification This isn't real life, you just have to learn it for the exam. In real life we use CIDR. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: OT: Looking for Ethernt/Optical Device
I'm wondering if anyone has seen a good and cheap(er) solution for providing multiple Gigabit Ethernet circuits over single pair of fiber. I'm looking for a way to do CWDM or DWDM that's cheaper than putting in a Cisco 15454 or 15327. I'm only going to be doing 2 GigE circuits between two switches, so I don't need to plan for future growth. If you only need two GigE circuits, the least expensive solution is probably standard LX/LH GBICs and passive splitter/combiners. Available from several vendors, for instance http://www.mrv.com/product/MRV-FD-SPLTCMB/ Disclaimer: I have no practical experience with this product. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: ntp config tech note
you ask do folk run ntpd on every server. And the answer is, yes, on all Unix servers. Have done so for many years. Running ntpdate from cron was always regarded as a poor substitute. i wonder if folk run ntpd on every router. i did and do. Yup. Or sntp if that's the only thing available. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: WAN transfer rates
I realize that transfer rates across the Internet diminish significantly with latency, but what's the good answer for someone shrunk down to 10Mbps when the smallest pipe between them is 100Mbps and latency is 40ms? Without window scaling (RFC 1323) your max transfer rate at 40ms RTT is 65535*8/0.040 = 13.1 Mbps. So slightly less than 10 Mbps isn't too unexpected. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
RE: Cisco Router best for full BGP on a sub 5K bidget 7500 7200orother vendor ?
I was surprised by the similarities between the 7507 and 7513. Why EOL the one device that has a pleasing form factor ? There are MANY providers who would be quite happy with ~ 600 mbps? That's a lot of billings... It's the 7505 that's EOLed. Possibly because it doesn't sell well enough, I don't know. For an ISP environment it has a significant problem in not supporting redundant powersupplies. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Juniper failes to change keys (More MD5 fun: Cisco uses wrongMD5key for old session after key change)
We've experienced this as well, between old versions of IOS without the new feature Sean describes, and newer versions with the new feature. Between two versions of IOS, we were successful at making this change if we changed both MD5 passwords at the same time: So if you do this: a) Configure password in Router A b) Wait till the first keepalive c) Configure password in Router B (at this time getting error message) d) After two keepalives (total three keepalive) the bgp goes down and comes up automatically e) The error messages still seen for 5 minutes However, if you skip steps b and c, and immediately configure the far end with the new password, there are no flaps, and should be no logs. Please let me know if this works for you. It certainly doesn't work between Cisco and Juniper, because the Juniper always resets the session when you configure a new MD5 key. After some more lab testing I have concluded that the key (pardon the pun) to make this work between Cisco and Juniper, and not get a lot of log messages about invalid keys, is to get an orderly termination of the old BGP session. I found two ways to make sure that happens: 1. Configure (and commit) the new key on the Juniper side first. This leads to an orderly termination of the existing BGP session, and then the new key can also be configured on the Cisco side. 2. Do an explicit reset of the BGP session on the Cisco side (which again gives you an orderly termination of the existing BGP session), and then configure the new key on both routers (here it doesn't matter which router gets the new key first). It would Really Nice (tm) if this was documented in the manuals. But to reiterate the original point - if a new key is configured on the Cisco side first, without resetting the existing BGP session, Cisco and Juniper will disagree about the key used to terminate the existing BGP session, with lots of confusing log messages as a result. Now that i understand what's happening, I agree that it would be good for Juniper to implement key change without BGP session reset too - but until that happens, the current situation is rather confusing (how is the user supposed to guess that the invalid key messages refer to the old BGP session?). Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Cisco Router best for full BGP on a sub 5K bidget 7500 7200 orother vendor ?
I bought a Riverstone Rs-3000 for BGP with a single upstream provider. Great Deal. Yeah, it might be a Great Deal (tm), but you're in for some surprises. I've seen an RS-8600 (with CM3 and 512MB on board) nearly melt under 13Mbps of Nachi, to the point that I had to set the CM failover keepalive timer to 30 seconds. This should come as no surprise - the Riverstone boxes are flow-based. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
RE: Cisco Router best for full BGP on a sub 5K bidget 7500 7200 orother vendor ?
Yes. I've been looking at it and a 7505 with a 3550 behind it seems the way to go for our type of operation. As a cost cutting alternative - has anyone played with the 2900 XL series using sub interfaces to turn them into virtual router ports ? or vlan groups ? Is it better to just buy a 3550 ? If you're only doing basic Ethernet-Ethernet routing, and don't need a full routing table, it's quite possible that the 3550 will perform better than either the 6000/Sup1A or the 7505. You might also consider a 3750, which handles a large number of SVIs better than the 3550. (Yes, I'm seriously suggesting using the 3550 or 3750 alone.) Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
RE: Cisco Router best for full BGP on a sub 5K bidget 7500 7200orother vendor ?
It is a great box. But I need BGP. I notice Cisco does not support 7505 with Software Advisor but does 7507 whats the deal with that ? There are no differences between the 7505 and the 7507 when it comes to BGP. As for the 3550, it'll do BGP just fine - but it can't handle a full routing table. Same with the 3750. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
More MD5 fun: Cisco uses wrong MD5 key for old session after key change
The other day I was trying to configure MD5 authentication on a BGP peering with MCI. Juniper at our end, Cisco at their end. We couldn't get the session up the way we wanted - or rather, we got the session up, and everything *seemed* to work fine, but the Cisco router was logging lots of Invalid MD5 digest - this did not seem to stop. Today I saw the same thing on a session where I controlled both ends, and was later able to reproduce it in the lab. The routers are: Cisco 7206, IOS 12.0(23)S6, IP 7.0.0.9 Juniper M7i, JunOS 6.2R2.4, IP 7.0.0.18 The session was sniffed with the latest (-current) version of tcpdump from tcpdump.org - which supports verification of TCP MD5 digests (chel3ixy is the MD5 key): # tcpdump -ni xl1 -s 1500 -M chel3ixy tcp port 179 Here we see normal BGP keepalives, all MD5 digests valid: 21:19:10.183900 IP 7.0.0.18.3961 7.0.0.9.179: P 76:95(19) ack 77 win 17102 nop,nop,md5:valid: BGP, length: 19 21:19:10.184306 IP 7.0.0.9.179 7.0.0.18.3961: P 77:96(19) ack 95 win 16206 md5:valid,eol: BGP, length: 19 21:19:10.298365 IP 7.0.0.18.3961 7.0.0.9.179: . ack 96 win 17083 nop,nop,md5:valid 21:19:40.181172 IP 7.0.0.18.3961 7.0.0.9.179: P 95:114(19) ack 96 win 17083 nop,nop,md5:valid: BGP, length: 19 21:19:40.181690 IP 7.0.0.9.179 7.0.0.18.3961: P 96:115(19) ack 114 win 16187 md5:valid,eol: BGP, length: 19 21:19:40.280368 IP 7.0.0.18.3961 7.0.0.9.179: . ack 115 win 17064 nop,nop,md5:valid 21:20:10.202449 IP 7.0.0.18.3961 7.0.0.9.179: P 114:133(19) ack 115 win 17064 nop,nop,md5:valid: BGP, length: 19 21:20:10.202831 IP 7.0.0.9.179 7.0.0.18.3961: P 115:134(19) ack 133 win 16168 md5:valid,eol: BGP, length: 19 21:20:10.302389 IP 7.0.0.18.3961 7.0.0.9.179: . ack 134 win 17045 nop,nop,md5:valid 21:20:40.214582 IP 7.0.0.18.3961 7.0.0.9.179: P 133:152(19) ack 134 win 17045 nop,nop,md5:valid: BGP, length: 19 21:20:40.214960 IP 7.0.0.9.179 7.0.0.18.3961: P 134:153(19) ack 152 win 16149 md5:valid,eol: BGP, length: 19 21:20:40.314417 IP 7.0.0.18.3961 7.0.0.9.179: . ack 153 win 17026 nop,nop,md5:valid After a while I decided to change the MD5 key. The session with the new key came up and looked fine, but the old session didn't close properly. Notice the close is initiated from the Juniper side, and the first packet from the Cisco side is now sent with an invalid MD5 digest - it turns out that the packet is actually sent with an MD5 digest based on the *new* key: 21:20:56.850905 IP 7.0.0.18.3961 7.0.0.9.179: F 173:173(0) ack 153 win 17026 nop,nop,md5:valid 21:20:57.845617 IP 7.0.0.18.3961 7.0.0.9.179: FP 152:173(21) ack 153 win 17026 nop,nop,md5:valid: BGP, length: 21 21:20:59.845711 IP 7.0.0.18.3961 7.0.0.9.179: FP 152:173(21) ack 153 win 17026 nop,nop,md5:valid: BGP, length: 21 21:21:03.846005 IP 7.0.0.18.3961 7.0.0.9.179: FP 152:173(21) ack 153 win 17026 nop,nop,md5:valid: BGP, length: 21 21:21:10.551830 IP 7.0.0.9.179 7.0.0.18.3961: P 153:172(19) ack 152 win 16149 md5:invalid,eol: BGP, length: 19 And since Juniper is now getting packets with invalid MD5 digests (for this session, which hasn't yet been properly closed), we get a *long* sequence (about 10 minutes) of: 21:23:03.854077 IP 7.0.0.18.3961 7.0.0.9.179: FP 152:173(21) ack 153 win 17026 nop,nop,md5:valid: BGP, length: 21 21:24:05.941658 IP 7.0.0.9.179 7.0.0.18.3961: FP 153:212(59) ack 152 win 16149 md5:invalid,eol: BGP, length: 59 21:24:07.858411 IP 7.0.0.18.3961 7.0.0.9.179: FP 152:173(21) ack 153 win 17026 nop,nop,md5:valid: BGP, length: 21 21:25:11.862725 IP 7.0.0.18.3961 7.0.0.9.179: FP 152:173(21) ack 153 win 17026 nop,nop,md5:valid: BGP, length: 21 21:25:35.028423 IP 7.0.0.9.179 7.0.0.18.3961: FP 153:212(59) ack 152 win 16149 md5:invalid,eol: BGP, length: 59 21:26:15.867021 IP 7.0.0.18.3961 7.0.0.9.179: FP 152:173(21) ack 153 win 17026 nop,nop,md5:valid: BGP, length: 21 21:27:04.115353 IP 7.0.0.9.179 7.0.0.18.3961: FP 153:212(59) ack 152 win 16149 md5:invalid,eol: BGP, length: 59 21:27:19.871338 IP 7.0.0.18.3961 7.0.0.9.179: FP 152:173(21) ack 153 win 17026 nop,nop,md5:valid: BGP, length: 21 And for every packet from the Juniper side (trying to close the old BGP session properly, with the correct MD5 key for the old session), the Cisco side now logs an invalid digest: Apr 24 21:23:03.854 %TCP-6-BADAUTH: Invalid MD5 digest from 7.0.0.18(3961) to 7.0.0.9(179) Apr 24 21:24:07.857 %TCP-6-BADAUTH: Invalid MD5 digest from 7.0.0.18(3961) to 7.0.0.9(179) Apr 24 21:25:11.860 %TCP-6-BADAUTH: Invalid MD5 digest from 7.0.0.18(3961) to 7.0.0.9(179) Apr 24 21:26:15.863 %TCP-6-BADAUTH: Invalid MD5 digest from 7.0.0.18(3961) to 7.0.0.9(179) Apr 24 21:27:19.871 %TCP-6-BADAUTH: Invalid MD5 digest from 7.0.0.18(3961) to 7.0.0.9(179) Meanwhile, the new session (with the new MD5 key) is up and all is well *on that session*. But because the Cisco side keeps logging these messages, it *looks* like the new session is somehow not working. As far as I can see, the bug here is clearly on the Cisco
Re: Juniper failes to change keys (More MD5 fun: Cisco uses wrong MD5key for old session after key change)
After a while I decided to change the MD5 key. The session with the new key came up and looked fine, but the old session didn't close properly. Notice the close is initiated from the Juniper side, and the first packet from the Cisco side is now sent with an invalid MD5 digest - it turns out that the packet is actually sent with an MD5 digest based on the *new* key: This is a feature, and hopefully Juniper will also add the same feature soon. The feature allows you to change the MD5 key without flapping the BGP session which is very important on large peering sessions. There is no requirement that MD5 keys must remain constant throughout an entire TCP session, or to terminate a TCP session when the key changes. As long as both sides agree, the key can be changed at any time including in the middle of a TCP session. New packets after the key change are sent with message digests based on the new key. But as long as the session *is* reset anyway, the current situation is extremely confusing - the log messages (on both Cisco and Juniper) give no indication that the invalid key in question is for an *old* BGP session, no longer active! Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Alternate and/or hidden infrastructure addresses (BGP/TCP RST/SYNvulnerability)
(TTL should only be decremented when _forwarding_, and I don't think you could argue that you need to _forward_ a packet from your ingress interface to your _loopback_ interface..) Well, if that were the case, then you wouldn't need multi-hop to do loopback peering. Different issue (directly connected interfaces vs not directly connected). Easy test: Connect two routers (I used Ciscos) to the same Ethernet switch, sniff the traffic between them. Ping from one router to the other on the directly connected interfaces, observe TTL with sniffer. Ping from loopback on one router to loopback on the other, observe TTL again. I see the *same* TTL in both cases, which means that at least for the IOS version I was testing, TTL is not decremented when sending from the loopback interface. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Packet Kiddies Invade NANOG
People should be worried about stuff like this. Banetele is a facilities-based network operator in Norway and these guys are directly attacking their BGP sessions to put them off the air. Can anyone from Banetele/who knows Banetele confirm this attack took place? According to the people I spoke to, they had not noticed such an attack on the date specified. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] (who used to work for BaneTele, and was intimately involved with getting suitable BGP filters in place)
Re: Packet Kiddies Invade NANOG
Hmm, if someone (except masochists and security vendiors) still hosts efnet... I can only send them my condoleences. I saw sthe same dialogs 6 years ago. Nothing changes. BaneTele hosts an EFnet IRC server. Caused no significant problems while I was working at BaneTele. That's probably because we *expected* DoS attacks on the IRC server, and engineered the network accordingly. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: MTUs - Was: Strange public traceroutes return private RFC1918addresses
Why is the MTU on Ethernet 1500 bytes? I have looked through various docs (eg IEEE Std 802.x) and can find where maxUntaggedFrameSize is listed as 1518 octets, but there is no mention of why this was chosen. I know where the minimum frame size comes from (CSMA/CD and propagation times, etc), but the maximum frame size number sounds fairly arbitrary. I believe Rich Seifert once said (on comp.dcom.lans.ethernet) that the cost of the necessary buffer memory for the first Ethernet cards was a relevant factor. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Poor connectivity to new b.root-servers.net address?
the problem seems to be in the level3/cenic/losnettos path. juniper -ge- gsr -ge- foundary -ge- foundary -ge- foundary -100m- 7513 the IP path is: juniper - 7513 more as we unearth the problems... What I didn't mention in my original post is that this problem has existed, as far as I can see, since B was moved to a new address. Anyway - it seems things are fixed now. DNS lookup, traceroute and ping work from AS 2116 (source address 193.71.2.2) and AS 3307 (source address 194.19.15.2). There are still timeouts at the router hop before 130.152.181.66, which looks like it should be 67.30.130.66, traceroute'ing from 193.71.2.2 and 194.19.15.2: 13 so-10-0.hsa1.Tustin1.Level3.net (209.244.27.154) 188.092 ms so-9-0.hsa1.Tustin1.Level3.net (209.244.27.174) 188.118 ms 187.955 ms 14 * * * 15 130.152.181.66 (130.152.181.66) 177.112 ms 177.141 ms 177.202 ms and 13 so-11-0.hsa1.Tustin1.Level3.net (209.244.27.162) 188.861 ms 188.604 ms so-8-0.hsa1.Tustin1.Level3.net (209.244.27.166) 188.947 ms 14 * * * 15 130.152.181.66 (130.152.181.66) 187.970 ms 187.573 ms 187.399 ms The missing hop here is visible as 67.30.130.66 coming from 129.241.1.16 (AS 224). I'm not going to worry too much about the traceroute timeouts, even if it would be nice if that could also be fixed. The main point is that DNS lookups are now working as they should. Thanks! Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Poor connectivity to new b.root-servers.net address?
I have two sites (in AS 2116 and 3307) here in Norway which cannot reach the new b.root-servers.net address, 192.228.79.201. No answers to DNS requests, no ping replies, traceroute times out. Everything works normally from a third site, in AS 224. Both prefixes (193.71.0.0/16 and 194.19.0.0/17) of the problem addresses are visible on route-views.oregon-ix.net, via multiple paths. Any suggestions why this is happening? Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] --- traceroute from AS 2116 (source address 193.71.2.2): 1 vortex-e1 (193.69.2.1) 0.211 ms 0.168 ms 0.148 ms 2 v560.rs1.osl-sand.inet.catchcom.no (193.75.4.117) 0.364 ms 0.376 ms 0.324 ms 3 ge-0-2-0-202.br3.gaus.no.catchbone.net (193.75.3.61) 0.831 ms 0.991 ms 0.718 ms 4 so-0-3-0.ar1.OSL1.gblx.net (64.213.23.65) 0.728 ms 0.717 ms 0.824 ms 5 pos12-0-2488M.cr2.HAM1.gblx.net (67.17.74.185) 18.857 ms 18.855 ms 19.101 ms 6 so0-0-0-2488M.cr2.LON3.gblx.net (67.17.64.38) 43.637 ms 43.511 ms 43.546 ms 7 so7-0-0-2488M.ar2.LON3.gblx.net (67.17.66.30) 43.604 ms 43.869 ms 43.626 ms 8 Level-3public-peering.ge-5-0-0.ar2.LON3.gblx.net (208.51.239.162) 43.768 ms 43.852 ms 43.923 ms 9 ae-0-55.mp1.London1.Level3.net (212.187.131.161) 44.186 ms 44.197 ms 44.149 ms 10 so-1-0-0.mp1.London2.Level3.net (212.187.128.49) 44.388 ms 44.417 ms 44.245 ms 11 so-1-0-0.bbr1.Washington1.Level3.net (212.187.128.138) 117.160 ms 117.296 ms 116.990 ms 12 so-3-0-0.mpls1.Tustin1.Level3.net (209.247.8.121) 178.607 ms 178.837 ms 178.576 ms 13 so-10-0.hsa1.Tustin1.Level3.net (209.244.27.154) 178.710 ms 178.529 ms 178.500 ms 14 * * * 15 130.152.181.66 (130.152.181.66) 177.340 ms 177.246 ms 177.298 ms 16 * * * traceroute from AS 3307 (source address 194.19.15.2): 1 nethelp-gw.banetele.net (194.19.15.1) 0.987 ms 0.891 ms 0.882 ms 2 oslo-a2.banetele.net (194.19.80.13) 6.389 ms 6.234 ms 6.205 ms 3 sand.osl.banetele.net (194.19.81.45) 6.498 ms 6.337 ms 6.332 ms 4 if-1-2.core2.Oslo.teleglobe.net (80.231.89.21) 7.128 ms 6.739 ms 6.796 ms 5 if-5-0.core1.Oslo.teleglobe.net (80.231.88.5) 119.151 ms 119.004 ms 119.184 ms 6 if-4-11.core2.London2.teleglobe.net (80.231.88.14) 210.376 ms 199.959 ms 206.017 ms 7 if-9-0.core2.Newark.Teleglobe.net (66.110.8.141) 118.323 ms 118.300 ms 118.073 ms 8 if-7-0.core1.Newark.Teleglobe.net (207.45.222.161) 117.308 ms 117.072 ms 116.978 ms 9 if-5-0.core2.Ashburn.Teleglobe.net (66.110.8.17) 116.370 ms 116.979 ms 116.195 ms 10 so-1-2-0.e1.Washington1.Level3.net (65.59.88.209) 113.998 ms 113.905 ms 113.767 ms 11 so-2-1-0.bbr1.Washington1.Level3.net (209.244.11.9) 114.371 ms 113.935 ms 113.795 ms 12 so-1-0-0.mpls2.Tustin1.Level3.net (209.247.8.117) 183.813 ms 183.557 ms 183.711 ms 13 so-8-0.hsa1.Tustin1.Level3.net (209.244.27.166) 183.242 ms 183.647 ms so-11-0.hsa1.Tustin1.Level3.net (209.244.27.162) 183.154 ms 14 * * * 15 130.152.181.66 (130.152.181.66) 182.641 ms 182.046 ms 185.201 ms 16 * * * traceroute from AS 224 (source address 129.241.1.16): 1 runit-sw1.runit.no (129.241.1.1) 5.753 ms 2.719 ms 0.953 ms 2 runit-gw.runit.no (129.241.249.77) 15.607 ms 13.284 ms 16.016 ms 3 trd-gw (129.241.249.14) 14.025 ms 14.839 ms 10.817 ms 4 oslo-gw1 (128.39.46.1) 22.427 ms 18.854 ms 20.827 ms 5 no-gw.nordu.net (193.10.68.101) 18.472 ms 20.159 ms 21.216 ms 6 se-kth.nordu.net (193.10.68.29) 29.554 ms 29.238 ms 29.233 ms 7 so-1-0.hsa2.Stockholm1.Level3.net (213.242.69.21) 28.094 ms 27.161 ms 29.325 ms 8 so-4-1-0.mp2.Stockholm1.Level3.net (213.242.68.205) 30.072 ms 27.242 ms 25.611 ms 9 so-0-0-0.mp1.London2.Level3.net (212.187.128.61) 61.408 ms 59.909 ms 65.957 ms 10 so-1-0-0.bbr1.Washington1.Level3.net (212.187.128.138) 137.661 ms 134.997 ms 136.561 ms 11 so-1-0-0.mpls2.Tustin1.Level3.net (209.247.8.117) 196.734 ms 198.486 ms 202.194 ms 12 so-11-0.hsa1.Tustin1.Level3.net (209.244.27.162) 201.479 ms 199.805 ms so-8-0.hsa1.Tustin1.Level3.net (209.244.27.166) 198.810 ms 13 67.30.130.66 (67.30.130.66) 216.913 ms 215.330 ms 214.481 ms 14 130.152.181.66 (130.152.181.66) 214.449 ms 217.795 ms 211.176 ms 15 b.root-servers.net (192.228.79.201) 216.927 ms 211.889 ms 213.429 ms
RE: CIsco 7206VXR w/NPE-G1 Question
PXF is found in the 7400 (old) and 7300 (newer) series. Not true. 7401 has a PXF. It's essentially an NSE-1 with GE/IO in a pizza box. 7301 is based on the NPE-G1 and doesn't have a PXF anywhere in sight. On the other hand, the (original) 7304 used PXFs, on the NSE-100 forwarding engine. Cisco later introduced the NPE-G100 for the 7304 with a much more powerful CPU, but no PXF. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
RE: CIsco 7206VXR w/NPE-G1 Question
Keep in mind, 72xx is still flow-based, so you need to count *both* shared fabric capacity (aka PCI buses) and capacity of NPE to establish flows (aka pps rate). Why do you say it is flow-based? You *do* use CEF, don't you? In which case 7200 with NPE-G1 is a prefix-based architecture, with software forwarding. NPE-G1 might probably route 3*GE, without any services and if all 3GE are in a single flow, but will melt down at a face of one-packet-per-flow DDoS (read: Nachi worm) at a far lower rate (I'd be surprised if it sustains 200kpps DDoS traffic, which can be as low as 150Mbit bandwidth). It's the pps that counts, not whether it is one packet per flow or many. We actually tested NPE-G1 a bit today with small (64 byte) packets, and we reached considerably higher pps numbers. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
3550 runs IOS. That's an answer. I never allow any non-IOS router in production environment (except high end devices, such as Juniper, when benefits are very high). And 3550 is not expansive (yes, it is not cheap). If you believe that IOS solves all problems, we live on different planets. PS. How much ethernet ports do you have in the office? Do you have 100 K ports? If not, why do you need 128K MAC's? (I know only one case, when I need so much - some kind of DSL service... Some kind of DSL service is indeed the background for my question. In most cases, you have 500 - 5,000 ports in one building. If you have more, it is unlikely that you use 3550 switches. So, it is enough for the tasks (just as performance - it have _enough_ performance). Btw, I believed that catalist swithes have not any limitations for the MAC tables (because they use memory _on demand_); where did you get this limitations? /I may be wrong here/ If you believe Catalyst switches have no MAC address limitations, I have a nice plot of land in Florida to sell you :-) Ethernet switches today use CAM to hold the MAC address tables - this CAM has a finite size. PPS. I do not know for sure, but 3550 should support traffic shaping, which makes bufferring. Technically, yes, CEF (with packet dropping) is not good to provide 2 Mbit by 100 Mbit link. 3550 only supports policing. Yes, I have worked extensive with 3550 and it doesn't have the features I need right now. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
3550 runs IOS. this is a benefit, especially in a switch? If your whole support organization is geared towards IOS, and unable to learn other CLIs, it may well be. Fortunately, not all support organizations are like that :-) Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
1) Cisco ISL is much better than urgly 802.1q - first of all, it was designed many years before 802.1q. I am not even talking abiout those idiots, who designed 802.1q as a _spanning tree on the trunk level_, which made many configurations (which we used with ISL ain 199x years) impossble, and caused vendors to extend 802.1q. Is it April 1st? ISL changes the size of packets, does it not? So know you have to deal with MTU issues. What happens when I want the biggest MTU possible? I know it is not much a difference in size, but for some people, size does matter. I am quite happy with dot1q. My gripe is with poor spanning-tree implementations. I don't want a single spanning-tree for every vlan on a trunk... I like standards, but I am happy with Rapid-PVST. Just my feelings about the issue. I would never deploy ISL unless I had something like a 1900 that did not do dot1q Amen. At my previous employer, we got rid of ISL on almost all trunks. I wouldn't dream of going back. The only thing I don't really like about 802.1q compared to ISL is the idea of native or default VLAN. I want links to be either access (untagged) or trunk (*all* packets tagged). Fortunately, reasonably new Cisco switches let me enforce that with vlan dot1q tag native. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
ISL _DOES NOT CHANGE_ packet size. An 802.1q tag adds 4 bytes to the Ethernet frame. ISL encapsulation adds 30 bytes to the Ethernet frame. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Any 1U - 2U Ethernet switches that can handle 4K VLANs?
Both the ISL _and_ the Dotq headers are stripped off at the trunk interface so they _both_ change the packet size but neither alters the payload. Obviously. But the fact that ISL adds 26 bytes more than 802.1q means that multiple levels of ISL encapsulation is somewhat less practical than multiple levels of 802.1q tags. Some of us *need* those multiple levels of 802.1q tags. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Any 1U - 2U Ethernet switches that can handle 4K VLANs?
Does anybody know of 1U - 2U form factor Ethernet switches that can handle 4K VLANs, or at a minimum 2000 VLANs? Note that we're specifically looking for the ability to handle this number of VLANs operating simultaneously, not only VLAN *IDs* in the full 4K range. (This rules out popular switches like the Cisco 3550 and 3750 series, which can only handle 1024 VLANs operating simultaneously.) The switches should have 12 - 24 Fast Ethernet ports. Some form of Q in Q or stackable VLANs, ie. the ability to handle more than one VLAN tag, is vital. Spanning tree is needed, but can be one common spanning tree for all VLANs (per-VLAN spanning tree is not needed). Other features that would be nice to have: - RSTP (802.w) and MST (802.1s). - A couple of GigE ports (GBIC or SFP based, presumably) for uplinks. - L3 (IP routing). - DC power. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Nachi/Welchia Aftermath
T( The 2948G-L3 and the 4908G-L3 I believe are Prefix/ASIC based. T( I believe the 3550-EMI is as well, but I'm not familiar with that T( equipment. All 3550s are prefix/ASIC based, EMI or SMI doesn't matter. Anyone know about the: Cisco Catalyst 3750 ? 3750s are also prefix/ASIC based. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: IANA down?
http://www.iana.org It appears so from here...and other places.. Works fine from here (Oslo, Norway). Port 80 okay, traceroute: % traceroute www.iana.org traceroute to www.iana.org (192.0.34.162), 64 hops max, 44 byte packets 1 nethelp-gw.banetele.net (194.19.15.1) 0.983 ms 0.842 ms 0.857 ms 2 oslo-a2.banetele.net (194.19.80.13) 5.605 ms 6.206 ms 6.218 ms 3 sand.osl.banetele.net (194.19.81.45) 6.356 ms 6.268 ms 6.338 ms 4 if-1-2.core2.Oslo.teleglobe.net (80.231.89.21) 7.053 ms 6.886 ms 7.105 ms 5 if-5-0.core1.Oslo.teleglobe.net (80.231.88.5) 122.524 ms 122.069 ms 121.780 ms 6 if-4-11.core2.London2.teleglobe.net (80.231.88.14) 121.629 ms 122.822 ms 121.621 ms 7 if-9-0.core2.Newark.Teleglobe.net (66.110.8.141) 122.299 ms 121.851 ms 122.107 ms 8 if-9-0.core1.Ashburn.Teleglobe.net (64.86.83.214) 121.376 ms 121.354 ms 121.495 ms 9 POS2-3.BR3.DCA6.ALTER.NET (204.255.174.197) 123.016 ms 123.201 ms 123.124 ms 10 0.so-3-1-0.XL1.DCA6.ALTER.NET (152.63.38.118) 117.694 ms 117.226 ms 116.658 ms 11 0.so-0-0-0.TL1.DCA6.ALTER.NET (152.63.38.69) 116.998 ms 117.068 ms 117.371 ms 12 0.so-0-1-0.TL1.LAX9.ALTER.NET (152.63.9.230) 181.698 ms 181.953 ms 181.906 ms 13 0.so-0-0-0.XL1.LAX9.ALTER.NET (152.63.115.137) 181.929 ms 182.103 ms 181.869 ms 14 POS6-0.GW6.LAX9.ALTER.NET (152.63.116.97) 182.035 ms 181.910 ms 182.047 ms 15 icann-gw.customer.alter.net (157.130.247.6) 185.549 ms 186.025 ms 185.753 ms 16 * * * Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Bandwidth Control Question
The quite annoying thing about that is switching a PC-MC-2T3+ interface from channelized (the default) to unchannelized causes a cbus complex restart, which interrupts traffic through the router for a period of time (the time varies based on the number of interfaces in the router). Even with service single-slot-reload-enable? Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Router with 2 (or more) interfaces in same network
You _used_ to be able to do this (oh, over two years ago?). The address was assigned to the interface, and the error from trying to add a duplicate route was simply ignored, no route got added anywhere. You can figure out when the change was made by examining the code or by seeing when the maillists started to get flooded by people who could no longer do, # ifconfig if0 inet 10.0.0.1 # ifconfig if0 alias 10.0.0.2 When they meant, # ifconfig if0 inet 10.0.0.1 # ifconfig if0 alias 10.0.0.2 netmask 0x There is a difference, of course - Cisco is perfectly happy to let you do int fa0 ip addr 10.0.0.1 255.255.255.0 ip addr 10.0.0.2 255.255.255.0 secondary I never could understand why this should be impossible in FreeBSD. But I guess this discussion is no longer NANOG relevant :-) Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: short question
I have a question. I need for a project a small router than can do 2xFE @wire speed, IOS IP feature set, and it will do BGP with a small subset of the global routing table (~1000 networks). Price is a big issue, but so is stability and reliability of the platform. Cisco Catalyst 3550 with EMI feature set. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
RE: Yankee Group declares core routing obsolete (was Re: Anybodyusing GBICs?)
Things are getting better, but L3-switches pale in comparison to today's high-end routers on almost all fronts. If you take GigE out of the equation, modern L3 Switches are just as expensive as modern core routers - and routable, mpls-able L3 GE ports are _more_ expensive on switches than routers (see 4xGE OSM vs 4xGE GSR 'tetra' pricing). In *my* Cisco GPL, 4GE-SFP-LC is listed at $75,000 while OSM-2+4GE-WAN+ is listed at $44,000. But then I tend to think of the 6500/7600 as a router... Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: [arin-announce] IPv4 Address Space (fwd)
Yes, because IPv6 is merely and incremental improvement, not a grand elegant solution to world hunger like ATM. Look at how we managed the incremental step of adding MPLS to our IPv4 networks. It was fairly painless because it uses the same boxes, the same people and the same management systems. And over time, the pain of doing MPLS is reduced because the bugs get worked out. Yes, but did MPLS require different ASICs? In some cases, yes. Cisco Catalyst 6500 with Sup2/MSFC2/PFC2 cannot do MPLS by itself, while 6500 with Sup720 can. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Extreme BlackDiamond
I can understand how a virus like Welchia can affect a flow-based architecture like Extremes. I was under the impression that CEF enabled Cisco gear wouldnt have this problem, but Cisco has instructions on their webpage on how deal with it and cites CPU usage as the reason. With CEF I thought the CPU wasn't involved? CEF is perhaps differently implemented on different plattforms? I think CEF in HW is the key, ASIC based and not Flow based. I'm not all-knowlegable on which platforms do this, but the 7500, 12000, 2948G-L3, 4908 have it. Yup. We have 6509s with Sup2/MSFC2/PFC2, and have had no problems with ICMP in connection with recent virus/worm attacks. Oh yeah, we also find the 6509s work very well as routers. Full routing tables, etc. YMMV. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
RE: Extreme BlackDiamond
On the other hand, 6500s can do both L2 and L3 rather well, including BGP. Aren't most of the 6500 blades the same as the 7600 ones anyway? Between these two IMHO we are looking at a blurry distinction between a router with very good switching capabilities and a L3 switch with very good routing capabilities. Until the Sup720, it was simple: 6500 with Sup2/MSFC2/PFC2 and at least one OSM equals 7600. The difference is mostly a marketing one. I don't understand how you can differentiate between a router and an L3 switch. In my view L3 switch is a marketing term. All high end boxes do hardware based IP forwarding, whether their ancestry is from the L2 or the L3 side. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: Change to .com/.net behavior
While I too am outraged by the actions of Verisign, I've decided to NOT modify my servers in any way. I might decide to block the sitefinder IP, but I will not change my nameservers into modifying DNS responses. Doing so would be to break things, *You* cannot modify DNS responses, but it's okay for Verisign to do so? Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Re: wire rate filtering and policy routing
Aside from Juniper, what are the options for wire rate filtering and policy routing (for at least 1Gbps and say 500+kpps)? As usual, private responses will result in a summary to the list. Cisco 6500 with Sup2/MSFC2/PFC2 or with Sup720. If you don't need a full routing table you might even be able to do it with a Cisco 3550. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
RE: North America not interested in IP V6
In europe, when any consumer gets a net connection it's sold as a pipe to do anything you want with (as long as it abides by laws and netiquette. That is certainly not the case everywhere in Europe. In Norway, there are several operators that have limitations on your use of xDSL, for instance (no servers, only x GB per month of downloads etc). Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
