As a JNCIE-SP candidate, you’re expected to troubleshoot OSPF neighbor mismatch quickly. So, in this article, we’ll recap all the OSPF attributes and criteria that must match before OSPF routers actually become functional neighbors. Next, I’ll show you which show commands and traceoptions flags are more appropriate to troubleshoot effectively such OSPF neighbor mismatches that you’re likely to encounter. Plus, it’s worth mentioning that being able to effectively troubleshoot these type of mismatches is really such a valuable skill to have, especially if you work in a multi vendor environment.
We all know that moment when you’re doing your lab and for learning/troubleshooting purposes you wish you had an option to capture the traffic on all networks in your lab in a convenient way. As of this writing, UNetLab latest release version is 1.0.0-10 and so far UNetLab developers haven’t released an official feature that allows the users to capture traffic on all network interfaces simultaneously. If you need to capture traffic using UNetLab GUI, you have the option to select only one network, which will result in firing up one Wireshark instance. So, if you need to capture traffic on all network simultaneously and pipe directly to Wireshark you’re out of luck and instead, you’ll have to fire up several instances of Wireshark, which isn’t practical because of the number of windows you’ll have to deal with. To remedy this situation, I’m going to show you how you can setup rpcap on UNetLab so you can specify from you client machine what networks you need to capture simultaneously in only one Wireshark window.
In this quick article, I’m going to show you how OAM LFM 1 can be used on MPLS L2VPN ACs to detect point-to-point connectivity faults on Junos. OAM LFM can be extremely helpful to enhance the AC (Layer 2) connectivity troubleshooting when you don’t have back to back physical connectivity on the PE-CE Ethernet link. This lack of back to back Ethernet connectivity, for instance, can arise when you have an underlying transport technology such as DWDM. In order to simulate this environment, I’ll run my entire topology (Figure 1) on virtual Ethernet bridges, which also have this lack of back to back physical connectivity between the two endpoints (i.e., even if you shut down one side of the link, the Ethernet link will still be perceived as up from the other endpoint’s perspective).
Pseudowire redundancy is key when it comes to eliminating a single point of failure, such as PW, AC and PE, in certain network designs as far as MPLS L2VPN services (e.g., VPWS and VPLS). When configuring pseudowire redundancy on Junos, you can either leave the backup PW in
standby or in
hot-standby mode. In this article, I’m going to compare both modes and point out some major benefits and drawbacks that you might want to take into account if you ever need to use PW redundancy in your network.
There are some nuances that you have to take into account if you need to interoperate MPLS L2VPN Martini (LDP VPWS) between Juniper (vMX) and Cisco (CSR1000v - IOS-XE). In this interoperability case, I’m going to use
VC-type 4/tagged mode (i.e., which in a nutshell, is the mode where you can use SVLANs on the ingress PE to differentiate between your L2VPN customers). If you need further or specific information about this mode, I’d suggest you take a look at the RFC4448 1.