Re: ATT and having two BGP peers
Use a /30 across the circuit and do multihop BGP using other IPs. On Friday 10 July 2009 13:48:15 Jay Nakamura wrote: We are getting an Ethernet DIA circuit from ATT but they insist that they can't BGP peer with 2 routers on our side. The WAN circuit can only have /30 they say. Has anyone been able to successfully talk them in to bending their rule? If so, how? I know this should have been negotiated before signing a contract but I was unfortunately not in the loop... :( It seems like a ridiculous bureaucratic restriction.
Re: Point to Point Ethernet
My first thought was that there's really no use ripping the guts out of a protocol whose core mechanisms are aimed at dealing with the complexities of operating on a shared medium only to use it in an environment in which none of those complexities exist. But, if interfaces would be made to support both Ethernet II and some new Addressless Ethernet (or some other moniker) frames, the additional costs, real or administrative, wouldn't be outstanding. You might want to first try proving that reducing the Ethernet frame overhead by 2/3 and, in turn, reducing the average frame size by 12 / [average frame size] percent is worthwhile. Or try making the frame overhead reduction argument only a small piece of the larger argument for getting rid of multi-access cruft in point-to-point environments. But good luck pushing the principle argument of making things as simple as possible but no simpler without good technical and (hence) business cases. Stephen Kratzer Network Engineer CTI Networks, Inc. On Wednesday 08 July 2009 06:01:20 Andre Oppermann wrote: A few time already I've wished for a fully standardized and vendor interoperable way of doing a true point to point ethernet link. It would work just like an old leased line or synchronous serial interface and completely do away with ARP, MAC addresses and all that stuff. Obviously no switches in between would be allowed. Each side would run in promiscuous mode where every ethernet frame is received and passed up to the network stack (just like on a serial link). Since MAC addresses are useless they can be scrapped and only the ethertype field remains. This increases the effective MTU by 12 bytes. The framing overhead goes away and the packet can directly be directly placed on the wire without taking a detour through L3-L2 lookup and encapsulation step. More importantly one can specify the just the outgoing interface again instead of the next hop: ip route 10.0.0.0 255.0.0.0 g0/1 Do you think this is useful? Maybe vendors will hear me/us.
Re: less than a /24 BGP tricks
Neal, If your providers are doing uRPF, and it is always the case that hosts using provider A's IPs must route through provider A, and hosts using provider B's IPs must route through provider B, then why not enforce this behavior in your routing tables rather than doing PBR? From your description, it doesn't sound like you're distributing subnets across datacenters, and it's difficult to tell how, why, or if you're sharing provider routes between your routers. Stephen Kratzer Network Engineer CTI Networks, Inc. On Tuesday 30 June 2009 09:54:29 neal rauhauser wrote: I have a network with two upstreams that land in datacenters many miles apart. The hardware involved is Cisco 7507s with RSP4s and VIP4-80. I've got a curious problem which I hope others here have faced. A while ago we got a /28 from each provider and attached it to a dedicated fast ethernet interface at each location. Inbound traffic arrives normally and anything arriving on that port is policy routed to the upstream that provided the prefix. This was all well and good when it was a little firewall with a Linux machine behind it being used to check latency and do other diagnostics, but the sales people noticed it and have lined up a couple of opportunities to sell a service that would depend on our being able to receive and send traffic from blocks less than a /24. The policy routing works fine at low volume, but the RSP4 is rated to only do four megabits and I know they're going to exceed that. I can terminate this subnet on another router, wire that device into the 7507 with a crossover, and establish a BGP session. I'm wondering if there is a tidy way to set next hop in some fashion using route-maps such that all the marking would be done on the auxillary machine and the traffic passing through the 7507 would be CEF switched rather than process switched.
Re: Cogent input
Should have said And, they have no plans to deploy IPv6 in the immediate future. On Thursday 11 June 2009 10:33:25 Stephen Kratzer wrote: We've only recently started using Cogent transit, but it's been stable since its introduction 6 months ago. Turn-up was a bit rocky since we never received engineering details, and engineering was atypical in that two eBGP sessions were established, one just to advertise loopbacks, and another for the actual feed. The biggest issue we have with them is that they don't allow deaggregation. If you've been allocated a prefix of length yy, they'll accept only x.x.x.x/yy, not x.x.x.x/yy le 24. Yes, sometimes deaggregation is necessary or desirable even if only temporarily. And, they have no plans to support IPv6. Cogent's official stance on IPv6 is that we will deploy IPv6 when it becomes a commercial necessity. We have tested IPv6 and we have our plan for rolling it out, but there are no commercial drivers to spend money to upgrade a network to IPv6 for no real return on investment. Stephen Kratzer Network Engineer CTI Networks, Inc. On Thursday 11 June 2009 09:46:45 Justin Shore wrote: I'm in search of some information about Cogent, it's past, present and future. I've heard bits and pieces about Cogent's past over the years but by no means have I actively been keeping up. I'm aware of some (regular?) depeering issues. The NANOG archives have given me some additional insight into that (recurring?) problem. The reasoning behind the depeering events is a bit fuzzy though. I would be interested in people's opinion on whether or not they should be consider for upstream service based on this particular issue. Are there any reasonable mitigation measures available to Cogent downstreams if (when?) Cogent were to be depeered again? My understanding is that at least on previous depeering occasion, the depeering partner simply null-routed all prefixes being received via Cogent, creating a blackhole essentially. I also recall reading that this meant that prefixes being advertised and received by the depeering partner from other peers would still end up in the blackhole. The only solution I would see to this problem would be to shut down the BGP session with Cogent and rely on a 2nd upstream. Are there any other possible steps for mitigation in a depeering event? I also know that their bandwidth is extremely cheap. This of course creates an issue for technical folks when trying to justify other upstream options that cost significantly more but also don't have a damaging history of getting depeered. Does Cogent still have an issue with depeering? Are there any reasonable mitigation measures or should a downstream customer do any thing in particular to ready themselves for a depeering event? Does their low cost outweigh the risks? What are the specific risks? Thanks Justin
Re: Cogent input
Perhaps you missed my quote: Cogent's official stance on IPv6 is that we will deploy IPv6 when it becomes a commercial necessity. We have tested IPv6 and we have our plan for rolling it out, but there are no commercial drivers to spend money to upgrade a network to IPv6 for no real return on investment. This came rom a contact at Cogent (not sure of the role, probably sales rep). On Thursday 11 June 2009 10:49:13 Bret Clark wrote: I'm skeptical as to where this info came from since this seems nothing more then nay-say? if people are going to make grandiose statements then they should justify them with reputable evidence. I would be extremely surprised if Cogent engineering isn't working on a IPv6 plan or doesn't have one already in place. Bret On Thu, 2009-06-11 at 10:37 -0400, Steve Bertrand wrote: Stephen Kratzer wrote: And, they have no plans to support IPv6. Ouch! I hope this is a non-starter for a lot of folks. Steve
Re: Cogent input
Perhaps you missed my amendment: Should have said And, they have no plans to deploy IPv6 in the immediate future. :) On Thursday 11 June 2009 11:06:38 Bret Clark wrote: Far different response then whoever quoted...And, they have no plans to support IPv6. On Thu, 2009-06-11 at 11:03 -0400, Stephen Kratzer wrote: Perhaps you missed my quote: Cogent's official stance on IPv6 is that we will deploy IPv6 when it becomes a commercial necessity. We have tested IPv6 and we have our plan for rolling it out, but there are no commercial drivers to spend money to upgrade a network to IPv6 for no real return on investment. This came rom a contact at Cogent (not sure of the role, probably sales rep). On Thursday 11 June 2009 10:49:13 Bret Clark wrote: I'm skeptical as to where this info came from since this seems nothing more then nay-say? if people are going to make grandiose statements then they should justify them with reputable evidence. I would be extremely surprised if Cogent engineering isn't working on a IPv6 plan or doesn't have one already in place. Bret On Thu, 2009-06-11 at 10:37 -0400, Steve Bertrand wrote: Stephen Kratzer wrote: And, they have no plans to support IPv6. Ouch! I hope this is a non-starter for a lot of folks. Steve
Re: v6 DSL / Cable modems
On Friday 06 February 2009 08:51:04 Jack Bates wrote: Joe Loiacono wrote: Indeed it does. And don't forget that the most basic data object in the routing table, the address itself, is 4 times as big. Let's also not forget, that many organizations went from multiple allocations to a single allocation. If we all filter anything longer than /32, we'll rearrange the flow of traffic that many over the years have altered through longer prefixes. Even I suspect I may occasionally have to let a /40 out now and then to alter it's traffic from the rest of the aggregate. Traffic comes to you as it wants to come to you. The only pseudo remedy that currently exists is to move some prefixes over to a different path. If you only have a /32, that'll be a bit hard. This, more than anything, is what will effect this list and the people on it where IPv6 is concerned. Filtering longer than /33, 35, 40? Dare we go to /48 and treat them as the new /24? I know for myself, traffic manipulation can't begin until /40 (unless I split them further apart). Jack I think we'll see this more and more. Our newest tier-1 IPv4 transit provider was the first to tell us that they don't allow deaggregation. If we were allocated /19s, we advertise /19s... Not to start another debate, but this will certainly highlight the deficiencies of the hop-by-hop, policy-based routing paradigm that all but ignores the load-balancing needs of 95% (fictitious number) of networks operating in a world which can't load-balance itself.
Re: v6 DSL / Cable modems [was: Private use of non-RFC1918 IP space (IPv6-MW)] (IPv6-MW)
On Thursday 05 February 2009 04:31:28 Brandon Butterworth wrote: I am beginning to be worried that no one [has|is willing to divulge] that they have accomplished this . One would think that someone would at least pipe up just for the bragging factor . The thread seemed long and noisy enough already without everyone doing a me too. We did it, to see if we could and because we have like minded users wanting access. I know there are others. brandon Reading between the lines, nobody just wants to know THAT you've got it working. We want to know HOW you got it working. What protocols and policies were implemented on what hardware for what kind of user base? Stephen Kratzer Network Engineer CTI Networks, Inc.
Re:
On Monday 12 January 2009 01:11:50 Aaron Imbrock wrote: Stop in the name of love
Re: eigrp and managed ethernet
Be sure to differentiate between unicast and multicast reachability. Try 'ping 224.0.0.10'. Stephen Kratzer On Tuesday 23 September 2008 12:25:34 Philip Lavine wrote: What is really bizarre is that I am down for minutes not seconds and the timers never fire. If I don't manually passive the connection eigrp will for some reason think there is a neighbor even though I am unable to source ping across the WAN. - Original Message From: Matthew Huff [EMAIL PROTECTED] To: Philip Lavine [EMAIL PROTECTED]; nanog [EMAIL PROTECTED] Sent: Tuesday, September 23, 2008 8:59:14 AM Subject: RE: eigrp and managed ethernet Correct. Eigrp neighbor connectivity has a short-cut when L2 connectivity goes down, otherwise it will use the eigrp neighbor hold-down timer. You can decrease that timer: interface fa0/0 ip hello-interval eigrp p x ip hold-time eigrp p y where p is your eigrp as-number, and x is how often you want the hello (in seconds) and y is the max hold-down timer. Generally y is = x * 3 http://www.cisco.com/en/US/docs/ios/12_2/iproute/command/reference/1rfeigrp .html Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 www.ox.com| Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -Original Message- From: Philip Lavine [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 23, 2008 11:43 AM To: nanog Subject: eigrp and managed ethernet For some reason when I lose layer 3 connectivity between two managed Ethernet sites EIGRP does not bounce.Is this because the physical interface does not bounce?
Re: eigrp and managed ethernet
On Tuesday 23 September 2008 13:46:02 Joseph Doran wrote: EIGRP timers over WAN media default to 60 seconds. Neighborship will not expire for up to 180 seconds. To verify your EIGRP neighborship do a show ip eigrp neighbor Message: 6 Date: Tue, 23 Sep 2008 09:25:34 -0700 (PDT) From: Philip Lavine [EMAIL PROTECTED] Subject: Re: eigrp and managed ethernet To: nanog [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii What is really bizarre is that I am down for minutes not seconds and the timers never fire. If I don't manually passive the connection eigrp will for some reason think there is a neighbor even though I am unable to source ping across the WAN. With regard to EIGRP, link type is dictated by the medium and speed. In this case, Ethernet will be considered a high-speed, broadcast link regardless of its use for LAN or WAN, so the hello/dead intervals should, by default, be 5/15 seconds.
