02-08-2013 07:26 AM - edited 03-04-2019 06:58 PM
Hi All,
Best way to do this is probably short and simple:
On a hub-and-spoke network where EIGRP is the routing protocol, there are PCI-compliant spoke sites, that look like this:
Spoke Site to Hub Site from Spoke-LAN-Edge to Data Center Hub Router:
3COM Switch----EIGRP Cisco Router w/ DMVPN configs---Watchguard FW-----Broadband Cable Modem----ISP Cloud-----EIGRP DMVPN hub router at Data Center
Question:
If EIGRP isn't understood by non-Cisco devices, then why does this work? In order for the spoke router to form a neighborship with the hub router, EIGRP traffic has to be exchanged. How is that possible if the Watchguard & Modem are non-Cisco devices?
The only thing that makes sense to me is that the EIGRP rule only applies to Routers, meaning non-router devices can be anything, as long as Cisco is the router model.
Is this correct?
Solved! Go to Solution.
02-08-2013 08:36 AM
So basically, my data center sends a multicast packet out 224.0.0.10 to all of my spoke sites to form the neighborship. In this case, I am guessing the Watchguard sees it as an encapsulated multicast packet and doesn't see it as EIGRP, which is why it works ?
Correct...
What about the 3COM switch at the LAN edge? If I wanted to send traffic from the data center to a PC station connected to the 3COM switch, would the 3COM switch ever know anything about the EIGRP?
Traffic from your DC till PC will be following EIGRP shown route till spoke. Once it reaches Spoke, it will follow either static route or switch it to exist interface ( depending upon your configuration.
What if the 3COM switch was in between two local EIGRP Cisco routers? Would EIGRP still work as long as the layer 3 devices were Cisco?
As long as multicast IP 224.0.0.10 is not block in between Cisco devices, EIGRP will form neighbourship. However important point to remember in this case is that 224.0.0.10 has got Multicast spoke of local and hence it will never transverse a routed boundary.
Regards,
Smitesh
02-08-2013 07:33 AM
Hi Dean,
The piece you are missing it that EIGRP uses multicast for its neighbor discovery ( 224.0.0.10 ).
So what ever the device comes in between; as long as it supports multicast; EIGRP will work.
Secondly, in the scenario which you have posted, EIGRP traffic are encapsulated into the GRE packet and hence would never be seen as EIGRP traffic to Watchgaurd or any other thing.
Regards,
Smitesh
PS: Please rate helpful posts.
02-08-2013 08:18 AM
Hi Smitesh,
Thank you for responding. A couple follow ups:
So basically, my data center sends a multicast packet out 224.0.0.10 to all of my spoke sites to form the neighborship. In this case, I am guessing the Watchguard sees it as an encapsulated multicast packet and doesn't see it as EIGRP, which is why it works?
What about the 3COM switch at the LAN edge? If I wanted to send traffic from the data center to a PC station connected to the 3COM switch, would the 3COM switch ever know anything about the EIGRP?
What if the 3COM switch was in between two local EIGRP Cisco routers? Would EIGRP still work as long as the layer 3 devices were Cisco?
02-08-2013 08:36 AM
So basically, my data center sends a multicast packet out 224.0.0.10 to all of my spoke sites to form the neighborship. In this case, I am guessing the Watchguard sees it as an encapsulated multicast packet and doesn't see it as EIGRP, which is why it works ?
Correct...
What about the 3COM switch at the LAN edge? If I wanted to send traffic from the data center to a PC station connected to the 3COM switch, would the 3COM switch ever know anything about the EIGRP?
Traffic from your DC till PC will be following EIGRP shown route till spoke. Once it reaches Spoke, it will follow either static route or switch it to exist interface ( depending upon your configuration.
What if the 3COM switch was in between two local EIGRP Cisco routers? Would EIGRP still work as long as the layer 3 devices were Cisco?
As long as multicast IP 224.0.0.10 is not block in between Cisco devices, EIGRP will form neighbourship. However important point to remember in this case is that 224.0.0.10 has got Multicast spoke of local and hence it will never transverse a routed boundary.
Regards,
Smitesh
02-08-2013 11:38 AM
Thank You Smitesh. I appreciate your help.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide