This topic is to discuss the following lesson:
Will this issue not arise in tunnel intended to pass both Unicast and Multicast?
Hello Deep
First of all, one major difference between unicast and multicast routing is that for unicast routing, we only care about the destination and how to get there. For multicast routing, we care about the source as well. PIM uses the unicast routing table to check what interface will be used to reach the source. More on this can be found at this lesson.
Now to your question. If a GRE tunnel is used only for multicast traffic, then there will be no unicast routing
information concerning routes over the GRE tunnel. Therefore you will run into the RPF problem. If you do use unicast over the GRE tunnel, unicast routes will be available and you will not have the RPF problem.
I hope this has been helpful!
Laz
1 Like
PIM sparse solution:
In R2 conf you have:
ip mroute 192.168.1.0 255.255.255.0 192.168.12.1
ip mroute 1.1.1.1 255.255.255.255 192.168.12.1
ip route 0.0.0.0 0.0.0.0 192.168.23.3
If you wouldn’t have “ip mroute 192.168.1.0 255.255.255.0 192.168.12.1” your unicast would go by the traditional path instead of the tunnel. Isn’t it? And in that way it wouldn’t work, am I right?
Then in R1 you don’t have any ip mroute. Should we also route the unicast traffic by the tunnel?
If we have a bidir multicast implementation with a GRE tunnel, would it work? But in that case my question about mroute in R1 would make sence, isn’t it?
Hello Miguel
First of all, remember that the mroute commands refer only to multicast traffic, so whether you implement the ip mroute 192.168.1.0 255.255.255.0 192.168.12.1 command or not will not affect the unicast traffic.
This command is implemented in order to verify that the RPF check is passed. The RPF check essentially checks to see if the source IP address of the multicast traffic is reachable via a routing entry in the routing table that matches the interface via which the packet entered the router. If this check is not passed, the packet is dropped. In order for this check to be passed, the ip mroute 192.168.1.0 255.255.255.0 192.168.12.1 command is implemented, thus satisfying the requirements of the check.
Once again, the mroute commands do not apply to unicast traffic. However, in order for unicast traffic to successfully traverse the tunnel, the appropriate routes must be installed in the routing table.
Remember that the above command was implemented not to enable bidirectional multicast traffic, but to satisfy the RPF check. If the RPF check is satisfied, then multicast will function correctly over a GRE tunnel.
I hope this has been helpful!
Laz
Thanks for your explanation.
I understand better the use of ip mroute.
But I still have 2 questions:
-
In the case you have R1-R2-R3*(RP)-R4-R5, with senders and receivers in all R%, would you have to configure ip mroute in R1,R2,R4 and R5?
In the case you have many senders and receivers in both sides R1 and R2, and a tunnel between them, would you recommend to implement pim sparse-dense mode or bidir multicat implementation?
I have in the lab 2 L3 in this config:
SW-R1-R2-SW2
I have R1 and R2 with pim sparse-dense-mode + ip routing
I used:
ip routing
ip multicast-routing distributed
router eigrp 100
network 0.0.0.0 0.0.0.0
exit
I didn’t use ip mroute. And even having senders and receivers in both sides they were communicating well in multicast.
why didn’t I need ip mroute?
Hello Miguel
The mroute command to take care of the RPF failure should be configured only on routers that terminate a GRE tunnel, and that have multicast receivers connected to them. Remember the configuration is done only to solve the RPF failure that occurs at the end of a GRE tunnel.
In your scenario, the most likely case is that the RPF condition is met, and so you don’t need to add any additional mroute commands. To verify this in your setup, check to see if the RPF condition is met in your routers. Remember that the RPF check ensures that a route to the source IP of a packet exists using the interface from which the packet entered the router. More about the RPF check can be found at the Multicast RPF lesson.
I hope this has been helpful!
Laz
Just one more questions regarding this discussion Multiscat tunnel rpf failure:
From S1 and H1 you must ping: Tunnel source, destination and both tunnel IPs.
Is it true? Or not necessarily an obligation.
Hello Miguel
With this configuration, S1 can only ping R1 and the ISP router while H1 can only ping R2 and the ISP router. Because the ISP router doesn’t include a route to 192.168.3.0/24 full connectivity is not available. Also, S1 and H1 can only ping the tunnel IP on the router they are connected to.
But this connectivity is not necessary to make this topology work. The important thing here is to ensure that multicast routing can occur via the tunnel interface.
I hope this has been helpful!
Laz
Hi Rayan
i did what have been explained
but when i use MCAST TOOL
i don’t get any ping for multicast traffic from sender and receiver
i feel tired from one month i am trying to forward Multicast over a GRE tunnel
i used ospf in gre tunnel but multicast not warking
also i used static ip ( for isp) then i implmanted ospf in GRE
also i didnt get any replay for multicast traffic
i used auto RP config
i cant get RP in both router when i use comand ( show ip pim rp maping )
but still no multicast for voice traffic
note: the unicast is working perfect
what is the best config to forward multicast (voice) over GRE tunnel ?
i did this lab ON ASR901 ROUTER
Hello Ridhwan
From your description, I can’t determine a reason for your multicast traffic not going over your GRE tunnel. GRE tunnels do indeed support auto-RP. I’m not quite sure what you mean by this statement:
Can you clarify?
in any case, I suggest you take a look at this detailed documentation of how to configure multicast over a GRE tunnel. There are some prerequisites and restrictions that you should keep in mind as you configure. I believe this document should cover most if not all of what you need.
Give it a try and let us know your results!
I hope this has been helpful!
Laz
How does this work with Source Specific Multicast over GRE? Can this be done?
Hello Mark
Yes, of course, you can set up SSM to run over a GRE tunnel. It will work just fine. But just like any other multicast implementations over GRE, SSM is also susceptible to the RPF failure over a GRE tunnel IF the tunnel is used exclusively for multicast traffic. The resolution to this RPF failure problem is the same as that in the lesson, adding a static route to resolve the issue.
I hope this has been helpful!
Laz
Dear Lazaros Agapides,
I am writing to you today to report an issue with Multicast over GRE in Cisco ASR901 routers. I have noticed that when I configure Multicast over GRE on an ASR901 router, it does not work as expected. However, when I configure the same thing on an ISR router, it works fine.
I have reported this issue to Cisco and they are aware of it and working on a fix. However, there is currently no ETA for a fix.
In the meantime, we need to find a suitable solution for the passage of voice data packets between ASR901 routers. Can you help us find a solution?
We appreciate your assistance in this matter.
Sincerely,
Ridhwan
example of configuration
version 15.6
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
boot-start-marker
boot-end-marker
!
!
!
!
!
!
!
no ip domain lookup
ip multicast-routing
ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!
redundancy
!
no cdp log mismatch duplex
!
ip tcp synwait-time 5
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
ip address 1.1.1.1 255.255.255.255
ip pim sparse-mode
ip ospf 1 area 0
!
interface Tunnel1
ip address 192.168.12.1 255.255.255.0
ip pim sparse-mode
ip ospf 1 area 0
tunnel source 192.168.13.1
tunnel destination 192.168.23.2
!
interface GigabitEthernet0/1
no ip address
negotiation auto
service instance 1 ethernet
encapsulation untagged
bridge-domain 10
int vlan 10
ip address 192.168.1.254 255.255.255.0
ip pim dense-mode
duplex auto
speed auto
media-type rj45
!
interface GigabitEthernet0/2
ip address 192.168.13.1 255.255.255.0
duplex auto
speed auto
media-type rj45
!
interface GigabitEthernet0/3
no ip address
duplex auto
speed auto
media-type rj45
!
router ospf 1
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
ip pim autorp listener
ip pim send-rp-announce Loopback0 scope 10 interval 10
ip pim send-rp-discovery Loopback0 scope 10 interval 10
ip route 0.0.0.0 0.0.0.0 192.168.13.3
!
!
!
version 15.6
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname ISP
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
ethernet lmi ce
!
!
!
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
!
!
!
!
!
no ip icmp rate-limit unreachable
!
!
!
!
!
!
no ip domain lookup
ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!
redundancy
!
no cdp log mismatch duplex
!
ip tcp synwait-time 5
!
!
!
!
!
!
!
!
!
!
!
!
!
interface GigabitEthernet0/0
no ip address
duplex auto
speed auto
media-type rj45
!
interface GigabitEthernet0/1
no ip address
negotiation auto
service instance 1 ethernet
encapsulation untagged
bridge-domain 10
interface GigabitEthernet0/2
negotiation auto
service instance 1 ethernet
encapsulation untagged
bridge-domain 11
int vlan 10
ip address 192.168.13.3 255.255.255.0
int vlan 11
ip address 192.168.23.3 255.255.255.0
!
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
ip route 1.1.1.1 255.255.255.255 192.168.13.1
ip route 192.168.1.0 255.255.255.0 192.168.13.1
ip route 192.168.2.0 255.255.255.0 192.168.23.2
!
!
Building configuration...
Current configuration : 3507 bytes
!
! Last configuration change at 16:57:59 UTC Wed Aug 2 2023
!
version 15.6
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R2
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
ethernet lmi ce
!
!
!
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
!
!
!
!
!
no ip icmp rate-limit unreachable
!
!
!
!
!
!
no ip domain lookup
ip multicast-routing
ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!
redundancy
!
no cdp log mismatch duplex
!
ip tcp synwait-time 5
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Tunnel1
ip address 192.168.12.2 255.255.255.0
ip pim sparse-dense-mode
ip ospf 1 area 0
tunnel source 192.168.23.2
tunnel destination 192.168.13.1
!
!
interface GigabitEthernet0/1
service instance 1 ethernet
encapsulation untagged
bridge-domain 10
!
interface GigabitEthernet0/2
service instance 1 ethernet
encapsulation untagged
bridge-domain 11
int vlan 10
ip address 192.168.23.2 255.255.255.0
int vlan 11
ip address 192.168.2.254 255.255.255.0
ip pim sparse-mode
ip igmp join-group 239.1.1.1
ip ospf 1 area 0
duplex auto
speed auto
media-type rj45
!
!
interface GigabitEthernet0/3
no ip address
duplex auto
speed auto
media-type rj45
!
router ospf 1
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
ip pim autrp
ip route 0.0.0.0 0.0.0.0 192.168.23.3
!
Hello Ridhwan
It’s unfortunate that the ASR901 is having such problems in implementing multicast over a GRE tunnel. If you get more info about it from Cisco we’d be interested in hearing more about the fix they suggest.
From my understanding, you want to create a tunnel between two ASR901s over the Internet or some other network, that will be able to carry multicast traffic as well, correct? Some alternatives you can consider include:
Now not all of these technologies are geared towards this particular setup, and I am not sure if all of these are supported by the ASR901. However, they may provide a temporary solution for your specific problem. All of the above technologies support multicast.
Alternatively, you may have to look at the possibility of either temporarily replacing the hardware with something that supports multicast over GRE, or of making changes to the services you are running over the network such that multicast won’t be necessary. Such decisions are not always easy but may be required to resolve the issue at hand. Let us know how you get along!
I hope this has been helpful!
Laz
In your configuration examples on
ISP: ip route 192.168.2.0 255.255.255.0 192.168.23.2
R2: interface GigabitEthernet0/1
ip address 192.168.2.254 255.255.255.0
it is supposed to be 3.254 respectively for R2 and 3.0 for ISP.
Was not sure if this was corrected before.
Matt
Hello Matt
Yes, you’re right The diagram shows 192.168.3.0/24 as the network of the Gi0/1 interface of R2. However, in all of the configurations and text of the lesson, it is 192.168.2.0/24. So the diagram is incorrect. I will let Rene know to make the correction.
Thanks for pointing that out!
Laz