Author Archives: Ivan Pepelnjak
Author Archives: Ivan Pepelnjak
A quick update BGP Labs project status update: now that netlab release 1.6.4 is out I could remove the dependency on using Cumulus Linux as the external BGP router.
You can use any device that is supported by bgp.session and bgp.policy plugins as the external BGP router. You could use Arista EOS, Aruba AOS-CX, Cisco IOSv, Cisco IOS-XE, Cumulus Linux or FRR as external BGP routers with netlab release 1.6.4, and I’m positive Jeroen van Bemmel will add Nokia SR Linux to that list.
If you’re not ready for a netlab upgrade, you can keep using Cumulus Linux as external BGP routers (I’ll explain the behind-the-scenes magic in another blog post, I’m at the Deep Conference this week).
For more details read the updated BGP Labs Software Installation and Lab Setup guide.
Features in netlab release 1.6.4 were driven primarily by the needs of my BGP labs project:
Numerous platforms already support the new BGP nerd knobs:
I’ll be talking about Internet routing security at the Deep conference in a few days, and just in case you won’t be able to make it1 ;) here’s the first bit of my talk: a very brief history of BGP route leaks2.
Note: you’ll find more Network Security Fallacies videos in the How Networks Really Work webinar.
After going through the BGP basics, it’s time to build a network that has more than one BGP router in it, starting with the simplest possible topology: a site with two WAN edge routers.
TL&DR: Violating the Betteridge’s Law of Headlines, the answer is “Yes, but the devil is in the details.”
It all started with the following observation by Minh Ha left as a comment to my previous BGP session security blog post:
I’d think it’d be obvious for BGP routers to only accept incoming sessions from configured BGP neighbors, right? Because BGP is the most critical infrastructure, the backbone of the Internet, why would you want your router to accept incoming session from anyone but KNOWN sources?
Following my “opinions are good, facts are better” mantra, I decided to run a few tests before opinionating1.
Bruce Schneier wrote a thoughtful article on the various perceptions of AI Risks including this gem:
As the science-fiction author Ted Chiang has said, fears about the existential risks of AI are really fears about the threat of uncontrolled capitalism, and dystopias like the paper clip maximizer are just caricatures of every start-up’s business plan.
Enjoy!
A few days after I published the EBGP session protection lab, Jeroen van Bemmel submitted a pull request that added TCP-AO support to netlab. Now that the release 1.6.3 is out, I could use it to build the Protect BGP Sessions with TCP Authentication Option (TCP-AO) lab exercise.
netlab release 1.6.3 added numerous BGP nerd knobs:
We also:
I encountered several articles explaining the challenges of simulating your network in a virtual lab in the last few months, including:
Enjoy!
Numerous Internet Exchange Points (IXP) started using VXLAN years ago to replace tradition layer-2 fabrics with routed networks. Many of them tried to avoid the complexities of EVPN and used VXLAN with statically-configured (and hopefully automated) ingress replication.
A few went a step further and decided to deploy EVPN, primarily to deploy Proxy ARP functionality on EVPN switches and reduce the ARP/ND traffic. Thomas King from DE-CIX described their experience on APNIC blog – well worth reading if you’re interested in layer-2 fabrics.
A few years ago, I was asked to deliver a What Is SDDC presentation that later became a webinar. I forgot about that webinar until I received feedback from one of the viewers a week ago:
If you like to learn from the teachers with the “straight to the point” approach and complement the theory with many “real-life” scenarios, then ipSpace.net is the right place for you.
I haven’t realized people still find that webinar useful, so let’s make it viewable without registration, starting with What Problem Are We Trying to Solve and What Is SDDC.
netlab release 1.6.2 improved reporting capabilities:
In other news:
In the BGP Route Aggregation lab you can practice:
Note: if you want to keep things simple, run BGP labs with netlab (other options).
If you’re monitoring the industry press (or other usual hype factories), you might have heard about Ultra Ethernet, a dazzling new technology that will be developed by the Ultra Ethernet Consortium1. What is it and does it matter to you (TL&DR: probably not2)?
As always, let’s start with What Problem Are We Solving?
A while ago I explained how Generalized TTL Security Mechanism could be used to prevent denial-of-service attacks on routers running EBGP. Considering the results published in Analyzing the Security of BGP Message Parsing presentation from DEFCON 31 I started wondering how well GTSM implementations work.
TL&DR summary:
Dip Singh wrote another interesting article describing how ECMP load balancing implementations work behind the scenes. Absolutely worth reading.
Lindsay Hill described an excellent idea: all ports on your switches routers should be in link aggregation groups even when you have a single port in a group. That approach allows you to:
It also proves RFC 1925 rule 6a, but then I guess we’re already used to that ;)
I always tell networking engineers who aspire to be more than VLAN-munging CLI jockeys to get fluent with Git. I should also be telling them that while doing local version control is the right thing to do, you should always have backups (in this case, a remote repository).
I’m eating my own dog food1 – I’m using a half dozen Git repositories in ipSpace.net production2. If they break, my blog stops working, and I cannot publish new documents3.
Now for a fun fact: Git is not transactionally consistent.
In the next BGP labs exercise you can practice tweaking BGP timers and using BFD to speed up BGP convergence.
I would strongly recommend using netlab to run BGP labs, but if you insist you can use any system you like including physical hardware.
After discussing names, addresses and routes, and the various addresses we might need in a networking stack, we’re ready to tackle an interesting comment made by a Twitter user as a reply to my Why Is Source Address Validation Still a Problem? blog post:
Maybe the question we should be asking is why there is a source address in the packet header at all.
Most consumers of network services expect a two-way communication – you send some stuff to another node providing an interesting service, and you usually expect to get some stuff back. So far so good. Now for the fun part: how does the server know where to send the stuff back to? There are two possible answers1: