2

I've been trying to get 2547oDMVPN with 'mpls nhrp' setup in a VIRL environment and I have gotten it to work with some of the examples I've seen online, but all the examples online have had the hub as the route reflector and have used the Tunnel interface for BGP peering. If I use my Tunnel interface as my iBGP peer source things work, but if I don't, then for some reason things stop?

Here is the output of some of my show commands that I believe to be the issue, but I don't know how to fix. In the 'show ip cef vrf CLASS detail' I see the prefix and it gets recursively resolved to my tunnel interface. In the 'show mpls forwarding-table' it says to drop the labels? Thank you in advance for any help.

show mpls forwarding-table

IR-01#show mpls forwarding-table 
Local Outgoing Prefix Bytes Label Outgoing Next Hop 
Label Label or Tunnel Id Switched interface 
305 202 0.0.0.0/0[V] 0 drop 
307 205 10.10.1.0/24[V] 0 drop 
308 No Label 10.30.1.0/24[V] 0 aggregate/CLASS 
313 307 10.50.1.0/24[V] 0 drop


IR-01#show ip cef vrf CLASS detail 
IPv4 CEF is enabled and running
VRF CLASS
17 prefixes (17/0 fwd/non-fwd)
Table id 0x2
Database epoch: 0 (17 entries at this epoch)

0.0.0.0/0, epoch 0, flags [rib defined all labels, default route]
local label info: other/305
recursive via 10.10.0.251 label 202
recursive via 10.10.0.250/31
nexthop 1.0.2.10 Tunnel102
0.0.0.0/8, epoch 0
Special source: drop
drop
0.0.0.0/32, epoch 0, flags [receive]
Special source: receive
receive
10.10.1.0/24, epoch 0, flags [rib defined all labels]
local label info: other/307
recursive via 10.10.0.251 label 205
recursive via 10.10.0.250/31
nexthop 1.0.2.10 Tunnel102
10.30.1.0/24, epoch 0, flags [attached]
local label info: other/308
attached to Null0
10.30.1.0/31, epoch 0, flags [attached, connected]
attached to Loopback1
10.30.1.1/32, epoch 0, flags [receive, local, source eligible]
Interface source: Loopback1 flags: local, source eligible
receive for Loopback1
10.30.1.32/30, epoch 0, flags [attached, connected, cover dependents, need deagg]
Covered dependent prefixes: 2
need deagg: 2
attached to GigabitEthernet0/2.20
10.30.1.32/32, epoch 0, flags [receive]
Interface source: GigabitEthernet0/2.20 flags: none
Dependent covered prefix type cover need deagg, cover 10.30.1.32/30
receive for GigabitEthernet0/2.20
10.30.1.33/32, epoch 0, flags [receive, local, source eligible]
Interface source: GigabitEthernet0/2.20 flags: local, source eligible
receive for GigabitEthernet0/2.20
10.30.1.35/32, epoch 0, flags [receive]
Interface source: GigabitEthernet0/2.20 flags: none
Dependent covered prefix type cover need deagg, cover 10.30.1.32/30
receive for GigabitEthernet0/2.20
10.50.1.0/24, epoch 0, flags [rib defined all labels]
local label info: other/313
recursive via 10.50.0.251 label 307
recursive via 10.50.0.250/31
nexthop 1.0.2.10 Tunnel102
127.0.0.0/8, epoch 0
Special source: drop
drop
224.0.0.0/4, epoch 0
Special source: drop
drop
224.0.0.0/24, epoch 0, flags [receive]
Special source: receive
receive
240.0.0.0/4, epoch 0
Special source: drop
drop
255.255.255.255/32, epoch 0, flags [receive]
Special source: receive
receive


IR-01#sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is not set

      1.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C        1.0.2.0/24 is directly connected, Tunnel102
L        1.0.2.30/32 is directly connected, Tunnel102
H        1.0.2.50/32 is directly connected, 00:07:01, Tunnel102
      10.0.0.0/8 is variably subnetted, 15 subnets, 3 masks
O        10.10.0.20/30 [110/1001] via 1.0.2.10, 00:42:50, Tunnel102
O        10.10.0.24/30 [110/1002] via 1.0.2.10, 00:42:50, Tunnel102
O        10.10.0.250/31 [110/1001] via 1.0.2.10, 00:42:50, Tunnel102
O        10.10.0.254/31 [110/1002] via 1.0.2.10, 00:42:50, Tunnel102
C        10.30.0.0/30 is directly connected, GigabitEthernet0/1
L        10.30.0.2/32 is directly connected, GigabitEthernet0/1
O        10.30.0.4/30 [110/2] via 10.30.0.1, 10:43:28, GigabitEthernet0/1
C        10.30.0.32/30 is directly connected, GigabitEthernet0/2.10
L        10.30.0.33/32 is directly connected, GigabitEthernet0/2.10
C        10.30.0.64/30 is directly connected, GigabitEthernet0/3
L        10.30.0.65/32 is directly connected, GigabitEthernet0/3
C        10.30.0.250/31 is directly connected, Loopback0
L        10.30.0.251/32 is directly connected, Loopback0
O        10.30.0.253/32 [110/2] via 10.30.0.1, 10:43:28, GigabitEthernet0/1
O        10.50.0.250/31 [110/2001] via 1.0.2.10, 00:42:40, Tunnel102
      192.168.0.0/24 is variably subnetted, 4 subnets, 2 masks
S        192.168.0.0/24 [1/0] via 10.30.0.66
O E2     192.168.0.10/32 [110/100] via 10.30.0.1, 10:42:44, GigabitEthernet0/1
C        192.168.0.30/32 is directly connected, Loopback100
O E2     192.168.0.50/32 [110/100] via 10.30.0.1, 10:43:16, GigabitEthernet0/1
IR-01# sh ip route vrf CLASS 

Routing Table: CLASS
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is 10.10.0.251 to network 0.0.0.0

B*    0.0.0.0/0 [200/0] via 10.10.0.251, 00:42:06
      10.0.0.0/8 is variably subnetted, 7 subnets, 4 masks
B        10.10.1.0/24 [200/0] via 10.10.0.251, 00:42:06
S        10.30.1.0/24 is directly connected, Null0
C        10.30.1.0/31 is directly connected, Loopback1
L        10.30.1.1/32 is directly connected, Loopback1
C        10.30.1.32/30 is directly connected, GigabitEthernet0/2.20
L        10.30.1.33/32 is directly connected, GigabitEthernet0/2.20
B        10.50.1.0/24 [200/0] via 10.50.0.251, 00:42:06
IR-01#
Improve this question

1 Answer 1

Reset to default
2

Edit based on the provided bug link:

This is obviously a bug. The workaround is given, and I think you need to use the tunnel interface as prescribed in the workaround until there is a code fix. We don't have magic solutions to a code bug. See the text I highlighted from the bug report on the last line below:

Symptom: Packet forwarding succeeds between DMVPN spoke nodes when going over spoke-hub-spoke path but fails when when going over the direct spoke-spoke path. Forwarding over the direct spoke-spoke will fail when either the source or endpoint is a directly connected interface address on the spoke node within a VRF, the interface has a /32 mask and MPLSoDMVPN using 'mpls nhrp' is configured on the DMVPN tunnel interfaces.

Additionally, using Loopback interfaces to perform iBGP peering across the Spokes will also fail, irrespective of the netmask on the loopback interfaces since iBGP peering will still be done using /32 prefix.

Conditions: MPLSoDMVPN [2547oDMVPN] setup with "mpls nhrp" configuration. Requirement is to setup direct spoke-to-spoke Tunnels.

Workaround: Change the interface mask to be something other than /32 like /31. Though this ends up wasting an address per such interface.

In case of iBGP peering over loopback interfaces, use Tunnel interface.

Improve this answer
5
  • All iBGP source interface can ping all other iBGP source interfaces in the global routing table. I get all my vpnv4 routes in my VRF. I have iBGP peering established. It "looks" like it should work, but it doesnt'. If i use 'mpls ip' instead of 'mpls nhrp' everything works fine, but I can't go spoke-to-spoke directly.
    – Kyle
    Feb 23, 2016 at 16:22
  • Does it ping through the tunnel?
    – Ron Maupin ♦
    Feb 23, 2016 at 16:24
  • i can ping through my mGRE tunnels just fine in the global routing table. VRF traffic just gets dropped immediately. I'm running OSPF through the mGRE tunnel to the hub from the spokes and that adj. is up. Like, I said, with 'mpls ip' everything works fine, but that doesn't provide spoke-to-spoke, you must use 'mpls nhrp'.
    – Kyle
    Feb 23, 2016 at 16:27
  • I put in my route tables as well. I'm also fighting a bug with this as well. tools.cisco.com/bugsearch/bug/CSCut61985/…
    – Kyle
    Feb 23, 2016 at 16:32
  • I edited my answer based on the bug report.
    – Ron Maupin ♦
    Feb 23, 2016 at 16:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.