Re: Reduced ISP uptime after BGP annoucement
Dylan Ebner wrote: Does anyone know if it is the policy of Qwest (or ISPs) to have lower uptime metrics for BGP customers or am I just experiancing lots of downtime with an ISP that is known for having lots of problems? We do BGP to Qwest Internet and they've been as reliable as any other provider over the long haul. There have been 1-2 outages impacting our ELA in the last year - one of which was big enough to take down our MOE services across the state. I can't imagine a good reason to give lower metrics to our BGP customers. We assume the customers who want BGP really value their uptime moreso than others because they are investing more money in it. Now if I have an outage and limited staff to do client contact notifications, we'll call the BGP customers last since they are least affected. But that's about it as far as discriminatory treatment goes. Mike
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: less than a /24 BGP tricks
On Tue, Jun 30, 2009 at 9:54 AM, neal rauhausernrauhau...@gmail.com 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. [snip] 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. I hope the NANOG list can forgive me replying--I have a soft spot for 7500's. A few things to check on your box before giving up: -if you don't need v6 or mpls, run the most recent 12.0S code available - cef-switched policy based routing (which I'm not convinced is required to do what you describe) has been part of 12.0 feature set since its inception. Weather it works or not due to regressions is another story. http://www.cisco.com/en/US/docs/ios/12_0/qos/configuration/guide/qcpolicy.html -12.4 main works well enough, adds mpls p/pe and ipv6 in cef -ip cef distributed (make sure it's enabled, regardless of the IOS version) Another suggestion is to place customers into their own unique interface (i.e. sub-interface vlan, etc), and simply bind this customer to a VRF corresponding to the provider they expect/wish/etc to egress. -tk
draft-scholl-idr-advisory
Folks, At our Philadelphia meeting, the operator community displayed strong support for IETF draft-scholl-idr-advisory. This draft describes a BGP extension for passing free-form advisory messages between peers. The IDR WG is split regarding this draft, with enthusiasm waning. I am about to post a message to the IDR mailing list in support of this draft and would for those of you who support the draft to do likewise. In order to subscribe to the IDR WG mailing list, send a subscription request to idr-requ...@ietf.org. The subject of the messages should be subscribe. thanks, Ron
Re: Telephones for Noisy Data Centers
Not 100% what you asked for, but the noise cancelling Jawbone bluetooth earpieces are great. Cordless phone that does bluetooth + jawbone was the first thing that popped into my head as well. Jawbone good. Jawbone + http://www.averysound.com/ outstanding. -r
Nanog Webcast Equipment
Hello There, I was hoping someone from the NANOG team could comment on what equipment/software they use for the live meeting broadcasts. I am looking to do the same for another professional association and could use some pointers. You can reply off-list if you wish. -Israel
Re: Nanog Webcast Equipment
You can reply off-list if you wish. Would love to see replies and/or summary on list if possible. It's a somewhat complex problem, and there are many solutions out there. Having feedback on what was used and any feedback on it would be great!
