In case no one else has suggested it: the source MAC address will identify the source. Chris
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Scott Morris Sent: Sunday, August 21, 2005 9:21 AM To: 'Tom Sanders'; nanog@nanog.org Subject: RE: Rip again!
How about the source IP?
RIP v1 is sent to 255.255.255.255 broadcast. RIPv2 is sent to 224.0.0.9 multicast. Both are local-link only, so won't go THROUGH a router. The sending source IP will tell you where they came from.
If you're using VLANs (trunks), there won't be any issues. If you're using secondary addresses, this will depend on whose devices you use. In the Cisco world, packets will always be sourced from the primary IP address on an interface. And if the receiving router doesn't have a subnet matching the sender, packets/updates are ignored. (Again, Cisco world you can use "no validate-update-source" to override this check)
But that gives you a tracking method on packets.
Scott
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Tom Sanders Sent: Sunday, August 21, 2005 12:13 PM To: nanog@nanog.org Subject: Rip again!
Hi,
There isnt IMO a way in RIP to identify the source of the RIP packet (the way we have Router ID in OSPF, system ID in ISIS, etc.)
Now assume we have 2 vlans defined on an ethernet. Thus we would have two IP interfaces, 1.1.1.1/24 and 2.2.2.2/24 and both using the same physical interface. RIP is running on both these interfaces.
My doubt is that how will another router, which is configured in the same way (2 vlans) be able to differentiate between the RIP responses originated by 1.1.1.1 and 2.2.2.2?
Thanks, Toms
Chris Ranch wrote:
In case no one else has suggested it: the source MAC address will identify the source.
You can also can play with the routing tag within each RIP routing entry if your implementation is flexible enough.
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Scott Morris Sent: Sunday, August 21, 2005 9:21 AM To: 'Tom Sanders'; nanog@nanog.org Subject: RE: Rip again!
How about the source IP?
RIP v1 is sent to 255.255.255.255 broadcast. RIPv2 is sent to 224.0.0.9 multicast. Both are local-link only, so won't go THROUGH a router. The sending source IP will tell you where they came from.
If you're using VLANs (trunks), there won't be any issues. If you're using secondary addresses, this will depend on whose devices you use. In the Cisco world, packets will always be sourced from the primary IP address on an interface. And if the receiving router doesn't have a subnet matching the sender, packets/updates are ignored. (Again, Cisco world you can use "no validate-update-source" to override this check)
But that gives you a tracking method on packets.
Scott
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Tom Sanders Sent: Sunday, August 21, 2005 12:13 PM To: nanog@nanog.org Subject: Rip again!
Hi,
There isnt IMO a way in RIP to identify the source of the RIP packet (the way we have Router ID in OSPF, system ID in ISIS, etc.)
Now assume we have 2 vlans defined on an ethernet. Thus we would have two IP interfaces, 1.1.1.1/24 and 2.2.2.2/24 and both using the same physical interface. RIP is running on both these interfaces.
My doubt is that how will another router, which is configured in the same way (2 vlans) be able to differentiate between the RIP responses originated by 1.1.1.1 and 2.2.2.2?
Thanks, Toms
-- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387 The information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster@globalstar.com
participants (2)
-
Chris Ranch -
Crist Clark