Archive

Category Archives for "ipSpace.net"

Layer-3 Carrier Ethernet

One of ipSpace.net subscribers asked for my opinion about Adaptive IP, a concept promoted by one of the optical connectivity vendors. As he put it:

My interest in Carrier Ethernet moving up to Layer 3 is to see if it would be something to account for in the future.

A quick search resulted in a marketecture using Segment Routing (of course) and an SDN controller (what else could one be using today) using Path Computation Element Protocol (PCEP) to program the network devices… and then I hit a regwall. They wanted to collect my personal details to grace me with their whitepaper, and I couldn’t find even a link to the product documentation.

Layer-3 Carrier Ethernet

One of ipSpace.net subscribers asked for my opinion about Adaptive IP, a concept promoted by one of the optical connectivity vendors. As he put it:

My interest in Carrier Ethernet moving up to Layer 3 is to see if it would be something to account for in the future.

A quick search resulted in a marketecture using Segment Routing (of course) and an SDN controller (what else could one be using today) using Path Computation Element Protocol (PCEP) to program the network devices… and then I hit a regwall. They wanted to collect my personal details to grace me with their whitepaper, and I couldn’t find even a link to the product documentation.

Running IS-IS over Unnumbered Ethernet Interfaces

Last time we figured out that we cannot run OSPF over unnumbered interfaces that are not point-to-point links because OSPF makes assumptions about interface IP addresses. IS-IS makes no such assumptions; IPv4 and IPv6 prefixes are just a bunch of TLVs exchanged between routers over a dedicated layer-3 protocol with ridiculously long network addresses.

Could we thus build a totally unnumbered IP network with IS-IS even when the network contains multi-access segments? It depends:

Running IS-IS over Unnumbered Ethernet Interfaces

Last time we figured out that we cannot run OSPF over unnumbered interfaces that are not point-to-point links because OSPF makes assumptions about interface IP addresses. IS-IS makes no such assumptions; IPv4 and IPv6 prefixes are just a bunch of TLVs exchanged between routers over a dedicated layer-3 protocol with ridiculously long network addresses.

Could we thus build a totally unnumbered IP network with IS-IS even when the network contains multi-access segments? It depends:

Video: Local Area Network Addressing

In the Local Area Network Addressing video (part of How Networks Really Work webinar) I covered numerous obscure LAN addressing details including:

  • There’s no layer-2 address in Fibre Channel frames (because FC is routing not bridging);
  • Why is the multicast bit lowest bit (0x01) in first byte on Ethernet but highest bit (0x80) on Token Ring or FDDI;
  • How some NIC manufacturers never got the memo on what OUI really means.
You need Free ipSpace.net Subscription to watch the video, and the Standard ipSpace.net Subscription to register for upcoming live sessions.

Video: Local Area Network Addressing

In the Local Area Network Addressing video (part of How Networks Really Work webinar) I covered numerous obscure LAN addressing details including:

  • There’s no layer-2 address in Fibre Channel frames (because FC is routing not bridging);
  • Why is the multicast bit the lowest bit (0x01) in the first byte on Ethernet but the highest bit (0x80) on Token Ring or FDDI;
  • How some NIC manufacturers never got the memo on what OUI really means.
You need Free ipSpace.net Subscription to watch the video, and the Standard ipSpace.net Subscription to register for upcoming live sessions.

Feedback: Recursive BGP Next Hop Resolution

The Recursive BGP Next Hops: an RFC 4271 Quirk blog post generated tons of feedback (thanks a million to everyone writing a comment on my blog or LinkedIn).

Starting with Robert Razsuk who managed to track down the original email that triggered the (maybe dubious) text in RFC 4271:

The text in section 5.1.3 was not really targeting to prohibit load balancing. Keep in mind that it is FIB layer which constructs actual forwarding paths.

The text has been suggested by Tom Petch in discussion about BGP advertising valid paths or even paths it actually installs in the RIB/FIB. The entire section 5.1.3 is about rules when advertising paths by BGP.

Feedback: Recursive BGP Next Hop Resolution

The Recursive BGP Next Hops: an RFC 4271 Quirk blog post generated tons of feedback (thanks a million to everyone writing a comment on my blog or LinkedIn).

Starting with Robert Razsuk who managed to track down the original email that triggered the (maybe dubious) text in RFC 4271:

The text in section 5.1.3 was not really targeting to prohibit load balancing. Keep in mind that it is FIB layer which constructs actual forwarding paths.

The text has been suggested by Tom Petch in discussion about BGP advertising valid paths or even paths it actually installs in the RIB/FIB. The entire section 5.1.3 is about rules when advertising paths by BGP.

Just Out: netsim-tools Release 1.1

New Year break was probably my busiest time (programming-wise) in years. Jeroen van Bemmel continued generating great ideas (and writing code and device configuration templates), and I found myself saying, “why not, let’s do the right thing!” more often than I expected. In parallel, Stefano Sasso fixed configuration templates for Junos, Mikrotik Router OS, and VyOS, and we were good to go.

To give you an idea of how fast we were moving: issue #84 was created on December 22nd, Sunday’s pull request that pushed release 1.1 into the master branch was #135 (GitHub numbers everything you do sequentially).

Just Out: netsim-tools Release 1.1

New Year break was probably my busiest time (programming-wise) in years. Jeroen van Bemmel continued generating great ideas (and writing code and device configuration templates), and I found myself saying, “why not, let’s do the right thing!” more often than I expected. In parallel, Stefano Sasso fixed configuration templates for Junos, Mikrotik Router OS, and VyOS, and we were good to go.

To give you an idea of how fast we were moving: issue #84 was created on December 22nd, Sunday’s pull request that pushed release 1.1 into the master branch was #135 (GitHub numbers everything you do sequentially).

Starting with release 1.3, we renamed netsim-tools to netlab.

Running OSPF over Unnumbered Ethernet Interfaces

Remember the unnumbered IP interfaces saga? Let’s conclude it with the final challenge: can we run link-state routing protocols (OSPF or IS-IS) over unnumbered interfaces?

Quick answer: Sure, just use IPv6.

Cheater! IPv6 doesn’t count. There are no unnumbered interfaces in IPv6 – every interface has at least a link-local address (LLA). Even more, routing protocols are designed to run over LLA addresses, including some EBGP implementations, allowing you to build an LLA-only network (see RFC 7404 for details).

OK, what about IPv4?

TL&DR: It works, but…

Running OSPF over Unnumbered Ethernet Interfaces

Remember the unnumbered IP interfaces saga? Let’s conclude with the final challenge: can we run link-state routing protocols (OSPF or IS-IS) over unnumbered interfaces?

Quick answer: Sure, just use IPv6.

Cheater! IPv6 doesn’t count. There are no unnumbered interfaces in IPv6 – every interface has at least a link-local address (LLA). Even more, routing protocols are designed to run over LLA addresses, including some EBGP implementations, allowing you to build an LLA-only network (see RFC 7404 for details).

OK, what about IPv4?

TL&DR: It works, but…

Feedback: Cisco ACI Deep Dive

In 2021, we completed one of the longest ipSpace.net webinars: Cisco ACI Deep Dive (almost 13 hours of content1). One of the participants found it extremely useful:

I really like the technical detail of the webinar and the way it is composed. Mario also does a good job in explaining all the complexity in a clear way without oversimplifying. All the sessions help to build up an understanding on the inner workings of the ACI solution, because they deliver technical details in depth piece by piece.

I also liked his take on the value of this webinar:

I’m always amazed on how much other (offical) training vendors under deliver in their courses that cost thousands of dollars, compared to the real expert level stuff you’ve got here.

Hope you’ll like the webinar as much as he did – you can get it with Standard or Expert ipSpace.net Subscription.

Feedback: Cisco ACI Deep Dive

In 2021, we completed one of the longest ipSpace.net webinars: Cisco ACI Deep Dive (almost 13 hours of content1). One of the participants found it extremely useful:

I really like the technical detail of the webinar and the way it is composed. Mario also does a good job in explaining all the complexity in a clear way without oversimplifying. All the sessions help to build up an understanding on the inner workings of the ACI solution, because they deliver technical details in depth piece by piece.

I also liked his take on the value of this webinar:

I’m always amazed on how much other (offical) training vendors under deliver in their courses that cost thousands of dollars, compared to the real expert level stuff you’ve got here.

Hope you’ll like the webinar as much as he did – you can get it with Standard or Expert ipSpace.net Subscription.

Recursive BGP Next Hops: an RFC 4271 Quirk

All BGP implementations I’ve seen so far use recursive next hop lookup:

  • The next hop in the IP routing table is the BGP next hop advertised in the incoming update
  • That next hop is resolved into the actual next hop using one or more recursive lookups into the IP routing table.

Furthermore, all BGP implementations I’ve seen used multiple recursive next hops (if available) to implement load balancing toward the BGP next hop – that’s how we made EBGP load balancing work in Stone Age of networking.

Recursive BGP Next Hops: an RFC 4271 Quirk

All BGP implementations I’ve seen so far use recursive next hop lookup:

  • The next hop in the IP routing table is the BGP next hop advertised in the incoming update
  • That next hop is resolved into the actual next hop using one or more recursive lookups into the IP routing table.

Furthermore, all BGP implementations I’ve seen used multiple recursive next hops (if available) to implement load balancing toward the BGP next hop – that’s how we made EBGP load balancing work in Stone Age of networking.

1 64 65 66 67 68 176