IX port security
Hi all, Thinking back about this thread we've had lately around IXes, I have some extra questions. It is I assume the IX's responsibility to protect members from harming each other through the peering LAN. For that purpose, the IX has to do some minimum sanity checks before letting a member in into the production VLAN, for instance by using a quarantine VLAN to probe its traffic first. Then, once those checks are done, the IX shall apply a minimum security configuration to each member port: 1/ limiting broadcast/unknown unicast on each member port 2/ filtering bpdu 3/ locking mac addresses Here are my questions: - re 1/, any clue about the PPS or %bandwidth values to be configured to limit broadcast/unknown unicast ? - re 3/ should a certain number of allowed mac-addresses be configured to the port (1 or 2) ? or should the customer's port mac be explicitly configured on the port ? - more importantly, is there any other standard precaution that I'm missing and that should be considered ? cheers, Greg VILLAIN Independant Network/Telco Architecture Consultant
Re: IX port security
On Feb 24, 2008, at 4:58 PM, Andy Davidson wrote: On 23 Feb 2008, at 11:19, Greg VILLAIN wrote: Thinking back about this thread we've had lately around IXes, I have some extra questions. It is I assume the IX's responsibility to protect members from harming each other through the peering LAN. That depends what you mean by protect. Any IX participant must remember that they're sharing an infrastructure with (by and large) competitors, and that there are particular miscreant activities that you as an IX participant must guard against, which your IX operators can't completely protect you from (I'm thinking pointing default, or attacks on port-facing router interfaces.) I've been thinking a lot about pointing defaults, I admit I think of any solution to avoid that... Anyone any idea ? (I was initially thinking making a route server mandatory would solve that, but it actually doesn't...) All of your suggestions are very sane, with this comment - re 3/ should a certain number of allowed mac-addresses be configured to the port (1 or 2) ? or should the customer's port mac be explicitly configured on the port ? This is largely down to local policy - one mac one port is sane, but depending on how your exchange has evolved and the services it offers, I can see the case for permitting different macs on different vlans too. Port security violations are normally caused by participants plugging IXes into a switch which ends up running some kind of chatty protocol, and by participants changing l3 interfaces connected to the exchange without informing IX support, rather than loops - but loops do happen, so define a policy and apply it strictly. Got this idea of a member portal feature, where the IX member can record one or more MACs via the web interfaces. Then a robot can easily clear those on the port, read the new ones, compare to those provided on the web portal, and ultimately lock them. That would reunite both security and flexibility for the member to change its kit on his end. (Still, I'd need to log any changes via the portal and limit the amount of changes in a given time for DoS reasons on the platform's switches). I've seen many ISPs do that with customer CPEs, so they don't change them. Best wishes Andy Davidson, www.lonap.net Greg VILLAIN Independant Network & Telco Architecture Consultant +33 6 87 48 66 14
Re: mtu mis-match
On Mar 19, 2008, at 8:05 PM, ann kok wrote: Hi I have this problem about mtu mismatch Some DSL clients, some are working fine. (browsing...ping ...) Some DSL clients have this problem they can't browse the sites. they can ssh the host but couldn't run the command in the shell prompt ping packet are working fine (no packet lost) Why? but I still don't know why mtu can cause this problem Thank you for your help Sounds like the old PPPoE issue : 1500 vs 1492. It usually is dealt with on a per destination basis: For a given destination (the ones that are causing problems to you) start with : ping -D -s 1500 and lower the -s value until the ping goes through. -D forces "don't fragment bit" -s manages packetsize When your ping reaches your destination, your -s size is good (for that destination only...). Greg VILLAIN Independent Network & Telco Architecture Consultant Greg VILLAIN Independant Network & Telco Architecture Consultant +33 6 87 48 66 14
Re: 10GE router resource
On Mar 24, 2008, at 10:23 AM, user user wrote: Hi everybody! I find myself in the market for some 10GE routers. As I don't buy these everyday, I was wondering if any of you guys had any good resources for evaluating different vendors and models. I'm mainly thinking about non-vendor resources as the vendorspeak sites are not that hard to find. Also I'd love to hear recommendatios for "budget" 10GE routers. The "budget" router would be used to hook up client networks through one 10GE interface and connect to different transit providers through two 10GE interfaces. - Zed Hiya, When it comes to budget, force10 are good. I wouldn't be able to confirm if they're worth performance-wise. I'd strongly suggest Foundry, I'm a big fan of their kits, price-wise and performance-wise, provided you do not need rocket-science features. MLX/XMR models will surely do the trick perfectly. When it comes to router purchasing habits, we all tend to get religious... Bottom line is that most of the 'regular' vendors (namely Cisco, Juniper, Foundry, Force10, Extreme, Riverstone) implement pretty much the same set of features, which are all IETF/IEEE normalized, meaning if you don't need proprietary features (and you'll wish you don't), any router will be fine, the only difference will come from: - the chassis being non-blocking or not (i.e. backplane design) - the price per port - the operating OS - the feeling you'll get with the salesperson, and the reputation of their Support Teams. - vendor specific features such as Flow Sampling To make it simple, most vendors have an IOS like OS, except Juniper which has a really clever and elegant OS, but are very pricey. Foundry and Force10 have the cheapest price per port Cisco does only Netflow, Foundry & Force10 only SFlow (which is a true standard) and I think Juniper does JFlow Cisco's kits are packed with proprietary protocols (HSRP and GLBP instead of VRRP, their own ethernet trunking, EIGRP as their own and yet extremely efficient IGP, TCL scriptable CLI...) , some of them are really good, some are crappy, but I suggest you'd stick with IEEE/IETF protocol to avoid future trouble. One thing: RSTP/802-1w is very (very, very, very) not often interoperable between vendors who all have their own interpretation of the norm and can quickly turn into a nightmare. I'd strongly suggest try&buys if (R)STP interoperability is required, but I'm a little paranoid :) Greg VILLAIN Independant Network & Telco Architecture Consultant
Re: 10GE router resource
On Mar 26, 2008, at 11:57 AM, <[EMAIL PROTECTED]> wrote: http://docs.rodecker.nl/10-GE_Routing_on_Linux.pdf. He hit a wall at 700K pps and was using two dual core Intel Xeon 64bit 2.33GHz CPUs and 2GB of RAM in a Dell PowerEdge 1950. Unless I am misreading this, he did not hit a wall. What he did was test a design that was scalable to multiple cores and show that the two core version could not go beyond 700k pps. The next logical question is how much more can you push with larger numbers of cores. The key thing is to use a recent Linux kernel that can share interrupts among multiple cores and to run it on a CPU using MSI interrupts. Since this was written up in January of 2007, There are people who use Linux for load balancing who also are working on finding how well it can cope with 10G of traffic and they have some anecdotal evidence of 800k pps. --Michael Dillon If I just may share my opinion on this whole Software Router debate. Even if it is technically feasible to route traffic over a server, I would not hesitate to sound old-fashioned and state that it is not a server's main role, i.e. what it is designed for. Mainly, I would assume that you'd get the same Network I/O issues with small packets that Disk I/O you would notice in a strictly systems/ server environment. Most of all, Routing Equipment manufacturers offer more than a physical routing chassis, they offer Hardware and Software support and that I say, is essential - if you want open source in your routing devices, I'd suggest you pick Juniper, their OS is BSDdey - you'll love it, plus they will provide you with support, which good or bad, will be better than none in times where you'll be stuck with an undocumented memory leak of your favorite open source software routers. It is not about making it work, it is about having it work -all the time-, even if it is more costly, even if YOU have failed troubleshooting a crash, SOMEONE will be forced to help you, by contract. Risk assessment folks, risk assessment... Greg VILLAIN Independant Network & Telco Architecture Consultant Greg VILLAIN Independant Network & Telco Architecture Consultant +33 6 87 48 66 14
Re: Inventory and workflow management systems
On Apr 4, 2008, at 11:16 PM, vijay gill wrote: What software solution do people use for inventory management for things like riser/conduit drawdown, fiber inventory, physical topology store, CLR/DLR, x-connect, contracts, port inventory, etc. Any experiences in integrating workflow into those packages for work orders, modeling, drawdown levels, etc. /vijay Seen loads of the running, (Granite's Xpercom which I have used a lot in the POS industry and which is a pain, Telcordia which back then was known to be even worse...), none of them was worth a dime... Then I saw that brilliant combination which was Comptel + Visionael, it did mass provisioning and inventory systems for a whole national DSL unbundling architecture in France. Takes some time and patience to mix/tune them together, but once done ... Greg VILLAIN Independant Network & Telco Architecture Consultant +33 6 87 48 66 14
Re: [NANOG] [Nanog] Routing Policy Information
On Apr 23, 2008, at 11:23 PM, Fouant, Stefan wrote: > > > Hi folks, > > Wondering if there is a good repository of information somewhere which > outlines the various major ISPs routing policies such as default > local-pref treatment for customers vs. peers, handling of MED, allowed > prefix-lengths from customers, etc. or would one have to contact each > ISP one was a customer of to ascertain this information. I'm a bit late on that, but I'd tend to think this is commonly done on their RIR aut-num object. This should at least be true for Major Bandwidth providers. > Thanks in advance. > > Stefan Fouant Greg VILLAIN Freelance Network&Telco architecture consultant > Principal Network Engineer > NeuStar ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
[Splitting ARIN assignment] MPLS VPNv4, iBGP, split announce
On May 22, 2008, at 7:02 PM, Joe Maimon wrote: James Kelty wrote: Hey all, I'm looking for an opinion from the group. I have an ARIN /21 assignment and a new requirement for a second data center. Rather than ask for another assignment, I would like to advertise one /22 from one location and the other /22 from the second location both with the same asn. My apps will work that way, so I don't have an issue internally, but I'm looking for a broader base opinion on that. Thanks a lot! -James You should attempt to advertise the /21 at each site along with the site's /22 If you dont have dedicated interconnectivity between the sites, tunneling *carefully* should do the trick. This will ensure that if/when those who filter on strict allocation boundaries dont hear your /22, there will still be reachability, even if suboptimal, to your sites. I have an equivalent dilemma: I'm of course well educated about not de- aggregating and would like, as much as possible, to avoid it. I'm trying to build a small-bandwidth core across an MPLS VPN, and I haven't been able to get an answer from the suppliers I'm auditing (even big ones...) although I'm pretty sure I can do it. Basically, the way I see it is that it would only be equivalent to a situation where hosts on my local LANs had tcp179 sessions across the VPN - but yet some (quite big players, not mentioning them though) are saying it would conflict with their instance of MP-BGP used for the VPN-v4. I seriously doubt it, but don't want to try it if there is a slightest risk. Also, I'm technically convinced that the supplier can maintain my loopback's connectivity and replace my IGP to bear my infrastructure's addressing (well I'd first have to get them to accept whatever OSPF between my router and their CPE, so their CPEs redistribute my subnets into the VPN's vrf on their PEs). I also don't want to add operational complexity by setting tunnels (one of the suppliers advised me to...) to bear the sessions - which I know would work, but I need to be sure my designed can be maintained easily, with least possible training. The only B-Plan that I eventually have, is voluntarily bypass best- practice (should my self esteem suffer from that :) split my announces on different geographical zones, to not have to maintain iBGP sync. Any one of you folks have any such experience ? I'd hate to upset the community and get NOs to peering enquiries just because of that, which basically would make running an AS pointless... Any pointers warmly welcome. Greg VILLAIN Independent internet architect
Re: Querstions about COGENT and their services...
On Jun 3, 2008, at 6:06 PM, TS Glassey wrote: So at one time Cogent was one of the lowest performing bandwidth providers. Anyone have any responses to their current operations? regards, Todd Glassey CISM CIFI Chief Scientist/Founder - Certichron Inc [EMAIL PROTECTED] 650-796-8178 Couple remarks on their reputation in europe, I've never had Cogent transit, so this requires further investigation. They're the cheapest (cost-wise, I wouldn't venture to say technically- wise) in Europe, that's a fact. They often get into peering clashes against major actors, they've recently been in that situation with Telia, in the past with France's incumbent (Orange), Level 3 has also depeered them in the past, this is due to them being brokers and is inherent to their pricing policy - it certainly will keep happening to them in the future. The above point is from my perspective a show-stopper, but a good strategy I've very often heard from some of their customers is to use them to forward traffic towards exotic locations, where QoS is not an issue, or where revenue is not critical. Their IP core is supposedly a patch-work resulting from their numerous past acquisitions (PSINet, Lambdanet to name a few), which can explain the many outages they have. Still, the sales people in Europe are really kind, comprehensive and caring people, which makes it a little better, I suppose :) Hope this helped. Greg VILLAIN Independant internet architect
Re: .255 addresses still not usable after all these years?
On Jun 14, 2008, at 12:26 AM, Mike Lewinski wrote: David Hubbard wrote: I remember back in the day of old hardware and operating systems we'd intentionally avoid using .255 IP addresses for anything even when the netmask on our side would have made it fine, so I just thought I'd try it out for kicks today. From two of four ISP's it worked fine, from Verizon FIOS and Road Runner commercial, it didn't. So I guess that old problem still lingers? The TCP/IP stack in Windows XP is broken in this regard, possibly in Vista as well, though I've yet to have the displeasure of finding out. I have a router with a .255 loopback IP on it. My Windows XP hosts cannot SSH to it. The specific error that Putty throws is "Network error: Cannot assign requested address". At least if I ever need to completely protect a device from access by Windows users, I have a good option :) Mike From what I recall, Microsoft's stack was based on the only free one they could afford back in the Trumpet/Winsock days, namely BSD's. It is either dependent on how the stack is integrated, or it simply implies that BSD's stack is(was) also broken (I'd tend to doubt that). Also, Vista's stack was supposed to have been re-developed from scratch, never checked it. Greg VILLAIN
Re: Force10 Gear - Opinions
On Aug 26, 2008, at 6:46 PM, Owen DeLong wrote: Another thing to note (as near as I can tell, this applies to all vendors). All line cards will function only at the lowest common denominator line card CAM level. IOW, if you have single, dual, and quad-cam cards in your F10 chassis, they'll all act like single-CAM cards. Owen I'd have to second that. This is a very annoying fact, that you will find mentioned nowhere. What I also used to dislike is the lack of verbosity of 'show features' - but that was back a year ago. Btw, you absolutely want to avoid the S series, the CLI is a pain, and is not the same as the E or C series, and lacks many features. Price/10G port is interesting though, but not as much as with Arastra, if that's switching you're into. (never tested any such kits though...) My own 2 cents. Greg VILLAIN
