gurfin gurf1n

In the beginning of LANs the Layer 1 media was shared between all devices in said LAN. They all received and transmitted on the same wires, at the same time. This is whats known as half-duplex (only send or received, not both). In this configuration devices would sometimes send traffic at the same time, which causes interference on Layer 1. The resulting interference can be enough to disrupt the communications. The shared “area” in which devices are connected to is known as a “collision domain”.

So I have been working quite a bit on the MPLS WAN setup the past few weeks. Currently I have two sites running the new MPLS nodes as their gateway and one more currently staged which will be installed in the coming weeks. I still have some work to do for the sites which use multiple wan connections, but the primary WAN works great! I have also setup network monitoring using LibreNMS which allows me to do ICMP and SNMP monitoring, while also letting me build custom triggers for alerts.

I ran into an interesting issue at work today. One of our customers were having issues with a site in Gothenburg. They were using L2VPNs as circuits between their central site and the remote sites. Across this L2VPN they are running MPLS MP-eBGP peering using inter AS option 2b to allow multiplexing of different routing-instances on the WAN. We were observing BGP flapping between the secondary ASBR router on site and their central ASBR router.

This will be a living document, for troubleshooting and tracing MPLS traffic. The idea is for me and others to be able to reference this post for basic MPLS troubleshooting. MPLS purpose and MPLS packet headers The original purpose of MPLS was to allow for faster packet routing through a provider network. This is because the actual forwarding operation on the routers is more efficient when using the labels for forwarding decisions, compared to looking up IP-addresses.

The past two weeks I have been working hard at getting the new MPLS WAN up and running. The idea is to build a scaleable solution, even though my MPLS cloud never will grow large enough to require the scalability. The plan is also to allow my colleagues to join the MPLS WAN, which means I need to think about locking down the WAN to keep them out of restricted parts of my provider core.

In my series DC@Home I recently ran into the issue of how to filter which VRF:s should be allowed to propagate from the provider core, out to the customer sites. It turns our it is quite simple and can be done in a manner similar to prefix-lists for regular BGP peering. For VPNv4 multiplexing the MP-BGP session uses extended community tags to separate the traffic. We can use a route-map combined with a extcommunity-list to filter which route-targets are allowed to traverse the peering.

This weekend I started setting up the core of the provider network. This mainly consisted of configuring MPLS and MP-BGP to run L3VPNs between provider nodes. I also setup a secondary internet connection, which will primarily be used to run active-active tunnels from sites into the MPLS core. One big goal of this new setup is to allow access from a site to any allowed VRF in the provider network. Each site is to have their own VRF, which automatically allows access from the provider core into all networks for a given customer.

I recently ran into a case where a customer wanted to be able to monitor their primary and secondary WAN-links in order to determine if they are up. We owned the primary WAN-link, which served the primary router at the site. The secondary link was a DIA running DMVPN across the interwebz. In order for them to have an IP-address that they can ping to ensure reachability from the CE-router to our PE-router we needed to setup a loopback which was not redistributed into the L3VPN for the customer.

I have a lot of tech stuff floating around at home and at friends houses. Some things are in “production” while others are legacy tests that have been left and forgotten. With this in mind I have begun the journey of building a datacenter at home! The most important aspect of doing greenfield is do have a clear purpose, which can then be broken down into goals, requirements and steps. The more good calls you can make early on, the less trouble you’ll run into down the road.

Hello, This is the first post on the new blog. My hopes are to use this place as a sort of public notebook for ideas, projects and studying. I find that I far too often research a subject and then loose all the research that I have done once I have found the most elegant solution for the issue at hand. The result of my research usually sticks in my memory, but I would like a collection of the underlying material for future reference.