Thursday, October 28, 2010

INE Vol 1 multicast - Lab 3 - Multicast RPF Failure (3rd Pass)

So this lab deals with Multicast with broken uRPF due to PIM no being enabled on preferred route/link.

The best way to determine where the problem is, is to use "no ip mroute-cache" on the the PIM enabled interfaces and to "debug ip mpacket". Of course, you'll want to log this to the buffer and not the console.

Doing this at each step of the way, you'll find that R4 is preferring a NON-PIM link to get back to the source.

*Oct 28 18:38:27.499: IP(0): s=10.1.37.7 (FastEthernet2/0) d=224.1.1.1 id=133, ttl=251, prot=1, len=114(100), not RPF interface

This should be an indication that path isn't taking the correct interface back to the source. A static mroute fixes this issue.

Monday, October 25, 2010

INE Vol 1 - Lab 26 - Multicast over MPLS VPNs (3rd pass) - BGP MDT SAFI!!!

For the IOS I'm using for my lab 12.4(20)T, it's necessary to configure BGP address-family MDT for the MDT tunnel to come up.

Otherwise everything else in this lab is straight forward. Configure Multicast throughout the SP and Enterprise devices, enable Multicast on the PE's for the specific VPN and if using static RPs remember to configure the RP address in the VRF on the PEs.

Saturday, October 23, 2010

INE Vol 1 - Lab 22 MPLS TE - Dynamic PE to PE tunnels (3rd Pass)

In this lab, it states that you should enable mpls ip on the links but in reality you don't have to since RSVP will take care of the IGP labeling for the BGP next hop and VPNv4 BGP takes care of the Customer prefixes. I did this lab without enable ldp/tdp and it worked as expected.

Just as a review, there are 5 major steps.

Step 1: Enable MPLS traffic-eng tunnels globally
Step 2: Enable MPLS traffic-eng tunnels in the IGP
OSPF - mpls traffic-eng area 0 & mpls traffic-eng router l 0
ISIS - metric-style wide, mpls traffic-eng [level1 | level 2], mpls traffic-eng router l 0
Step 3: Enable MPLS traffic-eng on the interface as well as IP RSVP on the interface
Step 4: Create a tunnel interface and configure as an mpls traffic-eng tunn
Step 5: Ensure that the tunnel is taken for some/all traffic, autoroute announce, static routing, pbr, etc.

INE Vol 1 - Lab 21 - Controlling MPLS Label Distribution (3rd Pass)

Don't forget when restricting label advertisements using "mpls ldp advertise-label for X to Y" that you need to disable mpls ldp advertise-labels for ALL labels which is on be default and won't show up in the config.

Use:
no mpls ldp advertise-labels
mpls advertise-labels for X to Y


Thursday, October 21, 2010

INE Vol 1 - Lab 20 - VRF Lite (twist)

I redid this lab again and this time I introduced my own twist. Instead of running a dynamic routing protocol between the VRF lite router and the PE, try using static routes and then try using static default routes. Turns out it's a fun redistribution exercise.

** Also be aware that for sub-interfaces on a serial link wasn't working correctly for me but once I used 2 physical serial interfaces instead of 1 with 2 subs, everything came up correctly.

Tuesday, October 19, 2010

INE Vol 1 - Lab 16 - Inter-AS MPLS VPNs with Multihop MP-eBGP for VPNv4 Exchange (3rd Pass)

This time around, I forgot I needed to redistribute from IPv4 Unicast BGP into IGP. This is required because when the VPNv4 BGP peers recurse to IGP (putting the IGP label on top of the VPN label), it has to know of the loopback in IGP. Even if it knows it by IPv4 BGP, that's not an IGP so it still won't work (meaning you may see the routes appear on the CEs but pings will fail, because the labeling is failing).

Other things to note, MP-eBGP multi hop and IPv4 Send-label are required.

IPv4 BGP Send-label to get labels across the Inter AS connection.

INE Vol 1 - Lab 15 - Inter-AS w/ MP-eBGP (3rd Pass)

Redoing this lab was good. Caught some silly mistake be trouble shooting.

1. Ensuring the control plane, ie. the BGP VPNv4 tables, look good, meaning you're receiving BGP routes. If you're not, then check to make sure you have next-hop-self enabled where appropriate and that you are not filtering route-targets by default on certain BGP-ASBR routers

2. Once the routes appear on the CEs, ping, if ping fails, then check step by step LDP and make sure labels are assigned for the destinations. A common mistake, if you have a loopback configured but not in IGP then you're LDP peering won't come up since it'll use the loopback as it's ID but the peers won't have reachability to it (unless you put it in IGP).