All Routing Protocol Convergence videos from the How Networks Really Work webinar are now public. Enjoy!
At the start of the year a very interesting (and some would say inevitable) event happened involving internet routing security, the first case study of a large-scale victim o
Most providers will only accept a /24 or shorter IPv4 route because routers have always had limited amounts of forwarding table space. In fact, many hardware and software IPv4 forwarding implementations are optimized for a /24 or shorter prefix length. Justin Wilson joins Tom Ammon and Russ White to discuss why the DFZ might need to be expanded to longer prefix lengths, and the tradeoffs involved in doing so.
Last time, we discussed the first line of defense against fat finger incidents: limiting the number of BGP prefixes your router accepts from a BGP neighbor. However, you can do much more without deploying customer-specific filters (which might require a customer database) or ROV/RPKI.
You can practice the default filters you should always deploy on EBGP sessions with your customers in the Stop the Propagation of Configuration Errors lab exercise.
Last time, we discussed the first line of defense against fat finger incidents: limiting the number of BGP prefixes your router accepts from a BGP neighbor. However, you can do much more without deploying customer-specific filters (which might require a customer database) or ROV/RPKI.
You can practice the default filters you should always deploy on EBGP sessions with your customers in the Stop the Propagation of Configuration Errors lab exercise.
I’m preparing a massive blog post on vPC in the context of VXLAN/EVPN and while doing so I accidentally broke my lab. What a great learning experience! I thought I would share it with you and how to perform troubleshooting of this scenario.
My topology looks like this:
Before I made any changes, there was full connectivity between these hosts, meaning that both bridging and routing was working. I then changed the loopback1 (NVE source interface) configuration of Leaf-1 and Leaf-2 to add a secondary IP. This was the initial configuration:
! Leaf-1 interface loopback1 description VTEP ip address 203.0.113.1/32 ip router ospf UNDERLAY area 0.0.0.0 ip pim sparse-mode ! Leaf-2 interface loopback1 description VTEP ip address 203.0.113.2/32 ip router ospf UNDERLAY area 0.0.0.0 ip pim sparse-mode
This then changed to:
! Leaf-1 interface loopback1 description VTEP ip address 203.0.113.1/32 ip address 203.0.113.12/32 secondary ip router ospf UNDERLAY area 0.0.0.0 ip pim sparse-mode ! Leaf-2 interface loopback1 description VTEP ip address 203.0.113.2/32 ip address 203.0.113.12/32 secondary ip router ospf UNDERLAY area 0.0.0.0 ip pim Continue reading
This is how we described the interactions between routing protocol tables, RIB, and FIB in the ancient times:
Let’s use a simple BGP+OSPF network to illustrate what I’m talking about:
This is how we described the interactions between routing protocol tables, RIB, and FIB in the ancient times:
Let’s use a simple BGP+OSPF network to illustrate what I’m talking about:
I've been following IP Fabric for some time now, checking out their updates and reading their blog posts. It made me curious to want to give their platform a try myself. So, I did just that and thought it'd be helpful to share my thoughts and experiences with you.
If you're curious about IP Fabric too, they offer a 90-day lab license, which is a great way to get hands-on with the platform. The nice people over at IP Fabric set me up with a trial license and I found the setup process to be very straightforward. In fact, it took me less than an hour to get everything up and running.
What we will cover?