[HN Gopher] BGP handling bug causes widespread internet routing ...
___________________________________________________________________
BGP handling bug causes widespread internet routing instability
Author : robin_reala
Score : 236 points
Date : 2025-05-27 11:15 UTC (11 hours ago)
(HTM) web link (blog.benjojo.co.uk)
(TXT) w3m dump (blog.benjojo.co.uk)
| mgaunard wrote:
| Does multicast over the Internet even work?
|
| I thought BGP was only for private networks.
| FL410 wrote:
| BGP is very much not only for private networks - it is what the
| internet is built on.
|
| Maybe you are thinking of iBGP or something like OSPF?
| Alifatisk wrote:
| No, BGP is not only for private networks. ASNs use it to
| exchange messages between each other.
| bc569a80a344f9c wrote:
| BGP is the routing protocol of the Internet. There effectively
| is no other choice of routing protocol between autonomous
| systems. A reasonable synonym for "Internet" is "the global BGP
| routing table".
|
| BGP also doesn't use multicast, you may be thinking of OSPF on
| multiaccess networks. BGP uses tcp/179 unicast to the IP
| addresses of its configured peers.
|
| That said, multicast works just fine over the Internet. It's
| not commonly used, certainly not by home users and not very
| often by enterprise users, and was phased out on Internet2 by
| 2021 (I think?), but there's absolutely nothing in principle
| that would make it not work.
| ai-christianson wrote:
| Anycast is pretty useful on the Internet :)
| bc569a80a344f9c wrote:
| Anycast is a very different beast, though. Anycast is just
| unicast but you announce the same IP space from multiple
| destinations, and the network figures out how to get a
| packet to the closest one. If one of those destinations
| fails, it just goes to the next closest one.
|
| Unicasts, multicasts, and broadcasts all actually work
| differently underneath and require specific handling by
| network equipment. Anycast is just a special case of
| unicast and generally speaking network equipment is
| completely unaware of it.
| rnxrx wrote:
| FWIW, 100% that BGP itself doesn't *use* multicast, but it
| can *propagate* multicast routing information. It's certainly
| technically possible to support multicast on the Internet
| (..thus the invention of MBGP) but in practice has been a
| non-starter for a whole bunch of reasons.
| toast0 wrote:
| > That said, multicast works just fine over the Internet.
| It's not commonly used, certainly not by home users and not
| very often by enterprise users, and was phased out on
| Internet2 by 2021 (I think?), but there's absolutely nothing
| in principle that would make it not work.
|
| In principle, no. In practice, I don't think many ISPs have
| equipment configured to forward multicast, except for those
| using multicast for TV and those probably don't interconnect
| with others.
| ta1243 wrote:
| Many years ago UK ISPs particpated in an MBone with BBC,
| ITV etc providing live broadcast
|
| https://www.bbc.co.uk/multicast/tv/channels.shtml
|
| Brandon Butterworths note about "why"
|
| https://support.bbc.co.uk/multicast/why.html
|
| Shows the growth of the backbone and CDNs:
|
| > The Olympic audience is expected to be around 50K
| streams, delivering 10Gbit+ is on the limit of sensible
| unicast delivery.
|
| In 2020 the BBC's internal CDN was delivering 100 times
| that [0] for 250k users, and 5 years later I suspect it's
| another order of magnitude given that iplayer does 5
| million concurrent live views quite frequently [1,2]
|
| [0] https://medium.com/bbc-product-technology/bbc-
| online-2020-in...
|
| [1] https://www.bbc.co.uk/mediacentre/2024/audiences-flock-
| to-bb...
|
| [2] https://www.bbc.co.uk/mediacentre/2022/england-v-iran-
| bbc-li...
|
| By 2035 and TV turnoff there's no reason to believe that
| the infrastructure won't have been able to scale another
| 100 fold and handle 500 million concurrent live streams.
| Makes no sense to multicast out 30 different formats, to
| people on phones and tablets and TVs hanging off wifi. It's
| a very different consumer experience than a PC wired into
| an ISP like it was in 2007.
| immibis wrote:
| It's sort of correct and sort of incorrect to say it's the
| only possible routing protocol between autonomous systems.
| Since many inter-AS connections are effectively made-to-
| order, they could use a different protocol, but in order to
| participate in the global BGP mesh, it would have to have
| semantics similar enough to BGP. Most notably, it would have
| to support the concept of AS-path. However I don't think
| there are any universal requirements beyond that. BGP isn't a
| single distributed algorithm like say OSPF - a completely
| separate instance of BGP runs between every pair of connected
| ASes and they share some data, indirectly forming a global
| system.
| tonetegeatinst wrote:
| Unsure about multicast...my gut would say no but I'd not trust
| that answer if I had to bet on it.
|
| BGP is the only way I know of that autonomous Systems can talk
| to each other and negotiate.
| patmorgan23 wrote:
| All traffic over the Internet is routed by routes that have
| been propagated through BGP. It's how adjacent networks tell
| each other what IPs they originate, and what networks they are
| connected to.
| Hikikomori wrote:
| The "Internet" is a bunch of separate networks operated by
| different entities. BGP is what allows them to connect to each
| other by exchanging routing formation.
|
| There was something called the mbone back in the day. Nowadays
| you can't really send random multicast, but its very much in
| use by ISPs for IPTV.
| ta1243 wrote:
| The standard approach is be liberal in what you accept and be
| specific in what you emit.
|
| You could
|
| 1) Filter the broken message
|
| 2) Drop the broken message
|
| 3) Ignore the broken attributes but pass them on
|
| 4) Break with the broken attributes
|
| To me, only 4 (Arista) is the really unacceptable behaviour. 3
| (Juniper) isn't desirable but it's not a devastating behaviour.
|
| EDIT: Actually rereading it, Arista did 2 rather than 4. I think
| it just closed the connection as being invalid rather than
| completely crash. That's arguably acceptable, but not great for
| the users.
| klysm wrote:
| I disagree with this approach. Being very very specific in what
| you accept and very very specific in what you emit seems better
| to me.
| tinco wrote:
| That's in conflict with the philosophy behind the internet.
| If you'd just drop anything because some part of it you don't
| understand, you lose a lot of flexibility. You have to keep
| in mind that some parts of the internet are running on 20
| year old hardware, but some other parts might work so much
| better if some protocol is modified a little. Just like with
| web browsers, if everything is a little bit flexible in what
| they accept, you both improve the smoothness of the
| experience and create room for growth and innovation.
| bluGill wrote:
| There is a place for both. The accept everything model made
| some extensions better, but it also allowed for various
| malware when junk was accepted.
| colejohnson66 wrote:
| Postel's law doesn't mean "accept everything", but that
| you should accept de-facto rules people have created. If
| everyone says, "this is how we do it", you should ignore
| the RFC and just copy what others do.
| bluGill wrote:
| There are several problems with that.
|
| One, if everyone is doing something different from the
| spec it is hard to figure out what they are really doing
| and what they mean. Long term you have confidence things
| will continue to work even when someone else writes their
| own version which otherwise might also deviate from the
| spec.
|
| Two, it is easier to modify the spec as more features are
| dreamed up if you have confidence that the spec is boss
| meaning someone else didn't already use that field for
| something different (which you may not have heard about
| yet).
|
| Three, if you agree to a spec you can audit it (think
| security), if nobody even knows what the spec is that is
| much harder.
|
| Following the spec is harder in the early days. You have
| to put more effort into the spec because you can't
| discover a problem and just patch it in code. However the
| internet is far past those days. We need a spec that is
| the rule that everyone follows exactly.
| SAI_Peregrinus wrote:
| Postel's Law is important, but it creates brittle systems.
| You can force them further from the ideal operating state
| before failure, but when they fail they tend to fail
| suddenly and catastrophically. I like to call it the
| "Hardness Principle" as opposed to the "Robustness
| Principle" in analogy to metallurgy.
| arccy wrote:
| This is so wrong, read up on
| https://datatracker.ietf.org/doc/html/rfc9413
|
| The internet is ossified because middleboxes stick their
| noses where they shouldn't. If they just route IP packets,
| we could have had nice things like SCTP...
| bolognafairy wrote:
| Alright. See you over on the XHTML Internet. Oh, wait.
| hinkley wrote:
| If the iPhone had come out just a little bit later I think
| xhtml-basic would have gotten more traction. It was pretty
| nice to implement.
| debugnik wrote:
| XHTML still lives on in the epub spec. I kinda wish we had
| an "epub web".
| oblio wrote:
| HTML is a nightmare that had to be reverse engineered as
| in, rebuilt with proper engineering standards in mind,
| several times. HTML and CSS are both quite horrible.
| hombre_fatal wrote:
| Browsers are permissive not because it's technically
| superior but as a concession for the end user who still
| wants to be able to use a poorly built website, and they're
| competing with browsers who will bend over backwards to
| render that crappy website so that they look good and your
| browser looks bad.
|
| It's not a concession you want to make unless you really
| have to.
| erincandescent wrote:
| Being that prescriptive is fundamentally unworkable in
| practice. Propagating unknown attributes is fundamentally
| what made the deployment of 32-bit AS numbers possible
| (originally RFC 4893; unaware routers pass the `AS4_PATH`
| attribute without needing to comprehend it), large
| communities (RFC 8092), the Only To Customer attribute (RFC
| 9234) and others.
|
| A BGP Update message is mostly just a container of Type-
| Length-Value attributes. As long as the TLV structure is
| intact, you should be able to just pass on those TLVs without
| problems to any peers that the route is destined for.
|
| The problem fundamentally is three things:
|
| 1. The original BGP RFC suggests tearing down the connection
| upon receiving an erroneous message. This is a terrible idea,
| especially for transitive attributes: you'll just reconnect
| and your peer will resend you the same message, flapping over
| and over, and the attribute is likely to not even be your
| peer's fault. The modern recommendation is Treat As Withdraw,
| i.e. remove any matching routes from the same peer from your
| routing table.
|
| 2. A lack of fuzz testing and similar by BGP implementers
| (Arista in this case)
|
| 3. Even for vendors which have done such testing, a number of
| have decided (IMO stupidly) to require you to turn on these
| robustness features explicitly.
| hinkley wrote:
| PNG solved this problem when BGP was still young: each
| section of an image document is marked as to whether
| understanding it is necessary to process the payload or
| not. So image transform and palette data is intrinsic, but
| metadata is not. Adding EXIF for instance is thus made
| trivial. No browser needs to understand it so it can be
| added without breaking the distribution mechanism.
| zajio1am wrote:
| This is also how BGP (mostly) solved it. Each attribute
| has 'transitive' bit. Unknown attributes with
| 'transitive' bit set are passed, one without are
| discarded.
| Diggsey wrote:
| You're suggesting that being liberal in what you accept is
| necessary for forward evolution of the protocol, but I
| think you're presenting a false dichotomy.
|
| In practice there are many ways to allow a protocol to
| evolve, and being liberal in what you accept is just about
| the worst way to achieve that. The most obvious alternative
| is to version the protocol, and have each node support
| multiple versions.
|
| Old nodes will simply not receive messages for a version of
| the protocol they do not speak. The subset of nodes
| supporting a new version can translate messages into older
| versions of the protocol where it makes sense, and they can
| do this because they speak the new protocol, so can make an
| intelligent decision. This allows the network to function
| as a single entity even when only a subset is able to
| communicate on the newer protocol.
|
| With strict versioning and compliance to specification,
| reference validators can be built and fitted as barriers
| between subnetworks so that problems in one are less likely
| to spread to others. It becomes trivial for anyone to
| quickly detect problems in the network.
| sc68cal wrote:
| The problem is that folks took advantage of the behavior of BGP
| where it would forward unknown attributes that the local device
| didn't understand, as a means to do all sorts of things
| throughout the network. People now rely on that behavior.
|
| Now, we're experiencing the downside of this "feature"
| spwa4 wrote:
| BGP has classes attributes that it forwards. While it is true
| that it forwards route attributes it doesn't know about, this
| was an attribute that it DID know about and knows it
| shouldn't forward.
|
| In fact it's a bit strange just how lenient Juniper's
| software was here. If a session is configured as IBGP on one
| end and EBGP on the other end, it should never get past the
| initial message. Juniper not only let it get past the
| connection establishment but forwarded obviously wrong
| routes.
| sc68cal wrote:
| Yes but you are seeing a symptom of what I believe is a
| fundamental design decision to be liberal in passing on
| data and then _later_ go through and build logic that stops
| certain things from being forwarded, and the result is that
| things slip through the cracks that shouldn't.
|
| Rather than the inverse where you only forward things
| explicitly and by default do not forward.
| icehawk wrote:
| As far as I'm aware "a session is configured as IBGP on one
| end and EBGP on the other end" isn't possible.
|
| You can't configure it like that, most of the BGP
| implementations I'm familiar with automatically treat the a
| same-AS neighbor as iBGP and a different-AS neighbor as
| eBGP.
|
| Juniper explicitly has 'internal' and 'external' neighbors,
| but you can't configure a different peer AS than your own
| on an internal neighbor or the same peer AS on an external
| neighbor.
|
| BGP sessions also have the AS of the neighbor specified in
| the local config, and will not bring up the session if it's
| not what's configured.
| zajio1am wrote:
| Without this behavior it would be impossible to deploy newer
| BGP attributes globally.
| sc68cal wrote:
| I understand that, but it's a double edged sword. We
| enjoyed that flexibility for a long time, but lately we are
| now experiencing the downsides of this flexibility.
| ExoticPearTree wrote:
| Arista did 2, but it also dropped the whole connection which
| was probably bad.
|
| IMHO, just drop the broken attributes in the message and log
| them, and pass on the valid data if there's any left. If not,
| pretend you did not receive an UPDATE message from that
| particular peer.
|
| Monitoring will catch the offending originator and people can
| deal with this without having to deal with any network
| instability.
| eqvinox wrote:
| In case you want to calibrate your sense of armchair-ness:
| you have completely missed the point that discarding an
| individual attribute can quite badly change the meaning of a
| route, and since we're talking about the DFZ here, such
| breakage can spread around the planet to literally every DFZ
| participant. The only safe thing you can do is to drop the
| entire route. Maybe there _was_ a point to this being
| discussed at quite some length by very knowledgeable people,
| before 7606 became RFC ;)
|
| (I haven't downvoted your comment, but I can see why others
| would -- you're making very simple and definite statements
| about very complicated problems, and you don't seem to be
| aware of the complications involved. Hence: your calibration
| is a bit off.)
| ExoticPearTree wrote:
| Funny enough, I actually have a few routers with a DFZ, so
| I have an idea or two about how BGP works.
|
| My point is that:
|
| - if you drop a connection, especially one through which
| you announce the full routing table, it is going to create
| a lot of churn to your downstreams. Depending on the kind
| of routers they use, it can create some network instability
| for quite a while. And if you drop it again when you
| receive that malformed route, the instability continues
|
| - removing only the malformed attribute maybe changes the
| way you treat traffic but you still route it. OK, you send
| it to maybe another interface, but no biggie
|
| - if you're using a DFZ setup, dropping that single route
| could blackhole traffic to that destination if you're the
| only upstream to another router
| billfor wrote:
| Author makes this point in a related post:
|
| At a glance this "feature" seems like an incredibly bad idea,
| as it allows possibly unknown information to propagate blindly
| through systems that do not understand the impact of what they
| are forwarding. However this feature has also allowed
| widespread deployment of things like Large Communities to
| happen faster, and has arguably made deployment of new BGP
| features possible at all.
| zajio1am wrote:
| There is already RFC 7606 (Revised Error Handling for BGP
| UPDATE Messages), which specifies in detail how broken BGP
| messages should be handled.
|
| The most common approach is 'treat-as-withdraw', i.e. handle
| the update (announcement of a route) as if it was a withdraw
| (removal of previously announced route). You should not just
| drop the broken message as that whould lead to keeping old, no
| longer valid state.
| eqvinox wrote:
| All of this is understood and has been discussed to death, it's
| just that Arista didn't implement the agreed-best approach
| (RFC7606) correctly.
| hannob wrote:
| > The standard approach is be liberal in what you accept and be
| specific in what you emit.
|
| What you're paraphrasing here is the so-called "robustness
| principle", also known as "Poestel's law". It is an idea from
| the ancient history of the 1980s and 09s Internet. Today, it's
| widely understood that it is a misguided idea that has led to
| protocol ossification and countless security issues.
| senderista wrote:
| Postel's Law certainly has led to a lot of problems, but is
| it really responsible for protocol ossification? Isn't the
| problem the opposite, e.g. that middleboxes are _too_ strict
| in what they accept (say only the HTTP application protocol
| or only the TCP and UDP transport protocols)?
| fc417fc802 wrote:
| Overly strict and overly liberal both lead to ossification.
| That's merely the observation that buggy behavior in either
| direction can potentially come to be relied on (or to be
| unpredictably forced on you, in the case of middleboxes
| filtering your traffic).
|
| I'd only expect security issues to result from being overly
| liberal but 1. I wouldn't expect it to be very common and
| 2. I'm not at all convinced that's a compelling argument to
| reduce the robustness of an implementation.
| thaumasiotes wrote:
| It's a description of how natural language is used, so what
| you'd expect is constant innovation, with protocols
| naturally developing extensions that can only be understood
| within local communities, even though they aren't supposed
| to.
|
| Something like "this page is best viewed in Internet
| Explorer" as applied to HTML.
| arccy wrote:
| see
| https://datatracker.ietf.org/doc/html/rfc9413#section-4.2
| fc417fc802 wrote:
| > Today, it's widely understood that ...
|
| Widely claimed by some but certainly not "widely understood"
| because such phrasing implies a lack of controversy regarding
| the claim that follows it.
| oblio wrote:
| It's kind of common sense, though. Look at HTML. So
| badly/under defined that it wasn't even testable for close
| to 2 decades.
|
| The sane approach is to be strict and provide great error
| messages.
| fuddy wrote:
| This "sane" approach lost to HTML.
| arccy wrote:
| It's good enough to be RFC 9413
| https://datatracker.ietf.org/doc/html/rfc9413
|
| And people who disagree are just wrong.
| AdamJacobMuller wrote:
| I would perhaps argue that juniper's behavior is the preferable
| one.
|
| Remember the definition of this "drop the message I think is
| broken" not inherently "drop the broken message," it's entirely
| plausible that the message is fine but you have a bug which
| makes you THINK it's a broken message.
|
| There is also a huge difference between considering it a broken
| message and a broken session, which is what Arista did.
| dakiol wrote:
| Is it just me or BGP is something I never learnt about until I
| heard about it causing issues? It seems it's essential to the
| internet, just like TCP/IP, but nevertheless I learnt about the
| latter in the university, during my career, I read many books
| about TCP/IP... but nothing about BGP (not in the university, not
| at work, not in books, nothing).
|
| I can "play" with TCP/IP at home in dummy projects and learn more
| about it... but I have no idea how to "play" with BGP. In that
| regard, how does one learn about it at home?
| klysm wrote:
| It's very much hidden, which I guess is a success of the
| design. You need not concern yourself with the web of ASNs when
| using IP.
| altilunium wrote:
| I think you need to manage a real (and large) network that's
| connected to global internet traffic in order to "play" with
| BGP. Well, you can tinker with it at home, but only by using a
| network simulator.
| bc569a80a344f9c wrote:
| You can set up local BGP routers and peer them and play with
| it.
|
| Another fun thing is to log into publicly available looking
| glass servers. Most ISPs (including very, very, very large
| ones) operate routers that have their full view of the BGP
| routing tables. They either run web interfaces that let you
| query those tables (more common) or make public ssh or telnet
| credentials to log in with roles that have very limited
| access to the available commands, but have read rights to
| those tables.
| _gmax0 wrote:
| Internet researchers commonly use RIPE and RouteViews.
|
| https://www.routeviews.org/routeviews/about/
| https://stat.ripe.net/docs/02.data-api/
| ta1243 wrote:
| I've used BGP internally at my company for a decade, using
| AS65xxx range. At home I use BGP between the house, garage
| and shed, I much prefer it to OSPF.
| normie3000 wrote:
| Should we know what OSPF is too?
| icedchai wrote:
| Unless you're heavily into networking and the ISP space,
| there's basically no need for you to know about routing
| protocols.
| pixl97 wrote:
| Depends if you do any routing on multipath networks. Most
| people don't so there's that.
| Hikikomori wrote:
| ECMP? Can do that with static routes. As long as you have
| more than 1 router you could set up a routing protocol.
|
| Or did you mean multipoint?
| unethical_ban wrote:
| Open Shortest Path First (OSPF) is an "internal" routing
| protocol. Basically, it is a protocol for routers to
| share routes when all routers are managed by the same
| organization.
|
| Border Gateway Protocol (BGP) has the primary purpose of
| sharing routes between routers managed by different
| organizations. It can be used within an organization too.
| It has a lot more control over how and which routes it
| sends and receives.
| ta1243 wrote:
| Depends how much you want to know about how networks
| work. Never ceases to amaze me how ignorant modern
| software developers are of the underlying technology, I
| guess that's because I'm from the pre-2010s when
| "Information Technology" was a general field.
| unethical_ban wrote:
| I took some comp-sci and majored in "IT" in the 2000s.
| Lower level CS did not go over routing protocols, and the
| IT side never got into compilation, linking, state
| machines, or pointers.
| edoceo wrote:
| Missed pointers!? Surprised me. (Am old)
| ta1243 wrote:
| In the 2000 my team had to deal with everything from
| compilation problems to hardware answering arp answers
| with fake mac addresses. The team consisted of a wide
| range of skills and abilities and information obviously
| leaks. While the DBA didn't need to know anything about
| OSPF, just by being in the same team as the network
| person they pick up how things work.
|
| Now it seems that teams seem to be far more specialised
| and there's less cross-specialist learning.
| normie3000 wrote:
| > Never ceases to amaze me how ignorant modern software
| developers are of the underlying technology, I guess
| that's because I'm from the pre-2010s
|
| Don't let my ignorance color your opinion of the youth of
| today.
| Bluecobra wrote:
| Same! At previous company I worked at we used BGP for all
| internal/external routing about 15 years ago despite all
| the poo-pooing by using BGP as an IGP. It was nice having
| no route redistribution and one command to monitor
| sessions.
| l_vorenus wrote:
| BGP is chill and robust, OSPF is correct and fast. Both
| have their own place in a network.
| buzer wrote:
| On top of the already suggested local BGP routers you can
| also use https://dn42.us/ to test a bit more real-world like
| scenarios.
| icedchai wrote:
| It doesn't have to be that large. Many people have "personal"
| ASNs.
|
| Check out this blog (not me, I just remember it from years
| back): https://blog.thelifeofkenneth.com/2017/11/creating-
| autonomou...
| azinman2 wrote:
| Really interesting post! Thanks for sharing
| Orochikaku wrote:
| The author spoke about this story on my favourite podcast,
| On The Metal (of Oxide Computer Company)
|
| https://onthemetal.transistor.fm/episodes/kenneth-finnegan
| wildzzz wrote:
| I worked an internship where I spent the summer setting up
| new equipment for a large corp that was replacing
| everything that AT&T had installed and managed with their
| own stuff. Nearly every office had their own ASN, everyone
| else got regular broadband or just a box of aircards
| depending on the number of users. I knew nothing about
| networks other than setting up my own consumer router at
| home so it was a pretty fun learning experience. I always
| got a smile on my face when I finally got vRouter to peer
| with our dummy AS in the office then we'd pack it all up
| and bring it out for installation over the weekend. I got
| offered a job to come back after I graduated but turned it
| down for something that paid better and was a lot more
| interesting. Honestly, I probably would be making more
| money as a network engineer now if I stuck with it.
| Bluecobra wrote:
| You don't need a large network to participate to BGP. You
| just need a /24 (IPv4) or /48 (IPv6) allocation, AS number,
| and a business class Internet connection that can do BGP.
| Might be out of reach for most hobbyists but not impossible.
| icedchai wrote:
| You don't even need a business class connection. You can do
| BGP over a tunnel to a VPS or colo.
| Hikikomori wrote:
| Not really, you can learn it just fine with simulators and a
| few routers. Designing and operating BGP in a large network
| is another thing though.
| bc569a80a344f9c wrote:
| Buy some routers that have BGP implementations (there are some
| cheap ones, Mikrotik for example), or use open source
| implementations. The article lists bird, another very popular
| one is FRR (free range routing). You can trivially stand up two
| docker containers, stand up a BGP session between them, and -
| for example - propagate static routes you set up within them.
|
| If you like guided tutorials,
| https://blog.ipspace.net/2023/08/bgp-labs-basic-setup/ is
| rather good and has been extended to somewhat advanced topics.
| Everything needed to follow along is free software.
| remram wrote:
| A good tool to try this stuff is containerlab:
| https://containerlab.dev/
|
| It lets you setup multiple containers with direct connections
| between them in whatever topology you want. It allows you to
| run both Linux containers (with FRR for example) and emulated
| versions of popular router platforms (some of the ones
| mentioned in the article).
| SoftTalker wrote:
| OpenBSD include bgpd(8) out of the box:
| DESCRIPTION bgpd is a Border Gateway Protocol (BGP)
| daemon which manages the network routing tables.
| Its main purpose is to exchange information concerning
| "network reachability" with other BGP systems. bgpd uses the
| Border Gateway Protocol, Version 4, as described in
| RFC 4271.
| zokier wrote:
| At least to me one of the challenges is relating to the
| problems that BGP solves. You can get pretty far in network
| complexity before BGP (or OSPF etc) really does anything for
| you. What would be good scenarios one could encounter in
| "homelab" situation where BGP would be beneficial?
| pixl97 wrote:
| So back when I did Wisp stuff I'd set up simulates networks
| between multiple machines with real and virtual networks. VyOS
| which was similar to the UBNT equipment we were using is light
| weight and supports multiple protocols.
| kalaksi wrote:
| Well, what did you study in the university? I did learn about
| BGP and routing in university since one of my subjects was
| information networks and protocols. But haven't really used it
| outside of some lab exercises since there's been no need at
| work nor at home.
| ecshafer wrote:
| My undergraduate networking course didn't touch BGP, my
| graduate networking course did touch BGP. We used a python
| package that acted as a simulator for different AS but I can't
| remember which one.
| acc_297 wrote:
| My undergrad networks course discussed a little BGP stuff but
| only on the blackboard.
|
| To experiment with BGP you could use a network simulator like
| what the author of this blog did. In my class we used something
| called gini[1] which I think my profs grad student wrote but
| the author apparently used gns3 which seems to be a cisco
| specific ns3 version. I used ns3 once and found it had a steep
| learning curve. The gini simulator has a more basic user
| interface but is probably less powerful.
|
| [1] https://citelab.github.io/gini5/ [2]
| https://docs.gns3.com/docs/
| mfro wrote:
| DN42[1] provides a playground for routing technologies. I
| wouldn't recommend digging in if you don't want to dedicate a
| lot of time into it. As someone fairly well versed in
| networking, WAN routing is still confusing to me.
|
| GNS3 is probably the easiest way to get hands on experience
| with any networking technologies.
|
| [1]: https://wiki.dn42.us/home
| unethical_ban wrote:
| TCP/IP affects every networked application and endpoint on the
| internet.
|
| BGP runs the internet routing "in the background" and you only
| need to know it if you're an internet service provider or work
| in a large org managing the network. If you didn't learn
| network routing, you aren't going to learn BGP.
|
| Put two or three VMs (OpenBSD has OpenBGPD daemon) onto a
| shared virtual switch and addresses in 172.31.255.0/24, connect
| the VMs. Also each of the VMs should have at least one other
| interface onto unique virtual switches with their own network
| (172.31.1.0/24, 172.31.2.0/24, etc).
|
| Then set up BGP to redistribute connected routes.
| ajsnigrutin wrote:
| BPG is like international shipping... it has to be there for
| the world to function, but most people don't need to interact
| with it.
|
| One way to play with it is something like this:
| https://www.eve-ng.net/
|
| The other is to make a couple of virtual machines with a couple
| of network interfaces, make some sort of network betweeen them
| and then use some bgp routing deamon, eg:
|
| https://bird.network.cz/
|
| https://www.nongnu.org/quagga/
|
| etc.
| elij wrote:
| if you're a linux person consider a routing on host setup with
| FRR with /32s. As every host is a /32 network you can focus
| more on the aspects of BGP rather than TCP/IP.
| mzsl wrote:
| In my opinion, containerlab is one of the easier tools to setup
| a lab environment for networking. You define a network with
| yaml which consists of nodes and links between them and it
| creates these using docker. They also have a BGP peering
| example lab: https://containerlab.dev/lab-examples/peering-lab/
| toast0 wrote:
| When has BGP not been implicated in causing issues though?
|
| The first widespread incident I found was from 1997 [1], but I
| didn't look too hard.
|
| I don't think there's really a satisfying way to play with BGP
| as a small network. Traffic engineering is where I think the
| fun would be, but you've got to have lots of traffic and many
| connections for it to be worthwhile. Then you'd be trying to
| use your announcements to coax the rest of the internet to push
| packets through the connections you want. As well as perhaps
| adjusting your outgoing packets to travel the connections you
| prefer when possible. Sadly, nobody lets me play with their
| setup.
|
| One of the ways to get a sense of emergent routing behavior is
| if you have hosting in many places, you'll likely see a lot of
| differences in routes when you start going to far off
| countries. If you run traceroutes (or mtr) from your home
| internet and your cell phone and various hosting, and if you
| can trace back... you'll likely see a diversity of routes.
| Sometimes you'll see things like going from west coast US to
| Brazil, where one ISP will send your packets to florida, then
| Brazil, and one ISP will send your packets to Spain, then
| Brazil, with a lot more latency.
|
| [1] https://en.m.wikipedia.org/wiki/AS_7007_incident
| immibis wrote:
| You can play with BGP by joining https://dn42.eu/ - a fake
| internet with a few thousand participants who are mostly as
| clueless as you, and none of whom will lose millions of
| dollars per hour if it breaks (which is not infrequently).
| moefh wrote:
| I still remember when Pakistan accidentally shut down YouTube
| in the entire world for about 2 hours in 2008:
| https://www.cnet.com/culture/how-pakistan-knocked-youtube-
| of...
| nikanj wrote:
| I remember Helsinki CS having quite a bit of BGP, TCP and both
| ipv4 and ipv6. No guarantees that every student aced those
| classes, but the teaching definitely was there
| protocolture wrote:
| Its hard to get real hands on BGP experience.
|
| A lab wont ever reflect the complexity of a carrier
| environment.
|
| That said, just bang a couple of mikrotiks together if you want
| to play with it.
| sc68cal wrote:
| I still remember the mad scramble we had to fix CVE-2023-4481
| across our entire network. This class of bugs is going to be an
| absolute nightmare to deal with, and because of the way BGP has
| been designed & implemented, it is going to take a _long_ time to
| fix these kinds of behaviors.
| alecco wrote:
| HGC Global Communications Limited, formerly known as Hutchison
| Global Communications Limited (abb. HGC), is an internet service
| provider of Hong Kong.
|
| https://en.wikipedia.org/wiki/HGC_Global_Communications
| mintflow wrote:
| I was developping BGP feature in a telco vendor though it's
| decades ago.
|
| Still think BGP is too complex and people keeping add new
| features and vendors keeping implement it based on RFC standard
| or draft.
|
| And it seems BGP will never be deprecated so this sort of bugs
| will continue be found again and again...
| incomingpain wrote:
| Our IOS XR chassis' have gotten some of these packets.
| Corresponding with high bgp route advertisements. No idea what
| equipment upstream uses tbh.
|
| Makes me wonder if the BGP protocol is properly fuzzed. Perhaps
| its one of those things that everyone is scared to try to knock
| over given it's so important.
|
| I suppose it would be easy to write a fuzzer for bgp but very
| hard to diagnose crashes?
| benjojo12 wrote:
| (author of the post)
|
| Yes, this is exactly what I did in the post I linked to:
| https://blog.benjojo.co.uk/post/bgp-path-attributes-grave-er...
| incomingpain wrote:
| Bravo!
|
| This is great research!
| bhaney wrote:
| > At 7AM (UTC) on Wednesday May 20th 2025
|
| May 20th was a Tuesday, just sayin'
| benjojo12 wrote:
| Great catch, there were like 3 mini incidents this week that I
| was keeping track of, so wires got crossed, will correct the
| post in a moment
| ta1243 wrote:
| Although at 7AM UTC in some parts of the world it was a Monday
| :D
| saghm wrote:
| Yes, but in those parts of the world it also wasn't May 20 at
| that time
| mschuster91 wrote:
| Well surprise, people cheat because an academic degree is yet
| another checkbox to be ticked in the ever more grueling list of
| tasks needed to be done to acquire a job that has even a remote
| chance of paying a living wage.
|
| Fix that, so that only those actually interested in academia per
| se and not just because they need a checkbox to tick remain, and
| the problem with cheating in academia will collapse.
| CSN3RD wrote:
| Several vendors had this bug in the past
| https://www.kb.cert.org/vuls/id/347067
|
| CVE-2023-4481 (Juniper) CVE-2023-38802 (FRR) CVE-2023-38283
| (OpenBGPd) CVE-2023-40457 (EXOS)
|
| Arista was not affected then.
___________________________________________________________________
(page generated 2025-05-27 23:00 UTC)