Archive

Category Archives for "ipSpace.net"

Video: What Is Software-Defined Data Center

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.

You need at least free ipSpace.net subscription to watch videos in this webinar.

netlab 1.6.2: More Reporting Goodies

netlab release 1.6.2 improved reporting capabilities:

  • BGP reports and IP addressing reports are fully IPv6-aware
  • Some columns in BGP reports are optional to reduce the width of text reports
  • You can filter the reports you’re interested in when using netlab show reports command
  • Reports relying on ipaddr Ansible filter display warnings (instead of crashing) if you don’t have Ansible installed.

In other news:

netlab 1.6.2: More Reporting Goodies

netlab release 1.6.2 improved reporting capabilities:

  • BGP reports and IP addressing reports are fully IPv6-aware
  • Some columns in BGP reports are optional to reduce the width of text reports
  • You can filter the reports you’re interested in when using netlab show reports command
  • Reports relying on ipaddr Ansible filter display warnings (instead of crashing) if you don’t have Ansible installed.

In other news:

What Is Ultra Ethernet All About?

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?

What Is Ultra Ethernet All About?

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?

How GitHub Saved My Day

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.

How GitHub Saved My Day

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.

Why Do We Need Source IP Addresses in IP Headers?

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:

Why Do We Need Source IP Addresses in IP Headers?

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:

Does EVPN/VXLAN over SD-WAN Make Sense?

It looks like we might be seeing VXLAN-over-SDWAN deployments in the wild. Here’s the “why that makes sense” argument I received from a participant of the ipSpace.net Design Clinic in which I wasn’t exactly enthusiastic about the idea.

Also, the EVPN-over-WAN idea is not hypothetical since EVPN+VXLAN is now the easiest way to build L3VPN with data center switches that don’t support MPLS LDP. Folks with no interest in EVPN’s L2 features are still using it for L3VPN.

Let’s unravel this scenario a bit:

1 24 25 26 27 28 180