Re: Replacement for Avaya CNA/RouteScience
imo, no more than 3-4 transit providers and maybe a presence at 1 or 2 ixp's with x amount of peer's would be small im not saying customers won't/don't care about latency, its just not difficult to route around the problematic nodes (unless SP A/B/C gets to it first and band aid the issue until resolution), maybe i just don't see enough issues to even recognize the problem? agreed, human error is a big cause of a lot of issues. well there are plenty of ways to manipulate traffic other than local_pref, that is why i find it interesting, you have options. i don't understand what the difficulty is in monitoring your bandwidth and understanding your traffic patterns, if this is done properly, you can plan capacity and execute your routing policies for optimal performance, and not have to re-route/re-engineer traffic so often. does your traffic fluctuate that much that you cant get a good grasp on what you're pushing, from who, and when? i definitely see value in appliances like the fcp and route science box, i just think for a smaller provider it may not be necessary - or maybe i have it backwards,and it is a better solution for a smaller provider so they don't have to waste money on highly skilled engineers? maybe i am just thinking "inside" the box at the moment, from an engineers view..if so my apologies for steering off course -christian On Thu, Jul 3, 2008 at 4:51 PM, Eric Van Tol <[EMAIL PROTECTED]> wrote: > >From: Christian Koch [mailto:[EMAIL PROTECTED] > >Sent: Thursday, July 03, 2008 2:39 PM > >To: Robert E. Seastrom > >Cc: Eric Van Tol; nanog@nanog.org > >Subject: Re: Replacement for Avaya CNA/RouteScience > > > >agreed. i see the most benefit from these boxes geared towards networks > >with critical apps that are latency intensive and more than a handful of > >transit providers than i do for a smaller provider.. > > Two questions: > > First, what would you characterize as a "smaller provider"? One that has > only one or two transits? If that's the case, then yes, I would definitely > agree with you. However, once you go beyond just a few transits and peers, > choosing which one to use for an unhealthy destination becomes tedious if > you're trying to do it all manually. That said, I believe there is a > stopping point at which the size of the network outgrows the need for such a > device. > > Second, can you provide an example of a network where users don't care > about latency? I can't say that I've worked on tons of networks, but if > "the internet is slow", and even though our customers may not be using the > latest in realtime streaming media protocols and apps, they notice. > > >depending on how many upstreams you're juggling, its not that hard to > >create some traffic engineering policies that can easily be modified, > >(whether by hand or you use a script with a front end that can push the > >changes for you) in order to re-route traffic in the event of issues with > >an SP network in your end to end path.. > > It *is* relatively simple to make routing changes manually, but wouldn't > you agree that human error is the cause of most outages? Even the most > skilled engineers/techs have days where their fingers are larger than > normal. These devices, at least the one we use, makes no changes to router > configurations. > > >personally i think manual traffic engineering and re-routing is one of > >the more fun parts of engineering.. > > > > > >-christian > > Yes, as long as the problem is interesting. Manually changing localpref on > a route because of packet loss in someone else's network, several times per > week, is not interesting to me or my staff. Nor is checking every transit > link several times a day to make sure that we're not going over a commit > when other transits have plenty of bandwidth to spare. > > In my opinion, most of the value of these types of appliances is to help > identify problem areas outside of your network, before end users notice > them. I know firsthand that our route optimization appliance frees up my > staff to work on other issues such as capacity planning, new service > deployments, or discussing the latest MGS4 strategies. Well, hopefully not > that last one. > > -evt > > > -- ^christian$
RE: Replacement for Avaya CNA/RouteScience
>From: Christian Koch [mailto:[EMAIL PROTECTED] >Sent: Thursday, July 03, 2008 2:39 PM >To: Robert E. Seastrom >Cc: Eric Van Tol; nanog@nanog.org >Subject: Re: Replacement for Avaya CNA/RouteScience > >agreed. i see the most benefit from these boxes geared towards networks >with >critical apps that are latency intensive and more than a handful of >transit >providers than i do for a smaller provider.. Two questions: First, what would you characterize as a "smaller provider"? One that has only one or two transits? If that's the case, then yes, I would definitely agree with you. However, once you go beyond just a few transits and peers, choosing which one to use for an unhealthy destination becomes tedious if you're trying to do it all manually. That said, I believe there is a stopping point at which the size of the network outgrows the need for such a device. Second, can you provide an example of a network where users don't care about latency? I can't say that I've worked on tons of networks, but if "the internet is slow", and even though our customers may not be using the latest in realtime streaming media protocols and apps, they notice. >depending on how many upstreams you're juggling, its not that hard to >create >some traffic engineering policies that can easily be modified, >(whether by >hand or you use a script with a front end that can push the >changes for you) >in order to re-route traffic in the event of issues with >an SP network in >your end to end path.. It *is* relatively simple to make routing changes manually, but wouldn't you agree that human error is the cause of most outages? Even the most skilled engineers/techs have days where their fingers are larger than normal. These devices, at least the one we use, makes no changes to router configurations. >personally i think manual traffic engineering and re-routing is one of >the >more fun parts of engineering.. > > >-christian Yes, as long as the problem is interesting. Manually changing localpref on a route because of packet loss in someone else's network, several times per week, is not interesting to me or my staff. Nor is checking every transit link several times a day to make sure that we're not going over a commit when other transits have plenty of bandwidth to spare. In my opinion, most of the value of these types of appliances is to help identify problem areas outside of your network, before end users notice them. I know firsthand that our route optimization appliance frees up my staff to work on other issues such as capacity planning, new service deployments, or discussing the latest MGS4 strategies. Well, hopefully not that last one. -evt
Re: Replacement for Avaya CNA/RouteScience
agreed. i see the most benefit from these boxes geared towards networks with critical apps that are latency intensive and more than a handful of transit providers than i do for a smaller provider.. depending on how many upstreams you're juggling, its not that hard to create some traffic engineering policies that can easily be modified, (whether by hand or you use a script with a front end that can push the changes for you) in order to re-route traffic in the event of issues with an SP network in your end to end path.. personally i think manual traffic engineering and re-routing is one of the more fun parts of engineering.. -christian On Thu, Jul 3, 2008 at 12:50 PM, Robert E. Seastrom <[EMAIL PROTECTED]> wrote: > > Eric Van Tol <[EMAIL PROTECTED]> writes: > > > I'd like to hire that engineer, please. Can you send me his resume? > > Here's the job description: > > > > - Required to works 24x7x365. > > - Must monitor all network egress points to examine latency, > retransmissions, packet loss, link utilization, and link cost. > > - Required to "tweak localpref" on an average of 5000 prefixes per day, > based upon a combination of the above criteria. > > - Required to write up a daily, weekly, and monthly report to be sent to > all managers on said schedule. > > - Must not require health or dental care. > > > > These devices are not a replacement for an actual engineer. They > > are a supplement to the network to assist the engineer in doing what > > he should be doing - engineering and planning as opposed to > > resolving some other network's packet loss/blackhole/peering > > dispute/latency problem. > > You can certainly get close to the requirements stated above by > offering a decent salary and hiring a reasonably clued engineer with > an SP background. You may have to settle for IRC, WoW, or SecondLife > as daily recreational activity that doesn't buy you much (expressed in > your requirements list as "tweaking localpref"). > > My general experience with such boxes is that they're awfully good at > impressing the PHBs, but not something you can really defend from a > cost/benefit perspective. I really do need to go into the "custom > painted boxes with LCD screens on the front" business. I could make > "melons", like Tom Vu. > >---Rob > > > -- ^christian$
Re: IPv6 Prefix Policy
Leo Bicknell wrote: In a message written on Thu, Jul 03, 2008 at 04:55:37PM +0200, Jeroen Massar wrote: In general though, ASNs are following: http://www.space.net/~gert/RIPE/ipv6-filters.html I don't know how common the strict/non-strict case is though, but looking at GRH (http://www.sixxs.net/tools/grh/) it seems that most ASN's are properly filtering, thus using the strict model. The strict filter is still broken in at least one way. Then mail Gert Doering about it, if he doesn't know he can't update it ;) ipv6 prefix-list ipv6-ebgp-strict permit 2001:500::/30 ge 48 le 48 http://www.arin.net/reference/micro_allocations.html Note that there are /45's, /46's, /47's and /48's right now. The filter allows only /48's. Of note, this will break access to the F-Root name server, we announce it from both a /47 and a /48 (local peers only) in IPv6. I believe there are other issues with the strict filter, but don't have the time to track them down right now. If you have them, please pass them on to Gert and possibly also spam ipv6-ops. Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: Replacement for Avaya CNA/RouteScience
Eric Van Tol <[EMAIL PROTECTED]> writes: > I'd like to hire that engineer, please. Can you send me his resume? > Here's the job description: > > - Required to works 24x7x365. > - Must monitor all network egress points to examine latency, > retransmissions, packet loss, link utilization, and link cost. > - Required to "tweak localpref" on an average of 5000 prefixes per day, > based upon a combination of the above criteria. > - Required to write up a daily, weekly, and monthly report to be sent to all > managers on said schedule. > - Must not require health or dental care. > > These devices are not a replacement for an actual engineer. They > are a supplement to the network to assist the engineer in doing what > he should be doing - engineering and planning as opposed to > resolving some other network's packet loss/blackhole/peering > dispute/latency problem. You can certainly get close to the requirements stated above by offering a decent salary and hiring a reasonably clued engineer with an SP background. You may have to settle for IRC, WoW, or SecondLife as daily recreational activity that doesn't buy you much (expressed in your requirements list as "tweaking localpref"). My general experience with such boxes is that they're awfully good at impressing the PHBs, but not something you can really defend from a cost/benefit perspective. I really do need to go into the "custom painted boxes with LCD screens on the front" business. I could make "melons", like Tom Vu. ---Rob
RE: Replacement for Avaya CNA/RouteScience
> -Original Message- > From: Paul Wall [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 03, 2008 11:25 AM > To: Drew Weaver > Cc: nanog@nanog.org > Subject: Re: Replacement for Avaya CNA/RouteScience > > Going off this and previous posts, you'd well-served to follow the > advice you sarcastically dispense, and hire an engineer. > > Opex and capex (spread over a ~2 year product lifetime) costs for the > above solutions in a small (several gigabits, several transit > providers) environment are right up there with the salary of a junior > to mid-level networking professional in most markets. By hiring a > live human, you get not only somebody who can tweak localpref, but > also a critical thinker who can aid in troubleshooting outages and > help you plan for growth. > > Paul I'd like to hire that engineer, please. Can you send me his resume? Here's the job description: - Required to works 24x7x365. - Must monitor all network egress points to examine latency, retransmissions, packet loss, link utilization, and link cost. - Required to "tweak localpref" on an average of 5000 prefixes per day, based upon a combination of the above criteria. - Required to write up a daily, weekly, and monthly report to be sent to all managers on said schedule. - Must not require health or dental care. These devices are not a replacement for an actual engineer. They are a supplement to the network to assist the engineer in doing what he should be doing - engineering and planning as opposed to resolving some other network's packet loss/blackhole/peering dispute/latency problem. -evt
RE: Replacement for Avaya CNA/RouteScience
what does vyatta have to do with route intelligence/optimization? vyatta is just a router.. -c -Original Message- From: Michienne Dixon [mailto:[EMAIL PROTECTED] Sent: Thu 07/03/08 10:36 AM To: nanog@nanog.org Subject: RE: Replacement for Avaya CNA/RouteScience Have you considered any of the options from Vyatta? Aside from the "roll your own" community offerings they also have a precompiled virtual appliance as well as a physical appliance you can use. - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 -Original Message- From: Drew Weaver [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2008 6:51 AM To: nanog@nanog.org Subject: Replacement for Avaya CNA/RouteScience Howdy for reasons it might be inappropriate to discuss on this list we've decided that we're going to replace our Avaya/RouteScience box and we're looking for recommendations on different solutions for 'BGP management appliances'. We're aware of the Internap FCP product, but is there anything else out there besides 'oy, hire a BGP admin ya tool!' that anyone can offer? As always, comments are appreciated. -Drew QUALITY TECHNOLOGY SERVICES CONFIDENTIALITY NOTICE: This e-mail message including its attachments is classified COMPANY CONFIDENTIAL. It is intended for the person or entity to which it is addressed and may contain confidential material. Quality Technology Services controls the distribution of COMPANY CONFIDENTIAL assets, as such, any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact us at [EMAIL PROTECTED] or 866-239-5000 and destroy all copies of the original message. Thank you.
Re: Replacement for Avaya CNA/RouteScience
On Thu, Jul 3, 2008 at 7:50 AM, Drew Weaver <[EMAIL PROTECTED]> wrote: >Howdy for reasons it might be inappropriate to discuss on this list > we've decided that we're going to replace our Avaya/RouteScience box and > we're looking for recommendations on different solutions for 'BGP management > appliances'. > >We're aware of the Internap FCP product, but is there anything else > out there besides 'oy, hire a BGP admin ya tool!' that anyone can offer? Going off this and previous posts, you'd well-served to follow the advice you sarcastically dispense, and hire an engineer. Opex and capex (spread over a ~2 year product lifetime) costs for the above solutions in a small (several gigabits, several transit providers) environment are right up there with the salary of a junior to mid-level networking professional in most markets. By hiring a live human, you get not only somebody who can tweak localpref, but also a critical thinker who can aid in troubleshooting outages and help you plan for growth. Paul
Re: IPv6 Prefix Policy
In a message written on Thu, Jul 03, 2008 at 04:55:37PM +0200, Jeroen Massar wrote: > In general though, ASNs are following: > http://www.space.net/~gert/RIPE/ipv6-filters.html > > I don't know how common the strict/non-strict case is though, but > looking at GRH (http://www.sixxs.net/tools/grh/) it seems that most > ASN's are properly filtering, thus using the strict model. The strict filter is still broken in at least one way. ipv6 prefix-list ipv6-ebgp-strict permit 2001:500::/30 ge 48 le 48 http://www.arin.net/reference/micro_allocations.html Note that there are /45's, /46's, /47's and /48's right now. The filter allows only /48's. Of note, this will break access to the F-Root name server, we announce it from both a /47 and a /48 (local peers only) in IPv6. I believe there are other issues with the strict filter, but don't have the time to track them down right now. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgp3oDkx8j12m.pgp Description: PGP signature
Re: IPv6 Prefix Policy
Frank P. Troy wrote: Hi, Can someone point me to the latest information on the minimum IPv6 prefix providers will accept for Provider Independent IPv6 prefixes? Ask the providers directly, it is their network thus they will have their own policies. In general though, ASNs are following: http://www.space.net/~gert/RIPE/ipv6-filters.html I don't know how common the strict/non-strict case is though, but looking at GRH (http://www.sixxs.net/tools/grh/) it seems that most ASN's are properly filtering, thus using the strict model. Of course don't forget to signup for GRH if you are going to/are participating in the IPv6 BGP and also of course sign up to ipv6-ops to keep informed about technical issues (SnR is quite high fortunately): http://lists.cluenet.de/pipermail/ipv6-ops Greets, Jeroen signature.asc Description: OpenPGP digital signature
IPv6 Prefix Policy
Hi, Can someone point me to the latest information on the minimum IPv6 prefix providers will accept for Provider Independent IPv6 prefixes? Thanks Frank Frank P. Troy 703-396-8700 [EMAIL PROTECTED] -
Re: RIPE NCC will begin allocating from 188/8
Not sure if RIPE knows this, but the following url will give you a list of RIPE allocations, many /20s, /17s and /16s which are either hijacked or allocated directly to illegal spam operations (who have obviously faked the RIPE application as 'ISPs' to get huge allocations)... http://www.spamhaus.org/sbl/listings.lasso?isp=RIPE Direct RIPE allocations to many of these outfits, including "Russian Business Network" (the Russian Cybercrime Mob) for example are allocations we would love to see reclaimed asap. Regards, Steve Linford The Spamhaus Project http://www.spamhaus.org On 3 Jul 2008, at 12:25, Alex Le Heux wrote: Dear Colleagues, The IANA and the RIRs are working on an ongoing basis to verify and correct registration data of legacy address space to identify free space in these blocks.
RE: Replacement for Avaya CNA/RouteScience
Have you considered any of the options from Vyatta? Aside from the "roll your own" community offerings they also have a precompiled virtual appliance as well as a physical appliance you can use. - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 -Original Message- From: Drew Weaver [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2008 6:51 AM To: nanog@nanog.org Subject: Replacement for Avaya CNA/RouteScience Howdy for reasons it might be inappropriate to discuss on this list we've decided that we're going to replace our Avaya/RouteScience box and we're looking for recommendations on different solutions for 'BGP management appliances'. We're aware of the Internap FCP product, but is there anything else out there besides 'oy, hire a BGP admin ya tool!' that anyone can offer? As always, comments are appreciated. -Drew
Replacement for Avaya CNA/RouteScience
Howdy for reasons it might be inappropriate to discuss on this list we've decided that we're going to replace our Avaya/RouteScience box and we're looking for recommendations on different solutions for 'BGP management appliances'. We're aware of the Internap FCP product, but is there anything else out there besides 'oy, hire a BGP admin ya tool!' that anyone can offer? As always, comments are appreciated. -Drew
tacid.org
Greetings, My name is Nick, and I have inherited admin duties for tacid.org. For an un-known amount of time (A month or more?) mail.tacid.org has been an open-relay, and sending out large amounts of spam. This should now be fixed. If anyone is having issues with this domain still, please contact me off list. Thank you, Nick
RIPE NCC will begin allocating from 188/8
Dear Colleagues, The IANA and the RIRs are working on an ongoing basis to verify and correct registration data of legacy address space to identify free space in these blocks. As a result of this work the RIPE NCC will begin allocating from 188/8 in future. The minimum allocation size for 188/8 has been set at /21. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found at: https://www.ripe.net/ripe/docs/ripe-434.html Please also note that three "pilot" prefixes will be announced from 188/8. These prefixes are: 188.0.0.0/16 188.0.0.0/21 188.0.0.0/24 They will all originate in AS12654. The following pingable addresses will available in these blocks: 188.0.8.1 188.0.1.1 188.0.0.1 More information on this "pilot" activity is available in the document "De-Bogonising New Address Blocks", which can be found at: http://www.ripe.net/ripe/docs/ripe-351.html Best regards, Alex Le Heux RIPE NCC
