Category: IP routing

Reliable ECMP with Static Routing

One of my readers wanted to use EIBGP to load balance outgoing traffic from a pair of WAN edge routers (hint: wrong tool for this particular job1). He’s using a design very similar to this one with VRRP running between WAN edge routers, and the adjacent firewall cluster using a default route to the VRRP IP address.

The problem: all output traffic goes to the VRRP IP address which is active on one of the switches, and only a single uplink is used for the outgoing traffic.

read more see 1 comments

When a Device Without an IP Address Wants to Play the IP Game

After I published the Source IP Address in Multicast Packets blog post, Erik Auerswald sent me several examples of network devices sending IP packets with source IP address set to 0.0.0.0:

read more see 3 comments

Spoofing ICMP Redirects for Fun and Profit

Security researches found another ICMP redirect SNAFU: a malicious wireless client can send redirects on behalf of the access point redirecting another client’s traffic to itself.

I’m pretty sure the same trick works on any layer-2 technology; the sad part of this particular story is that the spoofed ICMP packet traverses the access point, which could figure out what’s going on and drop the packet. Unfortunately, most of the access points the researchers tested were unable to do that due to limitations in the NPUs (a fancier word for SmartNIC) they were using.

add comment

Video: Link State Routing Protocol Basics

After introducing the routing protocols and explaining the basics of link-state routing it was time for implementation considerations including:

  • Collecting local endpoint reachability information
  • Finding neighbors and exchanging the collected information (hint: a link-state topology database is just a distributed key-value store)
  • Running the SPF algorithm (including partial SPF details) and installing the results
You need Free ipSpace.net Subscription to watch the video.
add comment

Source IP Address in Multicast Packets

One of my readers sent me this (paraphrased) question:

What I have seen in my network are multicast packets with the IP source address set to 0.0.0.0 and source port set to 0. Is that considered acceptable? Could I use a multicast IP address as a source address?

TL&DR: **** NO!!!

It also seemed like a good question to test ChatGPT, and this time it did a pretty good job.

read more see 2 comments

Why Is Source Address Validation Still a Problem?

I mentioned IP source address validation (SAV) as one of the MANRS-recommended actions in the Internet Routing Security webinar but did not go into any details (as the webinar deals with routing security, not data-plane security)… but I stumbled upon a wonderful companion article published by RIPE Labs: Why Is Source Address Validation Still a Problem?.

The article goes through the basics of SAV, best practices, and (most interesting) using free testing tools to detect non-compliant networks. Definitely worth reading!

add comment

DHCP Relaying in EVPN VRFs

After figuring out how DHCP relaying works and testing it with VRFs and in VXLAN segments, it seems like a no-brainer to make it work with EVPN.

TL&DR: It works, at least when using Arista vEOS as the relay and Cisco CSR 1000v as the DHCP server.

Lab Topology

We’ll keep using the exact same “physical” topology we used in the VXLAN DHCP relaying lab, add EVPN and BGP to the control-plane cocktail, and put the VXLAN segment into a VRF. We’ll use CSR 1000v as the DHCP server because Cisco IOSv doesn’t support some of the DHCP option-82 sub-options we need.

read more add comment

DHCP Relaying in VXLAN Segments

After I got the testing infrastructure in place (simple DHCP relay, VRF-aware DHCP relay), I was ready for the real fun: DHCP relaying in VXLAN (and later EVPN) segments.

TL&DR: It works exactly as expected. Even though I had anycast gateway configured on the VLAN, the Arista vEOS switches used their unicast IP addresses in the DHCP relaying process. The DHCP server had absolutely no problem dealing with multiple copies of the same DHCP broadcast relayed by different switches attached to the same VLAN. One could only wish things were always as easy in the networking land.

read more see 2 comments

Test VRF-Aware DHCP Relaying with netlab

After figuring out how DHCP relaying works and testing it in a simple lab, I went a step further and tested VRF-aware DHCP relaying.

Lab Topology

I had to make just a few changes to the DHCP relaying lab topology:

  • DHCP server is running on CSR 1000v. IOSv DHCP server does not support subnet selection DHCP option and thus doesn’t work with relays that do inter-VRF DHCP relaying.
  • I put the link between the DHCP client and DHCP relay into a VRF.
read more add comment

DHCP Relaying Details

Chinar Trivedi asked an interesting question about DHCP relaying in VXLAN/EVPN world on Twitter and my first thought was “that shouldn’t be hard” but when I read the first answer that turned into “wait a minute, how exactly does DHCP relaying works?

I’m positive there’s a tutorial out there somewhere, but I decided to go back to the sources of wisdom: the RFCs. It turned out to be a long walk down the IETF history lane.

read more see 2 comments

Worth Reading: Routing Protocol Implementation Evaluation

In 2018 I tried to figure out whether the rush to deploy new routing protocols in leaf-and-spine fabrics is anything more than another blob of hype (RIFT, OpenFabric, BGP), considering OSPF got the job done for AWS. Those discussions probably sounded like a bunch of smart kids trying to measure outside temperature with a moist finger, so the only recommendation I could give in 2021 was “use the best tool for the job, keeping in mind you’re not Google or Microsoft

It’s always better to measure than to have opinions, and a group of academics did just that. They developed Sybil – a tool to measure routing protocol performance in leaf-and-spine fabrics – and Dip Singh used it to compare BGP to IS-IS and OpenFabric.

add comment

Running Routing Protocols over MLAG Links

It took vendors like Cisco years to start supporting routing protocols between MLAG-attached routers and a pair of switches in the MLAG cluster. That seems like a no-brainer scenario, so there must be some hidden complexities. Let’s figure out what they are.

We’ll use the familiar MLAG diagram, replacing one of the attached hosts with a router running a routing protocol with both members of the MLAG cluster (for example, R, S1, and S2 are OSPF neighbors).

read more see 3 comments
Sidebar