Flowspec Implementation on Cisco ASR

Hi Folks, Has anyone implemented flowspec on Cisco ASR terminating PPPoE users. Flowspec rules should apply to the addresses assigned to PPPoE customers. If yes, kindly share configuration samples.. Regards Paschal Masha

Re: Flowspec IPv6

ric, > > with no v6 fs rules, the table inet6flow.0 stay hidden. Try to make any. > > -- > S pozdravem/Best Regards, > Zbyněk > > > > Dne 21.05.21 v 20:10 Eric Dugas via NANOG napsal(a): > > Hello, > > > > I've been fiddling with JunOS to enable Flowspec IPv6. Ac

Re: Flowspec IPv6

Hi, I just configured this a few days ago on a mx960 running 18.4R3. This was traffic redirection into a routing-instances so i do not know if it matches your setup. But i can confirm that it is working in my setup. Regards Trond Hello, I've been fiddling with JunOS to enable Flowspec

Re: Flowspec IPv6

Hi Eric, with no v6 fs rules, the table inet6flow.0 stay hidden. Try to make any. -- S pozdravem/Best Regards, Zbyněk Dne 21.05.21 v 20:10 Eric Dugas via NANOG napsal(a): > Hello, > > I've been fiddling with JunOS to enable Flowspec IPv6. According to the > docs, it was impleme

Flowspec IPv6

Hello, I've been fiddling with JunOS to enable Flowspec IPv6. According to the docs, it was implemented in 16.x. I've tried to set it up in vRR and vMX in the 20.x train. Everything commit just fine, I get the inetflow.0 for IPv4 but inet6flow.0 is not appearing. I already have a JTAC case (now

Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over

NANOG namens Douglas Fischer Verzonden: woensdag 3 februari 2021 10:59 Aan: Hank Nussbacher CC: NANOG Onderwerp: Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over Yep... But I remember the first concept of security: There is no real security on a single laye

Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over

of the listed versions, AND they have flowspec enabled, there is exposure. On Wed, Feb 3, 2021 at 5:32 AM Jean St-Laurent via NANOG wrote: > Interesting, > > > > Do I read it right that there is no workaround, but the solution is to > upgrade to an updated version which include the

Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over

On Feb 3, 2021, at 17:01, Douglas Fischer wrote: It should be announced to another box, running other software than that one on the Perimeter, and filtering and refiltering should be done on both layers. This is how the inter-operator implementations of which I'm aware function, via a

Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over

In this case, in my opinion, I saw as the best scenario the FlowSpec Rules being announced from ASN-Customer to ASN-Flowspec-Enforcer - Not on a BGP Border of ASN-Flowspec-Enforcer. - But on a Central RR-Cluster of ASN-Flowspec-Enforcer. Em qua., 3 de fev. de 2021 às 07:36, Peter F. de Boer

RE: RTBH and Flowspec Measurements - Stop guessing when the attack will over

s://ddostest.me/> https://ddostest.me email: <mailto:j...@ddostest.me> j...@ddostest.me From: NANOG On Behalf Of Hank Nussbacher Sent: February 3, 2021 12:41 AM To: nanog@nanog.org Subject: Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over

Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over

Yep... But I remember the first concept of security: There is no real security on a single layer. So, considering That, FlowSpec should never be accepted directly by the FlowSpec-Enforcer-Box. It should be announced to another box, running other software than that one on the Perimeter

Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over

this as an $extra$. About the "Please break me at my earliest inconvenience." part: I believe that the same type of prefix filtering that applies to Downstream-BGP-Routes applies to RTBH and Flowspec. So, exactly as in common BGP Route

Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over

1, > that sells this as an $extra$. > > About the "Please break me at my earliest inconvenience." part: > I believe that the same type of prefix filtering that applies to > Downstream-BGP-Routes applies to RTBH and Flowspec. > So, exactly as in common BGP Route-Filtering:

Re: [EXTERNAL] Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over

omp...@charter.com> escreveu: > Hi, here is a Flowspec best practices document that I helped write that > will hopefully help folks from shooting themselves in the foot > http://m3aawg.org/flowspec-BP. As you stated, route policies can be > applied to restrict what type of flowspec

Re: [EXTERNAL] Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over

Hi, here is a Flowspec best practices document that I helped write that will hopefully help folks from shooting themselves in the foot http://m3aawg.org/flowspec-BP. As you stated, route policies can be applied to restrict what type of flowspec rules can or can’t be accepted. For example

Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over

at applies to Downstream-BGP-Routes applies to RTBH and Flowspec. So, exactly as in common BGP Route-Filtering: - If the network operator does it correctly, it should work correctly. - If the network operator deals with that without the needed skills, expertise, attention+devotion, wrong things wi

Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over

Personally, I would absolutely, positively, never ever under any circumstances provide access to a 3rd party company to push a FlowSpec rule or trigger RTBH on my networks. No way. You would be handing over a nuclear trigger and saying "Please break me at my earliest inconvenience." O

Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over

OK, but do you know any company the sells de Flowspec as a service, in the way that the Attack Identifications are not made by their equipment, just receiving de BGP-FlowSpec and applying that rules on that equipments... And even then give back to the customer some way to access those statistics

Re: RTBH and Flowspec Measurements - Stop guessing when the attack will over

tion/classification/traceback. It's also possible to combine the detection/classification/traceback & flowspec trigger functions. [Full disclosure: I work for a vendor of such systems.] Roland Dobbins

RTBH and Flowspec Measurements - Stop guessing when the attack will over

I think most here know (way better than me) the concepts of DDoS, anomaly detection, and reactions. Some of the reactions that can be implemented to reduce the impact of an attack are Remote-Triggered BlackHole and FlowSpec Filtering. In theory, using FlowSpec would be possible to de source

Re: BGP FLowspec to Yang/Yaml ACL

#WlXYkcfATNRxpRcr4NGOtxw4cqzStbCpApxmIevRPDk= There's a lot more you could do to make this even more flexible, you don't need YANG or to modify any config, just build something that accepts what you're after and sends it as flowspec routes from ExaBGP to the routers you care about. -- Tim On Tue, Jun 16, 2020 at 1:46 PM

RE: BGP FLowspec to Yang/Yaml ACL

it into the pre-defined/prepared template (yang/ansible template), then the script just prompts the resulting config to be pushed onto the device (devices). adam From: NANOG On Behalf Of Douglas Fischer Sent: Tuesday, June 16, 2020 7:40 PM To: nanog@nanog.org Subject: BGP FLowspec to Yang

Re: BGP FLowspec to Yang/Yaml ACL

Just a complementary demonstration of a cenário we this "bgpfs2acl" been used. https://youtu.be/8pNZJUHlRPk Em ter., 16 de jun. de 2020 às 15:39, Douglas Fischer < fischerdoug...@gmail.com> escreveu: > We were looking for some way to implement BGP Flowspec Filtering(just the

BGP FLowspec to Yang/Yaml ACL

We were looking for some way to implement BGP Flowspec Filtering(just the permit/deny basic) using L3 switches in an automated way. Searching a bit we found https://github.com/ios-xr/bgpfs2acl Is almost what we are looking for! But is focused on Cisco devices. We even considered fork it to our

RE: [EXTERNAL] Re: FlowSpec

If you can impose a limit on the amount of flowspec rules the customer can send you (I assume you are the Service provider) where is the problem with offering flowspec services? Seems more of a vendor challenge. The tcam issue is relatively addressed with proper dimensioning (throw money

Re: FlowSpec

On 2020-04-23 19:12, Roland Dobbins wrote: On 23 Apr 2020, at 22:57, Denys Fedoryshchenko wrote: In general operators don't like flowspec Its increasing popularity tens to belie this assertion. Yes, you're right that avoiding overflowing the TCAM is very important. But as Rich notes

Re: FlowSpec

On 23 Apr 2020, at 22:57, Denys Fedoryshchenko wrote: In general operators don't like flowspec Its increasing popularity tens to belie this assertion. Yes, you're right that avoiding overflowing the TCAM is very important. But as Rich notes, a growing number of operators are in fact

Re: FlowSpec

On 2020-04-23 18:13, Colton Conor wrote: Do any of the large transit providers support FlowSpec to transit customers / other carriers, or is that not a thing since they want to sell DDoS protection services? FlowSpec sounds much better than RTBH (remotely triggered blackhole), but I am not sure

Re: FlowSpec

On 2020-04-23 18:13, Colton Conor wrote: Do any of the large transit providers support FlowSpec to transit customers / other carriers, or is that not a thing since they want to sell DDoS protection services? FlowSpec sounds much better than RTBH (remotely triggered blackhole), but I am not sure

Re: FlowSpec

Hi Colton, It is fairly common to use flowspec internally at an ISP for mitigation of DDoS attacks. eBGP flowspec is not very common though. I know of only a couple of ISPs that allow flowspec rules to be advertised by their customers. The biggest issue with this is that other providers

FlowSpec

Do any of the large transit providers support FlowSpec to transit customers / other carriers, or is that not a thing since they want to sell DDoS protection services? FlowSpec sounds much better than RTBH (remotely triggered blackhole), but I am not sure if FlowSpec is widely implemented. I see

Any IP Transit provider currently offering BGP FlowSpec?

Hello, I'm looking for an IP Transit provider (in the Americas region preferrably) that provides BGP FlowSpec capabilities. I've found some that accept filtering rules at the IP Transit level but changes are done by support ticket, which is subpar to me. I must have autonomy to change rules

Re: FlowSpec Support

on the Baker's Dozen? Wide-spread POPs on six continents? Showing up on 50 IXPs? 1k IPv4 adjacencies? A medium sized network that does FlowSpec could be vastly more useful to you than a large network that doesn't. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest

Re: FlowSpec Support

ng networks. I know it isn't > on all hardware, but does appear to be on at least a couple platforms from > the major router vendors. It is supported on an increasing number of DDoS > appliances and software packages. > > What all networks support receiving BGP FlowSpec informatio

FlowSpec Support

BGP FlowSpec information from customers and acting upon it? - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com

Re: BGP FlowSpec

On 3 May 2016, at 5:38, Martin Bacher wrote: Let the packets come is not the message. That was *precisely* the message which was spoken to me directly by a large regional CONUS ISP in mid-2003 or thereabouts. I know this; I was there. And it was the wrong message, as that particular ISP

Re: BGP FlowSpec

> Am 03.05.2016 um 00:06 schrieb Roland Dobbins <rdobb...@arbor.net>: > > On 3 May 2016, at 4:51, jim deleskie wrote: > >> I was going to avoid this thread because I've never been a huge fan of >> Flowspec for my own reasons. > > Flowspec is an ex

Re: BGP FlowSpec

> Am 02.05.2016 um 23:51 schrieb jim deleskie <deles...@gmail.com>: > > I was going to avoid this thread because I've never been a huge fan of > Flowspec for my own reasons. However having work on /been responsible for > several "Tier 1 and 2" networks and DDoS mi

Re: BGP FlowSpec

> Am 02.05.2016 um 23:38 schrieb Roland Dobbins : > > On 2 May 2016, at 20:16, Martin Bacher wrote: > >> However, Tier 1s and most probably also some of the Tier 2s may not want to >> offer it to customers because they are loosing money if less traffic is sent >>

Re: BGP FlowSpec

On 3 May 2016, at 4:51, jim deleskie wrote: I was going to avoid this thread because I've never been a huge fan of Flowspec for my own reasons. Flowspec is an extremely useful tool, IMHO - not only for direct, layer-4-granular mitigation leveraging linecard ASICs, but for more granular

Re: BGP FlowSpec

I was going to avoid this thread because I've never been a huge fan of Flowspec for my own reasons. However having work on /been responsible for several "Tier 1 and 2" networks and DDoS mitigation services over the last 20 years, I can say I, nor any of my peers ( in any sense of

Re: BGP FlowSpec

On 2 May 2016, at 20:16, Martin Bacher wrote: However, Tier 1s and most probably also some of the Tier 2s may not want to offer it to customers because they are loosing money if less traffic is sent downstream on IP-Transit links. I will go a step further than Danny's comments and state

Re: BGP FlowSpec

On 2016-05-02 09:16 AM, Martin Bacher wrote: I mainly agree on that. However, I have not found evidence of inter-AS S-RTBH deployments as of now. This would really require, at least in my understanding, a lot of hacks in order to implement it properly and avoid blackholing of the wrong

Re: BGP FlowSpec

for me to filter is at my ingress. Of course I'd rather have something akin to inter-domain pushback or FlowSpec, etc.. But you can't control how, or assume others will act on that. -danny

Re: BGP FlowSpec

> Am 02.05.2016 um 15:03 schrieb Alexander Maassen : > > On Mon, May 2, 2016 2:30 pm, Danny McPherson wrote: >> We use it effectively in a layered model where "Principle of Minimal >> Intervention" applies, allowing attack mitigation and traffic diversion >> in the most

Re: BGP FlowSpec

+1 I use this to block all kinds of unwanted traffic (with prejudice, of course). > On 1 May 2016, at 11:56 AM, Roland Dobbins wrote: > >> On 30 Apr 2016, at 19:56, Pierre Lamy wrote: >> >> to null out the destination rather than the source. > >

Re: BGP FlowSpec

w it usually starts. ;) > > > Given that I may be the guilty one here, I thought it might be worth chiming > in. > > Inter-AS FlowSpec largely met the same fate as inter-AS source-based RTBH, > where upstreams would only want to permit you to block sources destined for &

Re: BGP FlowSpec

On Mon, May 2, 2016 2:30 pm, Danny McPherson wrote: > We use it effectively in a layered model where "Principle of Minimal > Intervention" applies, allowing attack mitigation and traffic diversion > in the most optimal place (e.g., at network ingress), and only scrubbing > or diverting traffic

Re: BGP FlowSpec

On 2016-04-28 02:31 AM, Martin Bacher wrote: Literally the only people who were interested in it at the time was one of the spec's co-authors. :-) That’s how it usually starts. ;) Given that I may be the guilty one here, I thought it might be worth chiming in. Inter-AS FlowSpec

Re: BGP FlowSpec

On 30 Apr 2016, at 19:56, Pierre Lamy wrote: > to null out the destination rather than the source. --- Roland Dobbins

Re: BGP FlowSpec

I was looking into using this mechanism for blocking DDoS on Juniper devices, but at the time, they only supported 8k flowspec entries/routes and this was not sufficient to deal with the problem. My fallback was to poison the routing table with null routes, but the problem

Re: BGP FlowSpec

/ Sent via the Samsung GALAXY S® 5, an AT 4G LTE smartphone Original message From: Martin Bacher <ti14m...@technikum-wien.at> Date: 4/29/2016 2:02 AM (GMT-08:00) To: Tyler Haske <tyler.ha...@gmail.com> Cc: NANOG list <nanog@nanog.org> Subject: Re: BGP Flow

Re: BGP FlowSpec

Hello Tyler, thanks for your reply. > Am 28.04.2016 um 17:37 schrieb Tyler Haske : > > Martin, > > > > Last but not least: I am also looking for anonymized statistical data about > > DDoS attacks which I could use in the thesis. I am mainly interested in > > data

Re: BGP FlowSpec

> Am 27.04.2016 um 18:09 schrieb Hank Nussbacher <h...@efes.iucc.ac.il>: > > On 27/04/2016 18:58, John Kristoff wrote: >> On Thu, 21 Apr 2016 09:46:13 +0200 >> Martin Bacher <ti14m...@technikum-wien.at> wrote: >> >>> - Intra-AS BGP FlowSp

Re: BGP FlowSpec

> Am 27.04.2016 um 17:58 schrieb John Kristoff <j...@cymru.com>: > > On Thu, 21 Apr 2016 09:46:13 +0200 > Martin Bacher <ti14m...@technikum-wien.at> wrote: > >> - Intra-AS BGP FlowSpec deployment: Who is running it? For which kind >> of attacks are you

Re: BGP FlowSpec

On 27/04/2016 18:58, John Kristoff wrote: > On Thu, 21 Apr 2016 09:46:13 +0200 > Martin Bacher <ti14m...@technikum-wien.at> wrote: > >> - Intra-AS BGP FlowSpec deployment: Who is running it? For which kind >> of attacks are you using it? Are you only dropping or rate-

Re: BGP FlowSpec

On Thu, 21 Apr 2016 09:46:13 +0200 Martin Bacher <ti14m...@technikum-wien.at> wrote: > - Intra-AS BGP FlowSpec deployment: Who is running it? For which kind > of attacks are you using it? Are you only dropping or rate-limiting > certain traffic or are you also using the

BGP FlowSpec

Dear Nanog Members, My name is Martin Bacher. I am a Student at UAS Technikum-Wien and I am currently writing my master’s thesis with topic "Addressing DDoS Attacks with BGP FlowSpec“. It would be very helpful for me if some of you could share information about the following topics: -

BGP Flowspec Survey

Hey Everyone, I am looking to get feedback from the community on BGP Flowspec for an upcoming presentation... https://www.surveymonkey.com/s/RZYQ23S https://www.surveymonkey.com/s/RZYQ23S Feel free to forward this to any contacts you may have that are not on the NANOG list. Obviously

upstream support for flowspec

I was perusing RFC5575 after reading a presentation that ALU did (presumably during some previous NANOG conference). Reference: https://www.nanog.org/sites/default/files/wed.general.trafficdiversion.serodio.10.pdf This seems like it would be a godsend for small operators like myself who don't

Re: upstream support for flowspec

On Thu, 18 Sep 2014 13:53:52 -0400 Daniel Corbe co...@corbe.net wrote: Is there anything in the air about widening the adoption base? Cisco? Brocade? I've seen some suggesting that increased support, but even at Juniper, actions seem to speak larger than words. There seems to be very little

Re: upstream support for flowspec

On Thu, Sep 18, 2014 at 1:53 PM, Daniel Corbe co...@corbe.net wrote: And once that happens, what are the chances of services providers adopting this for their customers to make use of on as wide of a scale as (for example) blackhole community strings. I'd certainly *love* to have a way to

Re: upstream support for flowspec

Envoyé de mon iPhone Le 18 sept. 2014 à 19:53, Daniel Corbe co...@corbe.net a écrit : I was perusing RFC5575 after reading a presentation that ALU did (presumably during some previous NANOG conference). Reference:

Re: upstream support for flowspec

support are the 7750-SR and platforms made by Juniper. Cisco IOS-XR supports flowspec today as well. How much more would you pay per Mbps/month to have operator offer flowspec? IP transit is quite low margin product, supporting flowspec may have some adverse effects to business case: a) you're paying

Re: upstream support for flowspec

the only platforms that offer support are the 7750-SR and platforms made by Juniper. Cisco IOS-XR supports flowspec today as well. How much more would you pay per Mbps/month to have operator offer flowspec? IP transit is quite low margin product, supporting flowspec may have some adverse

Re: upstream support for flowspec

supports flowspec today as well. How much more would you pay per Mbps/month to have operator offer flowspec? IP transit is quite low margin product, supporting flowspec may have some adverse effects to business case: a) you're paying less, as you're not receiving the traffic This ventures

Re: upstream support for flowspec

On Thu, Sep 18, 2014 at 03:15:41PM -0400, Daniel Corbe wrote: Also, if I'm buying full line rate commit from you then you're not actually losing any money on the deal whether or not you route me the traffic. Ha, I wish all customers would buy in full line rate commits! :-) - Job

Re: upstream support for flowspec

because we filter we can't bill. Would you be willing to pay a premium to be able to do so? Is it worth a premium to insert ACLs in real time in the upstream's network or is a 2 hour delay acceptable? what about 5 minute delay? Aside from practical issues with flowspec as Ytti mentioned already, I

Re: upstream support for flowspec

with flowspec as Ytti mentioned already, I don't think the market has yet figured out how stuff like this should work and become cost-effective. Ah cost effective is a consideration, yeah that is a bit of a bummer. Kind regards, Job signature.asc Description: OpenPGP digital signature

Re: upstream support for flowspec

On 9/18/14 11:06 AM, John Kristoff wrote: On Thu, 18 Sep 2014 13:53:52 -0400 Daniel Corbe co...@corbe.net wrote: Is there anything in the air about widening the adoption base? Cisco? Brocade? I've seen some suggesting that increased support, but even at Juniper, actions seem to speak

Re: open source with flowspec ?

On 2014-03-13 23:13, joel jaeggli wrote: exabgp from ripe labs can inject flowspec routes. You mean from Exa Networks[1], not RIPE: https://github.com/Exa-Networks/exabgp Tom [1] http://www.exa.net.uk/

open source with flowspec ?

Hi, There is some open source sflow collector wich can talk via flowspec with juniper routers ? something like snort + nfdump ? I looking something besides Arbor because itis too expensive for me. thanks for help Peter

Re: open source with flowspec ?

exabgp from ripe labs can inject flowspec routes. typically some helper app would generate the policy for exabgp and then exabgp would do the heavy lifting. joel On 3/13/14, 3:42 PM, Piotr wrote: Hi, There is some open source sflow collector wich can talk via flowspec with juniper routers

Announcing the Community FlowSpec trial

Friends and colleagues, At NANOG 48 I talked about a community flow-spec service we were looking at trying to make work. This is the idea of using IETF RFC 5575 to pass around flow-based rules, in this case, primarily for dropping unwanted packets. This technology is not as widely deployed as

Re: Announcing the Community FlowSpec trial

flowspec routes can create firewall filters that use enough SRAM accesses that you will no longer be able to achieve line rate packets/sec. With a few more rules, you may find that your 10GE's will only be able to handle 3-5Mpps instead of the normal 14.8Mpps. When this happens, excess traffic above

Re: Announcing the Community FlowSpec trial

of which you should be aware. For example, we discovered that on MX routers (with classic I-chip DPCs, the performance should be somewhat better for Trio cards but we haven't fully tested the exact numbers yet), installing as few as a dozen flowspec routes can create firewall filters that use enough

BGP FlowSpec (RFC 5575) route injector

Hi, I juste added some preliminary support for FlowSpec (RFC5575) to my BGP route injector http://bgp.exa.org.uk/ As I am not aware of any other project allowing to inject flow route into a network, I am taking the liberty to plug it here. You can access the SVN repository at: http

Re: BGP FlowSpec support on provider networks

supporting BGP Flowspec at their edge, if there are any at all. The few providers I've reached out to have indicated they do not support this and have no intention of supporting this any time in the near future. I'm also curious why something so useful as to have the ability to advertise flow

RE: BGP FlowSpec support on provider networks

, but in this instance I feel their actions are doing quite the opposite. That aside, it's 2009 and we're still left with a situation where methodologies which have been used for roughly a decade now (i.e. BGP triggered destination-based filtering) is still considered the norm. Now I realize that FlowSpec

Re: BGP FlowSpec support on provider networks

Now I realize that FlowSpec isn't a panacea, but it certainly meets some of the requirements that many customers have today, and it gives us a lot more flexibility over simply destination based filtering. Whether it's FlowSpec or something else, what's it going to take to get the vendors

BGP FlowSpec support on provider networks

Hi folks, I am trying to compile data on which providers are currently supporting BGP Flowspec at their edge, if there are any at all. The few providers I've reached out to have indicated they do not support this and have no intention of supporting this any time in the near future. I'm also

Re: BGP FlowSpec support on provider networks

Fouant, Stefan wrote: Hi folks, I am trying to compile data on which providers are currently supporting BGP Flowspec at their edge, if there are any at all. The few providers I've reached out to have indicated they do not support this and have no intention of supporting this any time

BGP FlowSpec support on provider networks

Hi folks, I am trying to compile data on which providers are currently supporting BGP Flowspec at their edge, if there are any at all. The few providers I've reached out to have indicated they do not support this and have no intention of supporting this any time in the near future. I'm also

Re: BGP FlowSpec support on provider networks

Fouant, Stefan wrote: Hi folks, I am trying to compile data on which providers are currently supporting BGP Flowspec at their edge, if there are any at all. The few providers I've reached out to have indicated they do not support this and have no intention of supporting this any time

Re: BGP FlowSpec support on provider networks

On Apr 10, 2009, at 4:27 PM, Fouant, Stefan stefan.fou...@neustar.biz wrote: Hi folks, I am trying to compile data on which providers are currently supporting BGP Flowspec at their edge, if there are any at all. The few providers I've reached out to have indicated they do not support

Re: BGP FlowSpec support on provider networks

In my experience it's vendor support that is lacking, not provider support On Sat, Apr 11, 2009 at 6:08 AM, Fouant, Stefan stefan.fou...@neustar.bizwrote: Hi folks, I am trying to compile data on which providers are currently supporting BGP Flowspec at their edge, if there are any

Re: BGP FlowSpec support on provider networks

I am trying to compile data on which providers are currently supporting BGP Flowspec at their edge, if there are any at all. The few providers I've reached out to have indicated they do not support this and have no intention of supporting this any time in the near future. I'm also curious

Re: BGP FlowSpec support on provider networks

On Fri, Apr 10, 2009 at 6:38 PM, John Payne j...@sackheads.org wrote: On Apr 10, 2009, at 4:27 PM, Fouant, Stefan stefan.fou...@neustar.biz wrote: Hi folks, I am trying to compile data on which providers are currently supporting BGP Flowspec at their edge, if there are any at all