This topic is to discuss the following lesson:
Thanks for that interesting lesson.
I have some simple questions :
**-1-**
For fixing the issue by the “sub-interfaces” solution ; I guess, there will create 2 sub-interfaces (one for each PVC) ? I guess also that the 2 sub-interfaces will be configured with 2 different subnets ? According to my understanding of split-horizon ; 1 (only 1) sub-interface on R1 will have the same point-to-multipoint issue as the physical interface ?
**-2-**
I do not understand how the tunnel between R2 and R3 could work, if there’s no PVC between the two routers and there is nothing on R1 for “forwarding” information between R2 and R3.
**-3-**
By the way ; there’s a copy/paste error in first configuration lines. See below :
**R1**(config)#interface serial 0/0
R2(config-if)#ip pim sparse-dense-mode
**R1**(config)#interface serial 0/0
R3(config-if)#ip pim sparse-dense-modeWe have a split horizon issue here since with the physical point-to-multipoint interface, there is only one interface. With sub-interfaces, you would have two logical interfaces on the hub router. This does mean that you have a different subnet for each PVC yes. You won’t have any split horizon issues anymore since the hub uses a different logical interface for each spoke router.
I see I didn’t include the unicast routing configuration in this lesson, that’s something I will fix. The tunnel uses the 2.2.2.2 and 3.3.3.3 addresses but those have to be known on both spoke routers. Sorry for the confusion!
Thanks for sharing the typo, just fixed it.
could disabling spit horizon on the tunnel be a solution as well?
I configured this up and I never could get auto-rp information to go to the 2nd spoke even when split horizon was disabled on the hub router. Therefore, it seems the only way that multicast will forward multicast traffic is if the OIL is different than the ingress interface
test topology
spoke #1>hub>spoke #2
Note: I configured spoke #1 as both the RP and MA as an experiment and I configured an igmp-join on spoke #2 to see what would happen if I disabled split-horizon on the hub. when sourcing from spoke #1 going to the mcast address traffic never made it.
Hi Roland,
The split-horizon command only applies to distance vector routing protocols (RIP and EIGRP), not to multicast. You can configure the interface to forward multicast traffic that you received on that interface with the NBMA mode:
However, I don’t think that works for AutoRP traffic. If you have the RP and MA on one spoke, then probably the only way to make it work is either by tunneling or using sub-interfaces.
Rene
Hi Rene and Everyone
Thanks for Exciting Lessons.
I have a questions.
I try to verify this lesson on DM-VPN environment. But I don’t have satisfied results.
I create a tunnel between R2 and R3 so that R3 can learn from the mapping agent directly.
After, I look at R3 to see if it learns anything.
R3#show ip mroute 224.0.1.40
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
Q - Received BGP S-A Route, q - Sent BGP S-A Route,
V - RD & Vector, v - Vector, p - PIM Joins on route,
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 2d08h/00:02:38, RP 0.0.0.0, flags: DCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Loopback0, Forward/Sparse-Dense, 2d08h/stopped
Tunnel0, Forward/Sparse-Dense, 2d08h/stopped
R3#
Why don’t have (2.2.2.2, 224.0.1.40) on R3?
Each Router basic Configuration is following.
â—†R1
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
!
crypto isakmp key cisco address 0.0.0.0
crypto isakmp keepalive 30
!
crypto ipsec transform-set TS-IPSEC1 esp-3des esp-md5-hmac
mode transport
!
crypto ipsec profile PRO-DMVPN1
set transform-set TS-IPSEC1
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Gi0/1
ip address 100.1.1.1 255.255.255.0
!
interface tunnel0
ip address 192.168.123.1 255.255.255.0
tunnel source Gi0/1
tunnel mode gre multipoint
tunnel key 10
tunnel protection ipsec profile PRO-DMVPN1
ip nhrp network-id 100
ip nhrp map multicast dynamic
ip ospf network broadcast
!
ip route 0.0.0.0 0.0.0.0 100.1.1.100
!
router ospf 1
router-id 1.1.1.1
network 192.168.123.1 0.0.0.0 area 0
network 1.1.1.1 0.0.0.0 area 0
!
â—†R2
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
!
crypto isakmp key cisco address 0.0.0.0
crypto isakmp keepalive 30
!
crypto ipsec transform-set TS-IPSEC1 esp-3des esp-md5-hmac
mode transport
!
crypto ipsec profile PRO-DMVPN1
set transform-set TS-IPSEC1
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface Gi0/1
ip address 100.2.2.2 255.255.255.0
!
interface tunnel0
ip address 192.168.123.2 255.255.255.0
tunnel source Gi0/1
tunnel mode gre multipoint
tunnel key 10
tunnel protection ipsec profile PRO-DMVPN1
ip nhrp network-id 100
interface tunnel0
no ip nhrp map 192.168.123.1 1.1.1.1
no ip nhrp map multicast 1.1.1.1
ip nhrp map 192.168.123.1 100.1.1.1
ip nhrp map multicast 100.1.1.1
ip nhrp nhs 192.168.123.1
ip ospf network broadcast
ip ospf priority 0
!
ip route 0.0.0.0 0.0.0.0 100.2.2.100
!
router ospf 1
router-id 2.2.2.2
network 192.168.123.2 0.0.0.0 area 0
network 2.2.2.2 0.0.0.0 area 0
!
â—†R3
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
!
crypto isakmp key cisco address 0.0.0.0
crypto isakmp keepalive 30
!
crypto ipsec transform-set TS-IPSEC1 esp-3des esp-md5-hmac
mode transport
!
crypto ipsec profile PRO-DMVPN1
set transform-set TS-IPSEC1
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface Gi0/1
ip address 100.3.3.3 255.255.255.0
!
interface tunnel0
ip address 192.168.123.3 255.255.255.0
tunnel source Gi0/1
tunnel mode gre multipoint
tunnel key 10
tunnel protection ipsec profile PRO-DMVPN1
ip nhrp network-id 100
interface tunnel0
no ip nhrp map 192.168.123.1 1.1.1.1
no ip nhrp map multicast 1.1.1.1
ip nhrp map 192.168.123.1 100.1.1.1
ip nhrp map multicast 100.1.1.1
ip nhrp nhs 192.168.123.1
ip ospf network broadcast
ip ospf priority 0
!
ip route 0.0.0.0 0.0.0.0 100.3.3.100
!
router ospf 1
router-id 3.3.3.3
network 192.168.123.3 0.0.0.0 area 0
network 3.3.3.3 0.0.0.0 area 0
!
â—†ISP
hostname ISP
int g0/1
ip add 100.1.1.100 255.255.255.0
!
int g0/2
ip add 100.2.2.100 255.255.255.0
!
int g0/3
ip add 100.3.3.100 255.255.255.0
!
ip route 1.1.1.1 255.255.255.255 100.1.1.1
ip route 2.2.2.2 255.255.255.255 100.2.2.1
ip route 3.3.3.3 255.255.255.255 100.3.3.1
!
Hello Yoichi
There are several things that may result in what you’re seeing. From the configs you’ve posted, at first glance, I don’t see anything that immediately points to a problem. However, keep the following guidelines in mind:
- I don’t see any mapping agent or RP configurations on R1 or R2 like in the lesson. Have you omitted those from the configs you shared or maybe they haven’t been configured?
- Have you verified that R2 and R3 PIM neighbors of R1?
- Is R1 (the RP) receiving information from the mapping agent?
- Have you confirmed that the DMVPN is working correctly and that the RP and mapping agent configs are also correct?
These are just some points where you can start your troubleshooting process. Let us know how you get along so that we can help you further in the resolution of your network problem.
I hope this has been helpful!
Laz
Hi Lazaros
Thank you for your reply.
There was no problem with the above confirmation items. When I checked the routing table of each router after creating the tunnel between R2 and R3, it seems that the route using the created tunnel is not the optimum route. Is this result correct?
Topology
R2 (config) #interface tunnel 23
R2 (config-if) #tunnel source loopback 0
R2 (config-if) #tunnel destination 3.3.3.3
R2 (config-if) #ip address 192.168.23.2 255.255.255.0
R2 (config-if) #ip pim sparse-dense-mode
R3 (config) #interface tunnel 23
R3 (config-if) #tunnel source loopback 0
R3 (config-if) #tunnel destination 3.3.3.3
R3 (config-if) #ip address 192.168.23.3 255.255.255.0
R3 (config-if) #ip pim sparse-dense-mode
R2 # sh ip route 3.3.3.3
Routing entry for 3.3.3.3/32
Known via "ospf 1", distance 110, metric 1001, type intra area
Last update from 192.168.123.3 on Tunnel0, 01:23:48 ago
Routing Descriptor Blocks:
* 192.168.123.3, from 3.3.3.3, 01:23:48 ago, via Tunnel0
Route metric is 1001, traffic share count is 1
R2 #
R3 # sh ip route 2.2.2.2
Routing entry for 2.2.2.2/32
Known via "ospf 1", distance 110, metric 1001, type intra area
Last update from 192.168.123.2 on Tunnel0, 01:23:03 ago
Routing Descriptor Blocks:
* 192.168.123.2, from 2.2.2.2, 01:23:03 ago, via Tunnel0
Route metric is 1001, traffic share count is 1
R3 #
Hello Yoichi
This behavior is correct. In the lesson, Rene states that the use of a tunnel between the MA and the other spoke is a solution for a Frame-Relay topology. However, a DMVPN topology uses NHRP to exchange routes between spokes and to dynamically create tunnels between spokes. This means that the use of a tunnel is not a solution for a DMVPN topology.
When using NHRP, the next-hop address learned via NHRP always overwrites any other routing that may be present from other sources. That includes the direct tunnel that you created. If you take a look at the routing tables, you will see a % sign in the routing entry that has been learned via NHRP that looks something like this:
Spoke2#show ip route ospf | include 2.2.2.2
O % 2.2.2.2 [110/2001] via 172.16.123.1, 00:06:19, Tunnel0
That indicates that this is an override route, where NHRP has overridden any other routing. More about this feature can be found in this lesson:
So for your DMVPN topology, you will have to examine the other solutions to this problem to allow for multicast operation.
Let us know how you get along in your implementation!
I hope this has been helpful!
Laz
1 Like
Hi Lazaros
Thank you for your reply.
I changed to same network segment between hub and spoke. So I could get expect result.
In my environment, I couldn’t confirm the notation that the route was overwritten by NHRP, but I’m glad that I was able to achieve the purpose of this lesson for the time being.
1 Like