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 Fl

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 Flo

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 im

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

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

one 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 inclu

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 polic

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

y inc tel:438 806-9800 site: <https://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 Measure

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, and

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

$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

uding some tier 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 R

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

ich.comp...@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 flowspe

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

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 will come

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

detection/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 the

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,

RE: BGP FLowspec to Yang/Yaml ACL

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 to

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 Ric

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 a

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 are

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 chang

Re: FlowSpec Support

irmed. Also, what's big? Listed 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 Intellige

Re: FlowSpec Support

sn'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 information fr

FlowSpec Support

iving 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 f

Re: BGP FlowSpec

> Am 03.05.2016 um 00:06 schrieb Roland Dobbins : > > 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, IMH

Re: BGP FlowSpec

> Am 02.05.2016 um 23:51 schrieb jim deleskie : > > 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 ov

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 >> downstream on IP-Transit links

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 granula

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 t

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 that

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 traffic

Re: BGP FlowSpec

place 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 optimal place (e.g., at ne

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

arts. ;) > > > 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 > your address b

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 when

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 Flo

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 with this was that it

Re: BGP FlowSpec

/ Sent via the Samsung GALAXY S® 5, an AT&T 4G LTE smartphone Original message From: Martin Bacher Date: 4/29/2016 2:02 AM (GMT-08:00) To: Tyler Haske Cc: NANOG list Subject: Re: BGP FlowSpec Hello Tyler, thanks for your reply. > Am 28.04.2016 um 17:37 schrie

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 about the > > type of attack

Re: BGP FlowSpec

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 about the > type of attacks, attack time, sources, source and destination ports, and so on. I know this something which is generally n

Re: BGP FlowSpec

> Am 27.04.2016 um 18:09 schrieb Hank Nussbacher : > > On 27/04/2016 18:58, John Kristoff wrote: >> On Thu, 21 Apr 2016 09:46:13 +0200 >> Martin Bacher wrote: >> >>> - Intra-AS BGP FlowSpec deployment: Who is running it? For which kind >>> of attac

Re: BGP FlowSpec

> Am 27.04.2016 um 17:58 schrieb John Kristoff : > > On Thu, 21 Apr 2016 09:46:13 +0200 > Martin Bacher 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 >>

Re: BGP FlowSpec

On 27/04/2016 18:58, John Kristoff wrote: > On Thu, 21 Apr 2016 09:46:13 +0200 > Martin Bacher 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 traffi

Re: BGP FlowSpec

On Thu, 21 Apr 2016 09:46:13 +0200 Martin Bacher 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 redirect/remark > capabilities?

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. Obviousl

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 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 t

Re: upstream support for flowspec

substantially more profitable especially on a per packet or byte basis then delivering them. Not everyone wants that service however. > Aside from practical issues with flowspec as Ytti mentioned already, I > don't think the market has yet figured out how stuff like this should > work

Re: upstream support for flowspec

to you because of customer-pushed ACLs? If so, that would take the argument away "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? w

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

nly 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 produc

Re: upstream support for flowspec

; services. >> >> As far as I can tell though 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? >

Re: upstream support for flowspec

ly 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 effects to

Re: upstream support for flowspec

Envoyé de mon iPhone > Le 18 sept. 2014 à 19:53, Daniel Corbe a écrit : > > > 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.

Re: upstream support for flowspec

On Thu, Sep 18, 2014 at 1:53 PM, Daniel Corbe 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 mitigate an at

Re: upstream support for flowspec

On Thu, 18 Sep 2014 13:53:52 -0400 Daniel Corbe 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 interest for a

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 h

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/

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 >

Re: open source with flowspec ?

On 3/13/2014 6:42 PM, Piotr wrote: 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 I believe the goal of ExaDDOS is

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: Announcing the Community FlowSpec trial

serious performance considerations 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 do

Re: Announcing the Community FlowSpec trial

ut we haven't fully tested the exact numbers yet), installing as few as a dozen 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 b

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 tr

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

> 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

RE: BGP FlowSpec support on provider networks

. BGP triggered destination-based filtering) is still considered the norm. 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'

Re: BGP FlowSpec support on provider networks

On Apr 11, 2009, at 12:54 AM, Christopher Morrow wrote: On Fri, Apr 10, 2009 at 6:38 PM, John Payne wrote: On Apr 10, 2009, at 4:27 PM, "Fouant, Stefan" > wrote: Hi folks, I am trying to compile data on which providers are currently supporting BGP Flowspec at their e

Re: BGP FlowSpec support on provider networks

On Fri, Apr 10, 2009 at 6:38 PM, John Payne wrote: > > > On Apr 10, 2009, at 4:27 PM, "Fouant, Stefan" > wrote: > >> Hi folks, >> >> I am trying to compile data on which providers are currently supporting >> BGP Flowspec at their edge, if there a

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 &g

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 wrote: > 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

On Apr 10, 2009, at 4:27 PM, "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 thi

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 i

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&#

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 s

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&#