FS Lab 3: MPLSoDMVPN - Phase III Required?

Tryin to grasp my head around this concept when it comes to spoke-to-spoke label exchange.

As I understand, Phase 1 or 3 is required to use MPLS over the DMVPN cloud. This is because the next-hop of a prefix must be an LDP neighbor (in reality, I know that in Phase III, the next-hop will actually be a spoke in CEF [for spoke-to-spoke prefixes]).

However, in FS Lab 3 Section 4, the DMVPN setup was required to be in Phase II, which preserves the next-hop.
Furthermore, Section 5.1 Solution shows that the correct output is for R16 to only have LDP peers with R6 & R7 -- albeit it doesn't go into detail if this is intended or not...

Which brings me to Section 5.5 (where I'm stuck). I'd have to change the DMVPN to either Phase I or II to make VPNv4 work correctly, right?

My reasoning is that the MPLS VPN for VRF "RED" is failing because R15 and R16 are not using labels when sending packets to each other. For example, from SW4:Lo0 to SERVER1:

src = 150.1.24.24
dst = 192.168.8.100

Output of R16:

 R16#show ip route vrf RED 192.168.8.100

Routing Table: RED
Routing entry for 192.168.8.0/24
  Known via "bgp 65600", distance 200, metric 2, type internal
  Redistributing via ospf 2
  Advertised by ospf 2 subnets
  Last update from 150.1.15.15 00:32:58 ago
  Routing Descriptor Blocks:
  * 150.1.15.15 (default), from 66.66.66.66, 00:32:58 ago
      Route metric is 2, traffic share count is 1
      AS Hops 0
      MPLS label: 34
      MPLS Flags: MPLS Required

!------ Oooookay, shows I have the right VPN label (34), now to check the next-hop... --------!



R16#show mpls forwarding-table 150.1.15.15

Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop    

Label      Label      or Tunnel Id     Switched      interface              

30         No Label   150.1.15.15/32   0             Tu2        172.32.1.15 



!----- R16 is failing to attach an outer label for R15's Loopback0 because it is not an LDP peer. -----!


I thought I could remediate this by forcing R15 and R16 to become LDP Neighbors over the DMVPN:


[mpls ldp neighbor 150.1.X.X targeted ldp]


!------- Behold, I now have a label (imp-null) set for R15's loopback0! -------------!


R16#show mpls ldp bind 150.1.15.15 32                   


  lib entry: 150.1.15.15/32, rev 32

local binding:  label: 30

remote binding: lsr: 66.66.66.66:0, label: 32

remote binding: lsr: 77.77.77.77:0, label: 32

remote binding: lsr: 150.1.15.15:0, label: imp-null



!----- Now I'll look at the mpls forwarding table again...



R16#show mpls forwarding-table 150.1.15.15 32

Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop    

Label      Label      or Tunnel Id     Switched      interface              

30         No Label   150.1.15.15/32   0             Tu2        172.32.1.15 



!--- Sigh.....back to square one. Can this even be fixed? Is this a bug? Am I missing something?


BTW -- I'm running my lab on GNS3 using 7200's w/ 15.2(4)S3.


Any help is appreciated, thanks.



***EDIT***


It helps to scroll down to see the rest of the solution, heh..


I was halfway there with targeted LDP sessions between spokes, but was missing the NHRP map entry on the spokes, for the spokes.


I ended up modifying the NEXT_HOP instead via MPBGP with [next-hop-self all] (another nice tool I learned for Route Reflectors, wooh!). As speed is key, this seems to be the fastest solution.

Comments

  • I was going to answer, but i read the edit of your post, jjeje. I also tried to make targeted sessions with no luck and i cheated finally and learned a tricky command LOL

    Nice lab by the way!

Sign In or Register to comment.