We did a podcast describing NAPALM, an open-source multi-vendor abstraction library, a while ago, and as the project made significant progress in the meantime, it was time for a short update.
NAPALM started as a library that abstracted the intricacies of network device configuration management. Initially it supported configuration replace and merge; in the meantime, they added support for diffs and rollbacks
Read more ...
Public cloud is so good, it's almost boring.
SNMP was not designed with VRFs in mind. Querying the routing table via SNMP did not take into account the idea of having multiple routing tables. But clearly it’s something people want to do, so some clever engineers figured out how to shoe-horn VRF contexts in. This week a customer asked me how to query the routing table for the non-default VRF on Brocade VDX switches. Here’s how to do it:
For this lab I have Loopback 1 in the default VRF, with an IP of 50.50.50.50/32. I’ve created another VRF called “internet”, and put Loopback 2 in that VRF, with IP 60.60.60.60/32. Now I have two different routing tables:
VDX6940-204063# sh run rb 1 int loop 1
rbridge-id 1
interface Loopback 1
no shutdown
ip address 50.50.50.50/32
!
!
VDX6940-204063# sh ip route
Total number of IP routes: 1
Type Codes - B:BGP D:Connected O:OSPF S:Static U:Unnumbered +:Leaked route; Cost - Dist/Metric
BGP Codes - i:iBGP e:eBGP
OSPF Codes - Continue readingSNMP was not designed with VRFs in mind. Querying the routing table via SNMP did not take into account the idea of having multiple routing tables. But clearly it’s something people want to do, so some clever engineers figured out how to shoe-horn VRF contexts in. This week a customer asked me how to query the routing table for the non-default VRF on Brocade VDX switches. Here’s how to do it:
For this lab I have Loopback 1 in the default VRF, with an IP of 50.50.50.50/32. I’ve created another VRF called “internet”, and put Loopback 2 in that VRF, with IP 60.60.60.60/32. Now I have two different routing tables:
VDX6940-204063# sh run rb 1 int loop 1 rbridge-id 1 interface Loopback 1 no shutdown ip address 50.50.50.50/32 ! ! VDX6940-204063# sh ip route Total number of IP routes: 1 Type Codes - B:BGP D:Connected O:OSPF S:Static U:Unnumbered +:Leaked route; Cost - Dist/Metric BGP Codes - i:iBGP e:eBGP OSPF Codes - Continue reading
Cisco says SD-WAN should be viewed as an addition to MPLS, not a replacement.
Fortinet recently restructured its sales team.
The combination of these two telecom firms could create some interesting strengths in virtualized networking.
Defining the problem – unused capacity
One of the single greatest challenges if you have ever owned, operated or designed a WISP (Wireless Internet Service Provider) is using all of the available bandwidth across multiple PtP links in the network. It is very common for two towers to have multiple RF PtP (Point-to-Point) links between them and run at different speeds. It is not unusual to have a primary link that runs at near-gigabit speeds and a backup link that may range anywhere from 50 Mbps to a few hundred Mbps.
This provides a pretty clean HA routing architecture, but it leaves capacity in the network unused until there is a failure. One of the headaches WISP designers always face is how to manage and engineer traffic for sub-rate ethernet links – essentially links that can’t deliver as much throughput as the physical link to the router or switch. In the fiber world, this is pretty straightforward as two links between any two points can be the exact same speed and either be channeled together with LACP or rely on ECMP with OSPF or BGP.
However, in the WISP world, this becomes problematic, as the links are unequal and Continue reading
Defining the problem – unused capacity
One of the single greatest challenges if you have ever owned, operated or designed a WISP (Wireless Internet Service Provider) is using all of the available bandwidth across multiple PtP links in the network. It is very common for two towers to have multiple RF PtP (Point-to-Point) links between them and run at different speeds. It is not unusual to have a primary link that runs at near-gigabit speeds and a backup link that may range anywhere from 50 Mbps to a few hundred Mbps.
This provides a pretty clean HA routing architecture, but it leaves capacity in the network unused until there is a failure. One of the headaches WISP designers always face is how to manage and engineer traffic for sub-rate ethernet links – essentially links that can’t deliver as much throughput as the physical link to the router or switch. In the fiber world, this is pretty straightforward as two links between any two points can be the exact same speed and either be channeled together with LACP or rely on ECMP with OSPF or BGP.
However, in the WISP world, this becomes problematic, as the links are unequal and Continue reading