On 4/15/20 11:33 PM, Ross Tajvar wrote:
Can you give some examples of the things you mention above? I'm not
doing much in terms of customer filtering and would be interested to
hear what others consider best practice.
My experience is that there's two groups of customers that are
problematic
So I’m taking this thread for a total test-drive and we’re going down this
random ally...
I call our NOC “24x7x365” I hear that in my head as “twenty-four (hour) - BY -
Seven (days a week) - BY - 365 (days a year, indicating we don’t close on any
holidays).
Is that really not a thing? I swea
We’ve got a 24/7 NOC and respond to abuse reports in either real-time in as
close to real-time as we can, I’d send another message if it went 24 hours
without a reply too. We also have a ticket system that replies immediately so
they know the e-mail went through, and we track it like a real comp
The first warning sign would be where they discuss your AUP and exceptions /
corner cases to it
--srs
From: NANOG on behalf of Ross Tajvar
Sent: Thursday, April 16, 2020 9:03:58 AM
To: Rich Kulawiec
Cc: North American Network Operators' Group
Subject: Re: Cons
On Wed, Apr 15, 2020 at 8:52 AM Rich Kulawiec wrote:
> there are
> all kinds of things that can be done to detect problematic customers
> before you sign them up and once they're in place.
>
Hey Rich,
Can you give some examples of the things you mention above? I'm not doing
much in terms of cu
Sorry, I did not intend to imply that you were.
I should have prefaced my post with "to add".
Regards,
Jakob.
From: Matthew Petach
Sent: Wednesday, April 15, 2020 4:29 PM
To: Jakob Heitz (jheitz)
Cc: nanog@nanog.org
Subject: Re: Route aggregation w/o AS-Sets
I apologize if I wasn't clear.
I
I apologize if I wasn't clear.
I don't recommend ever using AS_SET.
So, in rule 3, I use the atomic-aggregate knob
to announce the single covering aggregate with
my backbone ASN as the atomic-aggregate origin
AS, and I don't generate or propagate any AS_SET
information along with the aggregate.
Suppose you had a set of customers than all announced to you a set of routes
and all those routes complete an aggregate
and you announce only the aggregate to those customers
and you include an AS_SET with it
then those customers will drop your aggregate, thinking there is an AS-loop
and those cust
Hi Josh. We generally do not block IP’s.
Feel free to contact me off-list with details.
Ryan @ Fastly
On Wed, Apr 15, 2020 at 11:32 Josh Luthman
wrote:
> Can someone from Fastly reach out to me? I believe you're blocking some
> of our IPs.
>
>
> Josh Luthman
> Office: 937-552-2340
> Direct: 9
Can someone from Fastly reach out to me? I believe you're blocking some of
our IPs.
Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373
On Wed, 15 Apr 2020 at 19:00, Deepak Jain wrote:
> Thanks for your input. How do you handle next-hops? Tunnels between all eBGP
> speakers as if they were fully meshed as their potential next-hops?
Don't run Cisco ORR RR or have IGP next-hops :/
--
++ytti
> Do we even like BGP ORR?
I like it, I think ADD-PATH and ORR are mandatory features in modern RR infra.
However proper interaction between them may not exist in every implementation.
Basically you want
a) send all ECMPable paths
b) send one backup path
This will lead to superior to full-mes
From: NANOG On Behalf Of Lars Prehn
Sent: Tuesday, April 14, 2020 3:02 PM
To: Christopher Morrow
Cc: nanog list
Subject: Re: Route aggregation w/o AS-Sets
Thanks for all the answers! I think I have one more detail I'd like to know.
Lets say you own X/22. You have delegated X/23 to your cust
> Nice to hear ORR has come a long way that it's somewhat usable.
It is usable, we have taken it even a step forward:
- virtualized RR
- add-path
- ORR
- IGP topology to RR via BGP-LS so we don't have to extend ISIS to VMs (there
are some issues with SR-IOV)
--
That sounds pretty exciting and
On 15/Apr/20 13:36, Saku Ytti wrote:
>
> ORR is not an RFC and there are some open questions. What to reflect,
> when next-hop is not in IGP? Do we hope that receiver would recurse to
> the same IGP next-hop? Juniper makes this assumption, which to me is
> decidedly the common case. Cisco make
Thanks for all the answers! I think I have one more detail I'd like to
know.
Lets say you own X/22. You have delegated X/23 to your customer, keeping
the other /23 for yourself. For some reason, your customer also owns and
announced (to you) all remaining IPs necessary to complete X/21.
Do y
On 15/Apr/20 14:53, Tarko Tikan wrote:
>
>
> Well ISIS works with bridge but we like to keep our virtualized NFs
> simple so KVM hosts have dedicated 10G port for NFs (that connects
> directly to a metro node) and we run SR-IOV.
Got you.
Mark.
hey,
I was asking in relation to your IS-IS + SR-IOV issues.
Well ISIS works with bridge but we like to keep our virtualized NFs
simple so KVM hosts have dedicated 10G port for NFs (that connects
directly to a metro node) and we run SR-IOV.
--
tarko
On Mon, Apr 13, 2020 at 12:11:44PM -0700, Matt Corallo via NANOG wrote:
> I don???t really get the point of bothering, then. AWS takes about
> ~forever to respond to SES phishing reports, let alone hosting abuse,
> and other, cheaper, hosts/mailers (OVH etc come up all the time) don???t
> bother at
[ Copied to Jonathan @ RiskIQ because I don't believed he's subscribed. ]
On Mon, Apr 13, 2020 at 11:14:11PM +0530, Kushal R. wrote:
> All abuse reports that we receive are dealt within 48 business
> hours. As far as that tweet is concerned, it???s pending for 16 days
> because they have been blo
On 15/Apr/20 14:40, Tarko Tikan wrote:
>
> No, we had RR function inline on ASBRs.
>
> To be clear, our RRs are not BIRD but Nokia VSRs.
I was asking in relation to your IS-IS + SR-IOV issues.
Mark.
hey,
Were you previously running IS-IS on a UNIX/Linux system running in a VM?
No, we had RR function inline on ASBRs.
To be clear, our RRs are not BIRD but Nokia VSRs.
--
tarko
On 15/Apr/20 14:28, Tarko Tikan wrote:
>
> It is usable, we have taken it even a step forward:
>
> - virtualized RR
> - add-path
> - ORR
> - IGP topology to RR via BGP-LS so we don't have to extend ISIS to VMs
> (there are some issues with SR-IOV)
Awesome!
Never been a fan of Add-Path or Di
hey,
Nice to hear ORR has come a long way that it's somewhat usable.
It is usable, we have taken it even a step forward:
- virtualized RR
- add-path
- ORR
- IGP topology to RR via BGP-LS so we don't have to extend ISIS to VMs
(there are some issues with SR-IOV)
--
tarko
On 15/Apr/20 13:36, Saku Ytti wrote:
>
> ORR is not an RFC and there are some open questions. What to reflect,
> when next-hop is not in IGP? Do we hope that receiver would recurse to
> the same IGP next-hop? Juniper makes this assumption, which to me is
> decidedly the common case. Cisco makes
On Wed, 15 Apr 2020 at 10:56, Deepak Jain wrote:
Hey,
> Do we even like BGP ORR?
I like it, I think ADD-PATH and ORR are mandatory features in modern
RR infra. However proper interaction between them may not exist in
every implementation. Basically you want
a) send all ECMPable paths
b) send o
Deepak Jain wrote on 15/04/2020 08:52:
Do we even like BGP ORR?
yes, but it needs to be planned carefully.
Nick
Thinking about setting up BGP-ORR on some BIRD VMs (https://bird.network.cz)
for lab purposes, I'm sure its more than sufficient.
Does anyone use these in production? Any thoughts, experiences, caveats?
Do we even like BGP ORR?
Thanks in advance,
Deepak
28 matches
Mail list logo
