On Thu, 15 Oct 2020 at 09:11, Ryan Hamel wrote:
Yep. Make sure you run BFD with your peering protocols, to catch outages
> very quickly.
>
Make sure you get higher availability with BFD than without it, it is easy
to get this wrong and end up losing availability.
First issue is that BFD has
Saku,
My experience with multiple carriers is that reroutes happen in under a minute
but rarely happen, I also have redundant backup circuits to another datacenter,
so no traffic is truly lost. If an outage lasts longer than 5 minutes, or it's
flapping very frequently, then I call the carrier.
On Wed, Oct 14, 2020, at 20:38, Rod Beck wrote:
> You are correct that if you have
> to carve it up into a lots of VLANs, it would be a nightmare. But
> Hibernia was a true wholesale carrier providing backbone to clients,
> not links distributing traffic to lots of user end points.
The fact
On Thu, 15 Oct 2020 at 10:28, Ryan Hamel wrote:
> My experience with multiple carriers is that reroutes happen in under a
> minute but rarely happen, I also have redundant backup circuits to another
> datacenter, so no traffic is truly lost. If an outage lasts longer than 5
> minutes, or it's
On Wed, Oct 14, 2020, at 22:40, Darin Steffl wrote:
> For 1G or less, ethernet
> might be cheaper with some protection already
Not to mention that 1G waves are becoming less and less comon those days. In
this part of the world waves tend to start at 10G.
Hey,
> All stub autonomous systems should have a simple egress ACL allowing only PI
> of their customers and their own PAs -it’s a simple ACL at each AS-Exit
> points (towards transits/peers), that’s it.
>
> -not sure why this isn’t the first sentence in every BCP and “security
> bulletin”…
I
Yep. Make sure you run BFD with your peering protocols, to catch outages very
quickly.
On Oct 14 2020, at 12:47 pm, Mike Hammett wrote:
> I haven't heard any concerns with reliability, on-net performance (aside from
> 2 gig flow limit) or other such things. Do they generally deliver well in
>
All DNS resolvers discovered on our network belong to customers. Our own
resolvers, running unbound, were not discovered.
While filtering same AS on ingress could help those customers (but only one
was a open relay), filtering bogons is something the customer can also do.
Or the software can be
Thanks all who replied. Yes in fact it is "ayo"-ending one, and i do
have others in the very same location and this doesn't happen at all.
Matter handed over to legal team.
cheers
/Nuno
On Wed, 2020-10-14 at 16:58 -0700, Robert L Mathews wrote:
> On 10/14/20 2:14 PM, Nuno Vieira via NANOG
Simple,
All stub autonomous systems should have a simple egress ACL allowing only PI of
their customers and their own PAs -it’s a simple ACL at each AS-Exit points
(towards transits/peers), that’s it.
-not sure why this isn’t the first sentence in every BCP and “security
bulletin”…
> From: Saku Ytti
> Sent: Thursday, October 15, 2020 11:12 AM
>
> Hey,
>
Hey Saku,
> > All stub autonomous systems should have a simple egress ACL allowing
> only PI of their customers and their own PAs -it’s a simple ACL at each
> AS-Exit
> points (towards transits/peers), that’s it.
> >
> >
On Thu, 15 Oct 2020 at 15:14, wrote:
> Yes one should absolutely do that, but...
> But considering to become a good netizen what is more work?
> a) Testing and the enabling uRPF on every customer facing box or setting up
> precise ACLs on every customer facing port, and then maintaining all
This is about ingress ACL not egress.
tor. 15. okt. 2020 12.00 skrev :
> Simple,
>
> All stub autonomous systems should have a simple egress ACL allowing only
> PI of their customers and their own PAs -it’s a simple ACL at each AS-Exit
> points (towards transits/peers), that’s it.
>
> -not sure
Hi Brian,
"However, I recognized a SP-specific case where we could receive legitimate
traffic sourcing from our own IP blocks: customers running multi-homed BGP
where we have assigned PA space to them. So I added "permit" statements for
traffic sourcing from these blocks."
If your customers
> Chris Adams
> Sent: Thursday, October 15, 2020 3:59 PM
>
> Once upon a time, adamv0...@netconsultings.com
> said:
> > Actually ideally there would be a feature/knob to automatically sync BGP
> (and static routes) with packet filters.
>
> Junos has prefix-lists that can be referenced in both
> From: Saku Ytti
> Sent: Thursday, October 15, 2020 3:30 PM
>
> On Thu, 15 Oct 2020 at 17:22, Tim Durack wrote:
>
>
> > We deploy urpf strict on all customer end-host and broadband circuits. In
> this scenario urpf = ingress acl I don't have to think about.
>
> But you have to think about
On Thu, 15 Oct 2020 at 17:49, Ryan Hamel wrote:
> > So you're dropping in every edge all UDP packets towards these three ports?
> > Your customers may not appreciate.
> You must not be familiar with JUNOS' ACL handling. This would be applied to
> interface lo0, which is specifically for
We deploy urpf strict on all customer end-host and broadband circuits. In
this scenario urpf = ingress acl I don't have to think about.
We deploy urpf loose on all customer multihomed DIA circuits. I dont this
makes sense - ingress packet acl would be more sane.
Any flavour of urpf on upstream
Once upon a time, adamv0...@netconsultings.com
said:
> Actually ideally there would be a feature/knob to automatically sync BGP (and
> static routes) with packet filters.
Junos has prefix-lists that can be referenced in both BGP policy and
firewall statements.
--
Chris Adams
Speaking as an ISP:
Most of the ISP networks I manage are multi-homed, and I don't
think uRPF provides the knobs to ensure legitimate traffic doesn't get
dropped in some cases, so we use static ACLs at the upstream edge on
ingress (and egress). These need updated any time new IP space is
Saku Ytti wrote on 15/10/2020 15:29:
But you have to think about what prefixes a customer has. If BGP you
need to generate prefix-list, if static you need to generate a static
route. As you already have to know and manage this information, what
is the incremental cost to also emit an ACL?
the
On Thu, Oct 15, 2020 at 10:30 AM Saku Ytti wrote:
> On Thu, 15 Oct 2020 at 17:22, Tim Durack wrote:
>
>
> > We deploy urpf strict on all customer end-host and broadband circuits.
> In this scenario urpf = ingress acl I don't have to think about.
>
> But you have to think about what prefixes a
> Do you want your martini emulated backbone link to fail when operator
> reroutes their own LSR-LSR link failure?
As I said, it's an acceptable loss for my employers network, as we have a BGP
failover mechanism in place that works perfectly.
> So you're dropping in every edge all UDP packets
Hi Nanog,
I am troubleshooting an issue where it appears that users orginitating from
a certain subnet that I manage are unable to access websites hosted by
Shopify. We have contacted Shopify support and are still waiting for
resolution.
If anybody here is from Shopify - I would like to get some
On Thu, 15 Oct 2020 at 17:22, Tim Durack wrote:
> We deploy urpf strict on all customer end-host and broadband circuits. In
> this scenario urpf = ingress acl I don't have to think about.
But you have to think about what prefixes a customer has. If BGP you
need to generate prefix-list, if
Greetings,
I am looking for somebody working for Twitter. I am working for a small ISP in
the Netherlands (AS 206238).
Our problem is that Twitter's geolocation database still situates some our IPv4
blocks in the United Arab Emirates. This renders Twitter unusable for some of
our customers.
I have a Bell Canada gig fibre connection. My first attempt was to bridge
their all-in-one box (disaster, unreliable as all hell), second was to set a
bunch of rules for inbound traffic. Apart from inbound access being *very*
iffy, their device was s_l_o_w.
So I pulled the fibre GBIC, used a
On 10/15/20 6:15 PM, Robert Blayzor wrote:
On 10/14/20 1:56 PM, Shawn L via NANOG wrote:
When I last spoke to them, it sounded like they were using a bunch of
LAG groups based on ip address because they _really_ wanted to know how
many ip addresses we had and what kind of traffic we would be
Would an engineer from Cox please contact me privately?
On 10/14/20 1:56 PM, Shawn L via NANOG wrote:
> When I last spoke to them, it sounded like they were using a bunch of
> LAG groups based on ip address because they _really_ wanted to know how
> many ip addresses we had and what kind of traffic we would be expecting
> (eyeball networks, big data
It is especially fitting whenever the NANOG/ARIN joint meetings occur in the
same week that we “remember IANA”.
As time has gone on, fewer and fewer of us actually know who J. Postel is -
that name that appears at the end of so many RFC’s we refer to every day. The
same person who also guided
31 matches
Mail list logo
