Skip to content

/ peeringdb

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Mark IXP peering LAN as bogon #352

Closed
johannesmoos opened this issue Jul 17, 2018 · 12 comments
Closed

Mark IXP peering LAN as bogon #352

johannesmoos opened this issue Jul 17, 2018 · 12 comments
Assignees
@arnoldnipper
Labels
Minor enhancement
Milestone
2.21

Comments

@johannesmoos
Copy link

@johannesmoos johannesmoos commented Jul 17, 2018

Hi team,

we at DE-CIX (and probably every other IXP as well) filter out our own peer peering LAN prefixes (i.e. peering lan hijacks) at our route servers. I'm interested in doing that for peering LANs of other IXPs as well. However, an IXP might announce its peering LAN intentionally in the DFZ. In this case, the announcement should not be filtered by the route server.

I can obtain a list of peering LANs from PeeringDB, however the information if a prefix is supposed to be in the DFZ or not is missing. Would it make sense to allow IXPs to tag their peering LANs as a bogon (checkbox) so that others know if the prefix is supposed to be globally visible or not?

The idea is not new: It existed in the EURO-IX database, but I think it might be helpful to integrate it in PeeringDB as well because it is used by a wider audience.

Regards
Johannes
@grizz
Copy link
Member

@grizz grizz commented Oct 10, 2018

@peeringdb/pc no votes on this

+1 from me
@netravnen
Copy link

@netravnen netravnen commented Oct 10, 2018

+1

Note: I would mark all IXP-NET prefixes as bogons by default. And make it an option to change this. (assuming most IXP's would not want their peering lan prefixes propagated in the DFZ)
@arnoldnipper
Copy link
Contributor

@arnoldnipper arnoldnipper commented Oct 11, 2018

+1 what @netravnen says. By default ixpfx are bogon You have to tivck a box to specify that is in the DMZ by purpose
@mcmanuss8
Copy link
Contributor

@mcmanuss8 mcmanuss8 commented Jan 11, 2019

+1 and making sure it's set by default
@fhibler fhibler self-assigned this Jun 24, 2019
@fhibler
Copy link

@fhibler fhibler commented Aug 8, 2019

+1 to mark it and set it to default (with option to opt-out)
@arnoldnipper arnoldnipper assigned arnoldnipper and unassigned fhibler Nov 18, 2019
@arnoldnipper arnoldnipper added this to the Decide milestone Nov 24, 2019
@arnoldnipper
Copy link
Contributor

@arnoldnipper arnoldnipper commented Dec 18, 2019 •
edited

To summarize:

  • add a field (flag) to ixpfx (GUI: "Not Bogon", API: not_bogon)

  • default is unticked resp. FALSE

  • notify IX operators when implementing (@peeringdb/ac)
@grizz
Copy link
Member

@grizz grizz commented Dec 18, 2019

Not to bikeshed, but I keep getting confused when I read this ticket, seems like it would make more sense to make it "In DFZ" API: in_dfz?
@arnoldnipper
Copy link
Contributor

@arnoldnipper arnoldnipper commented Dec 18, 2019

Happy with have it named like @grizz proposes
@vegu vegu added the Minor label Jan 14, 2020
@koalafil
Copy link

@koalafil koalafil commented Jun 1, 2020

Can we have the Release Notes pls?
@arnoldnipper
Copy link
Contributor

@arnoldnipper arnoldnipper commented Jun 2, 2020

Release Note

Allow IXP to tag their LAN prefixes as bogons. In general, LAN prefixes should not be visible in the DFZ. If it *should be visible, IXPs are able to debogonise them
vegu added a commit to peeringdb/django-peeringdb that referenced this issue Jun 24, 2020
@vegu
Mark IXP peering LAN as bogon (peeringdb/peeringdb#352)
4702441
vegu added a commit to peeringdb/django-peeringdb that referenced this issue Jun 24, 2020
@vegu
Merge branch 'gh_pdb_352' into 'support_202004'
1587a98 
Mark IXP peering LAN as bogon (peeringdb/peeringdb#352)

See merge request gh/peeringdb/django-peeringdb!6
vegu added a commit that referenced this issue Jun 24, 2020
@vegu
Mark IXP peering LAN as bogon #352
500ae78
vegu added a commit that referenced this issue Jun 24, 2020
@vegu
Merge branch 'gh_352' into 'support_202004'
fd81496 
Mark IXP peering LAN as bogon #352

See merge request gh/peeringdb/peeringdb!67
@grizz grizz mentioned this issue Jun 24, 2020
Merged
vegu added a commit that referenced this issue Jun 24, 2020
@vegu
Mark IXP peering LAN as bogon #352
5aa769b
@grizz grizz closed this in #751 Jun 24, 2020
grizz added a commit that referenced this issue Jun 24, 2020
@grizz @vegu
June updates (#751)
Verified
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: 4AEE18F83AFDEB23 Learn about signing commits
Loading status checks…
af6974e 
* Add pointer from API docs to tutorial #650

* Sorting by clicking table headers should use local-compare #356

* Mark IXP peering LAN as bogon #352

* Add help text to "Add (Facility, Network, Exchange)" tab #669

* Add Looking Glass field to the IX object #672

* Add read-only Superuser #679

* Make spelling of traffic levels consistent #519 (#723)

* Offer 2FA (#290)

* Show "Last Updated" fields on fac, ix, org records (#526)

* Enable sort and reverse sort of IP column in IX display (#72)

* IRR validation not handling unexpected characters gracefully (#712)

* Support alternative direction of writing, e.g. Arabic (#618)

* Undeleting an ixlan with an emtpy IPv4 XOR IPv6 field throws a silly error (#644)

* Changing org while adding net results in 500 #654

* missing delete button for organisations (#121)

* When changing owner of an ix admin GUI borks because of "Ixlan for exchange already exists" #666

* Selection should only present undeleted objects (#664)

* change default encoding of API calls to 'utf-8' #663

* Posting https://www.peeringdb.com onto social media doesn't select a good preview image #537

* Revert "Add Looking Glass field to the IX object #672"

This reverts commit 4daf252.

Conflicts:
	peeringdb_server/migrations/0037_ix_looking_glass.py
	peeringdb_server/views.py

* 500 Internal Error when creating IX where prefix already exists elsewhere #718

* Fix graceful restore of soft-deleted objects with translation active (#580)

* Don't return any POC data with status=deleted #569
Hard delete soft-deleted pocs after grace period #566

* django-peeringdb from github@2.0.0.2-beta

Co-authored-by: Stefan Pratter <stefan@20c.com>
@grizz grizz mentioned this issue Jul 1, 2020
Merged
grizz added a commit to peeringdb/django-peeringdb that referenced this issue Jul 1, 2020
@grizz @vegu
2.0.0.2 beta (#44)
Verified
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: 4AEE18F83AFDEB23 Learn about signing commits
Loading status checks…
fea2add 
* add py3.7 tests and mark as supported version,
remove py3.4 tests and remove from support versions

* Mark IXP peering LAN as bogon (peeringdb/peeringdb#352)

* Make spelling of traffic levels consistent (peeringdb/peeringdb#519)

* fix migration hierarchy

* changelog

* version to 2.0.0.2

Co-authored-by: Stefan Pratter <stefan@20c.com>
@job
Copy link
Contributor

@job job commented Jul 6, 2020

Folks - why did we end up implementing this and not recommending people to use the RPKI?

I get that the feature is already coded and pushed out, but this seems to 100% overlap with RPKI functionality, AND is of lower quality (as there is no crypto validation).

Why?
@funkestefan
Copy link
Contributor

@funkestefan funkestefan commented Jul 6, 2020

Whats the point of having this feature at PeeringDB anyway? I am not aware of a tooling that asks pdb for a prefix and it's status. In best case an ixlan's AS should set "never via route server" (I am aware that there are some rs/ixps having their own AS in the path)
@nickhilliard nickhilliard mentioned this issue Jul 13, 2020
Closed
@vegu vegu modified the milestones: Next Release, 2.21 Jul 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@arnoldnipper arnoldnipper

Labels
Minor enhancement
Projects
None yet
Milestone
2.21
Linked pull requests

Successfully merging a pull request may close this issue.

June updates