Re: Verizon FiOS - is BGP an option?
On 08/03/2012 10:31 AM, Richard Miller wrote: --snip-- Perhaps I can route to a co-located server then a tunnel back to the server farm over a static IP DSL or Cable link??? I am stumped. Any ideas? Rich That would indeed be a solution to your problem. Have a cheap colo somewhere. Have them advertise your /24's and route them to your server/router and tunnel/vpn the ips back to your location. It's actually pretty simple. Regards, Chris
Re: Verizon FiOS - is BGP an option?
On 08/03/2012 11:44 AM, Richard Miller wrote: Chris, Been thinking about taking that route no pun intended. It just moves the main link off-site. We've had these T1s for so long the maintenance and ops have become second nature. Someone should be able to route over a DSL/Cable/whatever link. Especially if we had a simple static IP setup. the prices are nuts here or T1s. Back in the day I was paying 3000 per T1..now it's 500/mnth for 1.5 symmetrical. I can get 50/5 or 15/5 from various providers for around 100/mnth! Rich Truth be told you don't even need to pay for a static ip if your termination point supports dynamic clients (i.e. a vpn). It's usually easiest if you have a server as your gateway for the local network too, that'll permit some more granular allowances with the ips, forwarding, etc. OpenVPN is a pretty good daemon for the tunnel. The only thing to keep in mind with the dynamic ips is once in a blue moon (for my area at least) you'll pick up a new ip and have a brief period of packet loss as the vpn re-establishes. Regards, Chris
Re: Peer1/Server Beach support for BGP on dedicated servers
On 05/19/2012 02:19 PM, Bill Woodcock wrote: Any recommendations of such? -Bill I know of a datacenter down in the Carolinas that will do such a setup for those sufficiently clued. Hit me up off list if you're interested in their details. Regards, Chris
Re: Hijacked Blocks
Christopher Morrow wrote: The end of the discussion was along the lines of: Yes, we know this guy is bad news, but he always comes to us with the proper paperwork and numbers, there's nothing in the current policy set to deny him address resources. Happily though he never pays his bill after the first 12 months so we just reclaim whatever resources are allocated then. (yes, comments about more address space ending up on BL's were made, and that he probably doesn't pay because after the first 3 months the address space is 'worthless' to him...) How should this get fixed? Is it possible to make policy to address this sort of problem? -chris If this is the case one could argue that ARIN should be reserving this worthless address space to be used when they receive similar requests in the future. There's no reason personX should get fresh, clean address space when they make additional requests. Regards, Chris
Re: Telecom Collapse?
Joe Abley wrote: I seem to remember when I *did* have dial-tone from Bell Canada I'd pick up the handset and get dead air a disturbing proportion of the time. The idea that copper wire-line providers are the only ones who can provide stable telephony doesn't ring true, for me. There's a reason why the five nines don't include the last mile. Joe Obviously experiences differ. I for one can't remember a single time I've picked up a POTS line and there not be a dial tone. This with living in several different cities along the East Coast. I find it significantly harder for a VOIP service to guarantee availability than a traditional POTS service. And for E911 any increased level of guarantee is better. However, for me it is increasingly more frequent that cell calls don't complete on the first try, or there are bad zones either at home or at work where having a conversation is impossible. Not a huge issue for normal phone calls but in an emergency who wants to be finding that special place where service is clear and the 911 operator can hear you. Personally I'll keep a POTS line in the home, if for nothing more than emergencies, until VOIP and Cell providers can consistently offer the same level of services I've had with a traditional phone. Regards, Chris
Re: Telecom Collapse?
Paul Stewart wrote: There's at least two cell phones in our house whenever the family is home and I have neighbors within quick walking distance. That's assuming they're not doing the same thing you are, are home, or are willing to let you borrow their phone. You're assuming a lot. I find it surprising that many people replying haven't kept a 911 only POTS line. Regards, Chris
Re: Telecom Collapse?
Erik (Caneris) wrote: So it can be argued both ways. Ultimately, it all comes down to marketing and hype. With everything going to IP at both the core and edge (yes, I chose the terms deliberately) and analogue-digital-analogue or TDM-IP-TDM-IP conversation happening so many times, the terms POTS and VOIP are becoming nothing but marketing speak open for abuse. Often, confused by marketing of the big boys, the end users have no clue what they're using, especially when it's CPE-less like VoIP-behind-POTS or hosted PBX or FTTB or cable or even things powered by field equipment. A certain company here tells DSL folks they're on fibre and another one emphasizes to staff to refer to their cable phone service as it's not VoIP, it's IP telephony (I'm not kidding). Regards, -- Erik Caneris None of the above matters if the supposed POTS lines has a greater availability over the true VOIP phone you use via your residential internet service. If they can trick the customer by providing the analogue-digital-analogue service so well that the customer doesn't realize it then the originating comment that started this tangent is moot. They are providing a reliable E911 service over IP. If they're not providing a more reliable service than we're back to the same point. E911 over ip (and VOIP) are generally less reliable than true POTS. Regards, Chris
Re: Is it time to abandon bogon prefix filters?
[EMAIL PROTECTED] wrote: On Sun, 24 Aug 2008 23:21:23 PDT, Tomas L. Byrnes said: You're missing one of the basic issues with bogon sources: they are often advertised bogons, IE the bad guy DOES care about getting the packets back, and has, in fact, created a way to do so. But if you've seen a BGP announcement with a prefix that covers the source, is it really a bogon anymore? IIRC bogon is specific to unallocated space. Whether it be advertised or not should not matter. Regards, Chris
Re: Force10 E300 vs. Juniper MX480
Joe Abley wrote: Hi all, An acquaintance who runs an ISP with an M7i on its border is looking to upgrade, because the M7i is starting to creak from all the flesh-tone MPEGs his customers are sharing. (How times have changed. Back when I was chasing packets, it was flesh-tone JPEGs.) He's looking at the MX480 and the E300. The MX480 is attractive because the M7i has been stable as a rock, and he's familiar with JUNOS. The E300 is attractive because it's half the price of the MX480, and has the potential to hold layer-2 cards as well as layer-3 ports which makes the price per port much more reasonable than the MX480. But he has no experience with Force10 at any ISO layer higher than 2. He doesn't have any exotic requirements beyond OSPF, OSPFv3, BGP, IP and IPv6. There's no MPLS in the picture, for example. However, he's going to want four or five full tables plus a moderate load of peering routes in there. And maybe VRRP. Thoughts from people who have tried one or the other, or both? Or who have faced this kind of problem, and came up with a different answer? Feel free to send mail off-list; I can summarise if there is interest. Joe I would avoid Force10 if at all possible. In the network I managed I've had some fairly surprising stability problems with their S series switches and feature problems (or lack there of) on their E series. Things you kind of scratch your head at and wonder what they were thinking. Juniper on the other hand is indeed a bit pricier but quite a stable platform. If he has to look at alternatives I would suggest Foundry, either the RX-8, MLX-8, or XMR-8000 (depending on requirements) for comparable models to the MX480. Regards, Chris
Re: Force10 E300 vs. Juniper MX480
Keith O'neill wrote: Force 10 is fine. I do suggest he go with the dual cam cards over the regular cards. I am not sure what Chris is talking about but I have used Force 10 for a long time, E, C and S series and have found it very stable. It will do everything you want and then some. The E300 is a good bang for the buck. Sure Foundry might be cheaper but I hear more complaining about Foundry than any other platform. Chris you want to share what issues you have seen with Force 10. Keith - Original Message - From: Chris Marlatt [EMAIL PROTECTED] To: Joe Abley [EMAIL PROTECTED] Cc: nanog [EMAIL PROTECTED] Sent: Friday, July 18, 2008 7:43:33 AM (GMT-0500) America/New_York Subject: Re: Force10 E300 vs. Juniper MX480 Joe Abley wrote: Hi all, An acquaintance who runs an ISP with an M7i on its border is looking to upgrade, because the M7i is starting to creak from all the flesh-tone MPEGs his customers are sharing. (How times have changed. Back when I was chasing packets, it was flesh-tone JPEGs.) He's looking at the MX480 and the E300. The MX480 is attractive because the M7i has been stable as a rock, and he's familiar with JUNOS. The E300 is attractive because it's half the price of the MX480, and has the potential to hold layer-2 cards as well as layer-3 ports which makes the price per port much more reasonable than the MX480. But he has no experience with Force10 at any ISO layer higher than 2. He doesn't have any exotic requirements beyond OSPF, OSPFv3, BGP, IP and IPv6. There's no MPLS in the picture, for example. However, he's going to want four or five full tables plus a moderate load of peering routes in there. And maybe VRRP. Thoughts from people who have tried one or the other, or both? Or who have faced this kind of problem, and came up with a different answer? Feel free to send mail off-list; I can summarise if there is interest. Joe I would avoid Force10 if at all possible. In the network I managed I've had some fairly surprising stability problems with their S series switches and feature problems (or lack there of) on their E series. Things you kind of scratch your head at and wonder what they were thinking. Juniper on the other hand is indeed a bit pricier but quite a stable platform. If he has to look at alternatives I would suggest Foundry, either the RX-8, MLX-8, or XMR-8000 (depending on requirements) for comparable models to the MX480. Regards, Chris Considering I just had another issue pop up sure - I'd be glad to at this point. As provided to another member who contacted me off list: == The S series problems were the worst - customer facing issues. --snip--. The list is noted in SFTOS and FTOS. Our design required layer 3 code on the S50N which caused some of these errors to present themselves: - SFTOS: Limit of 8 ACL's (total ACL line count). Secondary assignments on the switch were unprotected. - SFTOS: OSPF required a specific ACL to form an adjacency even with a default allow. - SFTOS: If an uplink went down with OSPF running (ECMP) when the link was brought back up the OSPF adjacency would only form half way but would add a route. A 50/50 chance of success was the result. - SFTOS: A Transient Parity Error crashed one of the S50's in production. No known cause. - FTOS: The switch would lock during certain ARP operations (i.e. port flap). A hard reboot was necessary to recover the switch. --snip-- - FTOS: Random reboots preceded by Low memory errors. Our design would not / could not have consumed all the switch memory. - FTOS: An upgrade from SFTOS to FTOS changes all the SNMP interface indexes causing lots of internal software to no longer be able to poll switch ports or monitor accurately. - FTOS: Hard lock of the switch after an STP root change. The root change was not seen on any other switches (i.e. another bug in the S50 code) and there were no events that should have caused a change in the topology. The E series has more stable but like I said lacking some features. The most notable is the inability to do normal PBR. Pretty much any BGP attribute can't be used to build a policy. We were forced to dedicate vlans to certain policies as they could only match the traffic via an interface. A minor annoyance is the timing for the management cpu causing ping times to look as though there is something wrong with the router. There's a paper out there somewhere explaining the cause for this and it has to do with the polling cycles of the board. A snippet of a ping to a routing interface: 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=4 ttl=252 time=0.640 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=5 ttl=252 time=5.376 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=6 ttl=252 time=12.170 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=7 ttl=252 time=1.106 ms 64 bytes from xxx.xxx.xxx.xxx: icmp_seq=8 ttl=252 time=8.089 ms 64 bytes from
