Re: BGP Engines with support to "RTFilter address-family"
On 26/02/2023 21.46, Douglas Fischer wrote:
> However, I'm searching for BGP Engines that implement this address-family
> (AFI=1, SAFI=132), to avoid Lock-In.
>
> But I'm looking for an open-source engine that supports it.
rustybgp and gobgp might support it.
$ grep -r -P "AFI,SAFI = 1,132" rustybgp gobgp
rustybgp/tools/pyang_plugins/gobgp.yang: "Route target membership
(AFI,SAFI = 1,132)";
gobgp/tools/pyang_plugins/gobgp.yang: "Route target membership
(AFI,SAFI = 1,132)";
Nothing on FRR
$ grep -P -r -i 'IANA_SAFI_.* = 1\d{2,}' frr
frr/lib/iana_afi.h: IANA_SAFI_MPLS_VPN = 128,
frr/lib/iana_afi.h: IANA_SAFI_FLOWSPEC = 133
The mentions in the FRR issue tracker are (now) old entries.
Re: Longest prepend( 255 times) as path found
On Thu, 25 Aug 2022, 16:31 Alistair Mackenzie, wrote: > There are some generally accepted and useful filters found at > https://bgpfilterguide.nlnog.net/. There is one which covers excess > prepends. > It's generally accepted to filter **very** long as paths. As Alistair pointed to. The guide mentions 100x max path length as a (current!) value that won't filter out long current as paths. (And protect you from others missing filtering.) https://bgpfilterguide.nlnog.net/guides/long_paths/ If you want to go for a lower than 100 value. RIB dumps from the ripe ris collectors / route-views may be the most accessible starting point for data to analyse. If you want to read data about avg as path lengths over the years. APNIC publishes data about it. https://blog.apnic.net/2022/01/06/bgp-in-2021-the-bgp-table/
Peering Contact for AS41552 eBay Classifieds Group
Hi NANOG, AS41552 eBay Classifieds Group https://www.peeringdb.com/asn/41552 Anyone know of a working peering contact for this network? The one email address listed on the peeringdb page returns an error message: "550 #5.1.0 Address rejected." -- Med Venlig Hilsen, Chriztoffer Hansen | e c...@kviknet.dk Netværkstekniker Kviknet.dk ApS | cvr 35466924 | asn 204151
Re: Setting sensible max-prefix limits
On Wed, 18 Aug 2021 at 11:33, Lars Prehn wrote: > I guess for long standing peers one could just eyeball it, e.g., current > prefix count + some safety margin. How does that work for new peers? If you have automation in place. Another approach is to count the received prefix. Store the counted value in a database. Based on the avg prefix count over X (time period). Add e.g. 10 - 25 % headroom over the avg prefix count and use the calculated value as the max-prefix limit? PeeringDB data (sometimes or often?) be somewhat misleading (in contrast to actual avg prefix count) in the sense 'some' networks will input a value with headroom percentages already included.
Re: A crazy idea
On Tue, 20 Jul 2021 at 17:41, Bryan Fields wrote: > On 7/20/21 10:01 AM, Michael Loftis wrote: > > My apologies to everyone using an HTML mail client. > > No reason to apologize for that. If someone is careless enough to use an HTML > client on a mailing list, they deserve what they get :-D Enable the setting in Mailman to enforce plain-text E-mail delivery from the list address?
Re: Do you care about "gray" failures? Can we (network academics) help? A 10-min survey
On Thu, 8 Jul 2021 at 22:10, Baldur Norddahl wrote: > We had a line card that would drop any IPv6 packet with bit #65 in the > destination address set to 1. Turns out that only a few hosts have this bit > set to 1 in the address, so nobody noticed until some Debian mirrors started > to become unreachable. Also, web browsers are very good at switching to IPv4 > in case of IPv6 timeouts, so nobody would notice web hosts with the problem. > And then we had to live with the problem for a while because the device was > out of warranty and marked to be replaced, but you do not just replace a > router in a hurry unless you absolutely need to. Grey failures, ugh. Heard of a colleague at prior employment who did troubleshooting of an issue with an extended line. Where packets to select IPv4 dest addresses would be dropped by the extended line card. Took time plus inserting middle-boxes from Vendor Y (packet capture for evidence) to confirm and convince the vendor of their code had problems.
Re: BGP38 egress filter on Ubuntu Server
On Tue, 1 Jun 2021 at 22:58, Chriztoffer Hansen wrote: > https://team-cymru.com/community-services/bogon-reference/bogon-reference-http/ I have found that pfSense uses this feed to filter traffic if 'Block bogon networks' is enabled on the WAN interface(s). I.e. the pfSense bogons + bogonsv6 tables match the Cymru HTTP feed. -- Chriztoffer
Re: BGP38 egress filter on Ubuntu Server
On Tue, 1 Jun 2021 at 22:43, Stephen Satchell wrote: > Before I re-invent the wheel, has anyone come up with blackhole route > specifications for netplan in Ubuntu servers? Such a capability would > perform the egress blocking for an edge server. https://team-cymru.com/community-services/bogon-reference/bogon-reference-bgp/ https://team-cymru.com/community-services/bogon-reference/bogon-reference-http/ Could be considered implemented, too. Either as EBGP multi-hop feed from Cymru or via (scheduled cron) HTTP(s) download and distributed internally in your network via IBGP. -- Chriztoffer
Re: BGP Traffic Engineering - Active\Passive
On Fri, 21 May 2021 at 17:13, nanoguser100 via NANOG wrote: > If I'm unable to do that will most provider prepend on your behalf so that > ISP-A would add the prepends for only? For this part, you will have to investigate which BGP standard/extended/large communities your ISP-A/B supports. By setting the correct community, your upstream can do the prepending for you. (usually 1, 2, or 3 times depending on the supported communities) E.g. * ISP-A 174 * ISP-B 1299 1299 or * ISP-A 174 174 174 * ISP-B 1299 > Now to mix this up let's say another ASN, was in-between 1299 and > but latency wise the route was still faster. Some(!) ISP's will support _only_ prepending to select ASN's they peer with. E.g. * prepend only to peers * prepend only to customers * prepend only to other upstream (in case of T2 and T3) * prepend if a route is exported outside $region-Y * prepend to ASN x 1-time * prepend to ASN x 2-times * prepend to ASN x 3-times E.g. * ISP-A 174 174 174 65001 * ISP-A 174 174 174 65002 * ISP-A 174 174 174 65003 * ISP-A 174 * ISP-B 1299 1299 You will need to investigate which BGP communities your ISP's support for the above example to be relevant to you. If they do not have the docs available on their public website or customer portal. Ask their support for a list of supported communities. /Chriztoffer
Re: Historic IRR/RADB snapshots?
On Wed, 24 Feb 2021 at 09:00, Lars Prehn wrote: > Does anybody have (somewhat frequent, e.g., monthly) snapshots of the > various IRR databases lying around? Any snapshot since 2010 would be > helpful! For any specific use-case whowas cannot solve? ¯(°_o)/¯ -- Chriztoffer
Re: DMVPN via Internet or Private APN
On Mon, 11 Jan 2021 at 19:27, Sean wrote: > I offer a question to help me settle an internal debate. As a network > engineer for a large enterprise, do you choose ISP flexibility or ISP > security when you build an OOB network? I was tasked to create an OOB > network for my company. Realistically it would only be deployed to 25% > of the companies sites as they are considered important enough to > justify the cost. The design is simple enough. Hub and spoke using > cellular routers. DMVPN will carry data from the spoke to the hub. Maybe this talk from NLNOG 2020 is of interest to you concerning OOB. https://www.youtube.com/watch?v=72yccGg0h8g -- Chriztoffer
AWS using 169.254.0.0/30 for ptp VPNs.
On 26 Oct 2020 17:57, B F wrote: > Looking for any fresh experience with this: > > https://docs.aws.amazon.com/vpn/latest/s2svpn/VPNTunnels.html > <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.aws.amazon.com_vpn_latest_s2svpn_VPNTunnels.html=DwMFaQ=uYNHtGtKbnb8KY_aWQH_nw=rdjfZQefpT_LdC_BOcEEpw=cOAeqtk8BvD_8rwuvYiLdhl4JrJs6NZR0qY7uRIoajg=clsyJTjLlh2voqF13Lny9y8vAUWziL95IobbMLlgDdM=> > > Any problems experienced with using that reserved space as a non-local > destination? Seems like it might not be wise WRT RFC3927. > > Apparently space from RFC1918 is not an option. > > Found a few hits in the archives (2012) but looking recent experience. > > Thank you very much in advance. > Using 169.254.0.0/16 or fe80::/64 Link-Local space as next-hop shouldn't cause you to much of a head-egg. One point to remember is "just" rewriting the next-hop address to a network reachable for your other routers and switches to forward the traffic towards. (e.g. the loopback address of your router peering with AWS Private Cloud) -- Chriztoffer smime.p7s Description: S/MIME Cryptographic Signature
Juniper configuration recommendations/BCP
On 08/10/2020 11:37, Forrest Christian (List Account) wrote: > Is there anything I should worry about > which is Juniper-specific? JUNOS default ARP timeout: 20 min. If you connect to IXP's. Recommended ARP timeout: 4 hours.
cloud automation BGP
On 29/09/2020 15:36, Graham Johnston wrote: > Does anyone have a quick answer as to what public data sources are used? I > tried looking at the main github page for the project but I either missed it > or it isn't there. https://blog.apnic.net/2020/07/27/easy-bgp-monitoring-with-bgpalerter/ > Where is the data coming from? > BGPalerter connects to public data sources (not managed by NTT) and the > entire monitoring is done directly in the application (there are no NTT > servers involved). > > A data source can be integrated with a connector component. In this way, you > can also use your data if you would like. > > Currently, BGPalerter connects automatically to RIS live, an amazing project > by the RIPE NCC. RIS live collects BGP updates coming from more than 600 > peers. The updates are streamed to BGPalerter in real time for an > unprecedented detailed and responsive monitoring. > https://raw.githubusercontent.com/nttgin/BGPalerter/v1.26.0/config.yml.example --> connectors smime.p7s Description: S/MIME Cryptographic Signature
BFD for routes learned trough Route-servers in IXPs
On 16/09/2020 04:01, Ryan Hamel wrote: > CoPP is always important, and it's not just Mikrotik's with default low > ARP timeouts. > > Linux - 1 minute > Brocade - 10 minutes > Cumulus - 18 minutes > BSD distros - 20 minutes > Extreme - 20 minutes Juniper - 20 minutes > HP - 25 minutes -- Chriztoffer smime.p7s Description: S/MIME Cryptographic Signature
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
On Wed, 9 Sep 2020 at 06:25, Mark Tinka via NANOG wrote: > It's not unlike trusting your customers to send you FlowSpec > instructions. No issues technically, but do you want to do it? Why not? As a service offering, it makes total sense. Thou, generally I agree with you. Trust, but verify any received announcement conforms to a base-set of expectations. Discard non-conforming. -- Chriztoffer
Re: BGP Community - AS0 is de-facto "no-export-to" marker - Any ASN reserved to "export-only-to"?'
Douglas,
On Tue, 8 Sep 2020 at 17:55, Douglas Fischer via NANOG wrote:
>
> Most of us have already used some BGP community policy to no-export some
> routes to somewhere.
>
> On the majority of IXPs, and most of the Transit Providers, the very common
> community tell to route-servers and routers "Please do no-export these routes
> to that ASN" is:
>
> -> 0:
>
> So we could say that this is a de-facto standard.
>
>
> But the Policy equivalent to "Please, export these routes only to that ASN"
> is very varied on all the IXPs or Transit Providers.
>
>
> With that said, now comes some questions:
>
> 1 - Beyond being a de-facto standard, there is any RFC, Public Policy, or
> something like that, that would define 0: as "no-export-to"
> standard?
>
> 2 - What about reserving some 16-bits ASN to use : as
> "export-only-to" standard?
> 2.1 - Is important to be 16 bits, because with (RT) extended communities, any
> ASN on the planet could be the target of that policy.
> 2.2 - Would be interesting some mnemonic number like 1000 / 1 or so.
Please see:
- https://www.euro-ix.net/en/forixps/large-bgp-communities/
- https://tools.ietf.org/id/draft-adkp-grow-ixpcommunities-00.html
If you use large communities (yes, I know the standard is NOT 100%
unilaterally supported by all vendors just yet).
Using the combination of RS${ASN}:0:0 (Don't announce to any peer) and
RS${ASN}:1:${PEERAS} (Advertise to PEERAS) you can do what you are
asking for. Announcing routes to only select peers.
Most major IXP's will support most of the mentioned large
communities. For ISP's in general. It's thou a different story that is
not mine to speak about.
Using 2-byte communities in today's age of explosive "assignment" of
4-byte ASN's is similar to the price-hike of IPv4 space. In the long
term. Standard BGP communities and IPv4 will not be worth the required
effort/investment (unless you want to "cripple" yourself from the
get-go). And IPv6 and Large BGP Communities is "slowly" gaining traction
as the way to go.
--
Cheers,
Chriztoffer
Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?
On Wed, 29 Jul 2020 at 18:06, Mark Tinka wrote: > On 29/Jul/20 16:54, Nick Hilliard wrote: > > it's a capability negotiation, so is handled on session setup. > > Meaning the initial setup would still require the use of literal IP addresses? Unless your (e.g. DC equipment) is set up for automatic bgp neighbour discovery using IPv6 ND+RA [2]. Then yes. [0]: https://github.com/FRRouting/frr/commit/04b6bdc0ee6275442464edec1d14b3f4d3eaa246 [1]: https://github.com/FRRouting/frr/search?p=3=hostname=Commits [2]: https://docs.cumulusnetworks.com/cumulus-linux/Layer-3/Border-Gateway-Protocol-BGP/#configure-bgp-unnumbered-interfaces -- Cheers, CHRIZTOFFER
Re: Mikrotik RPKI Testing
On Thu, 4 Jun 2020 at 16:13, Mike Hammett wrote: > I noticed that Mikrotik has added RPKI into their very much beta v7 branch. I > would like to ask those of you that know RPKI well to check it out and offer > Mikrotik feedback on what they've done right\wrong\broken. Promising development, indeed - MT RPKI Forum Topic: https://forum.mikrotik.com/viewtopic.php?f=2=81340=85bf0ab2fec75b418a070485e5a68741 - Changelog: https://mikrotik.com/download/changelogs/development-release-tree, https://forum.mikrotik.com/viewtopic.php?t=161980=797998 - Help page: https://help.mikrotik.com/docs/display/ROS/v7+Routing+Protocol+Status
[nanog] Re: Quagga for production?
Raymond Burkholder wrote: > On 2020-02-23 5:26 a.m., Dmitry Sherman wrote: >> Anybody working with Quagga for production peering with multiple peers >> and dynamic eBGP/iBGP announcement? >> > Free Range Routing (FRR) forked Quagga a few years back. I would say it > is the new Quagga. > > But either flavour handles multiple peers and full routing tables / DFZ > with aplomb. > > VYOS was Quagga, but now incorporates FRR, and is a good routing workhorse. PfSense, too. https://blog.vyos.io https://cumulusnetworks.com/blog/free-range-routing-anniversary/ https://www.cloudscale.ch/en/news/2017/11/27/new-border-routers-with-frr https://www.theregister.co.uk/2017/04/04/quagga_open_source_routing_resuscitated_as_free_range_routing/ https://mum.mikrotik.com/presentations/US19/presentation_6721_1554447941.pdf https://www.zdnet.com/article/internet-experiment-goes-wrong-takes-down-a-bunch-of-linux-routers/ <= Used by players as the bgp speaker on edge network nodes. Article is of the 'famous' experiment from last year. Were use of an experimental BGP code. Caused FRR bgp speakers to crash. The code error was since be corrected as an emergency hot-fix. https://news.ycombinator.com/item?id=18552425 -- Best regards, Chriztoffer
Re: NANOG 78 Webcasts
On Sat, 15 Feb 2020 at 20:40, Ana Tomasović wrote: > Is anyone able to access NANOG 78 playlist on YouTube or the webcast > URL? > > YouTube videos/playlist appear as private. Nope. -_- Wish they would keep the Day 1, Day 2, Day 3 videos online until the edited talks have been published. https://www.youtube.com/playlist?list=PLO8DR5ZGla8jSzWlrWt_cz13LLAz44rHY -- Chriztoffer
Re: Customer sending blackhole route with another provider's AS
Chris Adams wrote on 11/02/2020 17:30: > Just curious what others do... I always assumed AS path filtering to > customer (and their downstream customers) AS was a standard best > practice. It is. Then again, there exists every exception to the rule you can think of. If the exception has not been seen yet, we have not looked hard enough. => I.e. it depends. Is my answer. BCP is to not accept direct customer routes 'another provider's AS in the path'. If you can reach an agreement with the customer. You can agree to a >standardized< exception for this single customer. <= Your dice to roll. You are the customers upstream in this case. AS-path rewriting on the customers side of the eBGP connection is an option. If they remove $otherProviders ASN from the path before (re-)announcing the black-hole routes to you. So $customerASN is seen as the source when you receive the announcements. Chriztoffer
Re: Dual Homed BGP
fre. 24. jan. 2020 18.23 skrev Job Snijders : > > On Fri, 24 Jan 2020 at 17:40, Brian wrote: > > Am I crazy? >> > > I dropped out of university, never completed my psychology studies, I fear > I am unqualified to answer this question. ;-) > Education shopping, it is called by some. Chriztoffer >
Re: AS45102 Alibaba - lot networks with ROA wrong and invalid
Marco, tor. 16. jan. 2020 12.50 skrev Marco Paesani : > I need contact with AS45102 because there is a lot networks with ROA wrong > and invalid. > Nobody knows some technical people inside this AS ? > No succes using the contacts listed in their PeeringDB entry? https://www.peeringdb.com/net/6824 Chriztoffer >
Re: GEO IP Updates
Colin Legendre wrote on 06/08/2019 17:10: We updated... Maxmind, DB-IP, IP Info, IP Geolocation, IPHub. IP2location Any others we should update? $DAY_JOB previously had a case. Were it was necessary to contact Akamai. Because they have their own database. -- [ have you enabled IPv6 on something today...? ] [ Chriztoffer Hansen+1 914 3133553 ] [ 0x18dd23c550293098de07052a9dcf2ca008ebd2e8 ] signature.asc Description: OpenPGP digital signature
Re: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis
On 06/08/2019 05:20, Grant Taylor via NANOG wrote: > I did some sleuthing and just learned that OpenBSD's Common Address > Redundancy Protocol (also ported to other *BSDs and Linux) does support > an active/active configuration. > > I found some details in FreeBSD's carp(4) man page. Search said page > for "net.inet.carp.arpbalance". > > So … I'm going to need to do some pontification about CARP. }:-) Colour me surprised! Option is documented as early as the FreeBSD-5.4 carp(4) man pages. https://www.freebsd.org/cgi/man.cgi?query=carp=0=4=FreeBSD+5.4-RELEASE=default=html -- [ have you enabled IPv6 on something today...? ] [ Chriztoffer Hansen+1 914 3133553 ] [ 0x18dd23c550293098de07052a9dcf2ca008ebd2e8 ]
Re: Xfinity with IPv6 clue?
Janet, Did an actual person follow up with you privately after ipv6 got working on your connection? ... Or was it more like magic silence from their end. And suddenly it "just" worked? /Chriztoffer On 05/08/2019 04:00, Ross Tajvar wrote: > Did you get in touch with someone? What was the problem?
Re: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis
cyrus, cyrus ramirez wrote on 04/08/2019 21:40: If you're looking for vendor neutral FHRP, VRRP has RFC documentation. GLBP and HSRP are Cisco proprietary protocols and are protected information other than the study material and how too out there. The thing about the study material I know already. (have been through both ccna- and ccnp-level route/switch/design training material in recent 1-4 years) The question was simply about if GLBP/HSRP had ever been up in discussions in the IETF concerning publishing the protocol specifications as a standard. (As pointed out. I totally forgot about the RFC concerning HSRP.) Haven't gotten a response on the GLBP part. Which I am more than doubtful, myself, will ever come to fruition as a standard in an IETF WG. -- [ have you enabled IPv6 on something today...? ] [ Chriztoffer Hansen+1 914 3133553 ] [ 0x18dd23c550293098de07052a9dcf2ca008ebd2e8 ] signature.asc Description: OpenPGP digital signature
Re: [nanog] Cisco GLBP/HSRP question -- Has it ever been discussed to publish fully/in-part the specifications
Saku Ytti wrote on 03/08/2019 15:49: I don't think any work for GLBP exists in IETF. A shot in the dark. Correct. https://www.google.com/#q=%28"GLBP"%7C"Gateway+Load+Balancing"+Protocol%7C"Global+Load+Balancing"+Protocol%29+AND+inurl%3Adatatracker+AND+inurl%3Aietf (My IETF history is short. =I won't know any older history.) ... I doubt any current or previous Cisco folks on the list would want to chirm in about history from inside Cisco on the GLBP topic...(?) -- Best regards, Chriztoffer signature.asc Description: OpenPGP digital signature
[nanog] Cisco GLBP/HSRP question -- Has it ever been discussed to publish fully/in-part the specifications
Cisco has their FHR protocol specifications protected as proprietary IP. * Gateway Load Balancing Protocol (GLBP) * Hot Standby Router Protocol (HSRP) * https://packetlife.net/media/library/3/First_Hop_Redundancy.pdf Apart from the EIGRP specifications. Which has become publicly available in-part. Q: Anyone know about if the same has ever been discussed with regards to their HSRP and GLBP protocol specifications? -- Best regards, Chriztoffer signature.asc Description: OpenPGP digital signature
