BCP38 For BGP Customers

Jared Mauch jared at puck.nether.net
Tue Nov 8 22:35:28 UTC 2022


On Mon, Nov 07, 2022 at 02:47:57PM -0500, Tom Beecher wrote:
> >
> > Are you taking the stance of "if you don't send us the prefix, then
> > we don't accept the traffic"?
> >
> 
> If you were one of my upstreams, and you implemented that, you would very
> quickly no longer be one of my upstreams.

	Yes, I suffer from having two upstreams that each have a shared
transit supplier.  They are most likely to only have a single best path
on their network and i can observe in the flow data it's not the one I
expect it to be.

	I'm not sure how that provider (3356) would make it happen.

	I can tell you that the uRPF that 7018 does made me not able to
utilize one of the providers for outbound traffic because they never
opened the proper ticket for routing that IP space until I had
side-escalated to some people that could help me after several months.

	Thankfully it's not a lot of bits but was still annoying to
diagnose and triage.

	- Jared

> On Mon, Nov 7, 2022 at 2:22 PM Charles Rumford via NANOG <nanog at nanog.org>
> wrote:
> 
> > Hello -
> >
> > I'm are currently working on getting BCP38 filtering in place for our BGP
> > customers. My current plan is to use the Juniper uRPF feature to filter
> > out
> > spoofed traffic based on the routing table. The mentality would be: "If
> > you
> > don't send us the prefix, then we don't accept the traffic". This has
> > raised
> > some issues amongst our network engineers regarding multi-homed customers.
> >
> > One of the issues raised was if a multi-homed BGP customer revoked a
> > prefix from
> > one of their peerings, but continued sending us traffic on the link then
> > we
> > would drop the traffic.
> >
> > I would like to hear what others are doing for BCP38 deployments for BGP
> > customers. Are you taking the stance of "if you don't send us the prefix,
> > then
> > we don't accept the traffic"? Are you putting in some kind of fall back
> > filter
> > in based on something like IRR data?
> >
> > Thanks!
> >
> > --
> > Charles Rumford (he/his/him)
> > Network Engineer | Deft
> > 1-312-268-9342 | charlesr at deft.com
> > deft.com
> >

-- 
Jared Mauch  | pgp key available via finger from jared at puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.


More information about the NANOG mailing list