avnish@ka.excelan.com (Avnish Aggarwal) (11/30/89)
If you have an IP router that is connected to subnets (which
are all part of the same IP network), what is the router
supposed to do with an directed IP broadcast datagram?
(i.e. destination address is <net><-1> where <net> is same
as the local net)
I had thought that the IP router would forward such
a datagram to all connected subnets. The SUN IP router does not do this.
I do not know what other routers do.
RFC 922 says that this should be possible (Section 6.2).
RFC 985 is not much help.
Any opinions?
Avnish Aggarwal
avnish@excelan.com
UUCP: {ames,sun,apple,mtxinu,cae780,sco}!excelan!avnish Avnish Aggarwal
Internet: avnish@excelan.com msd@trwind.UUCP ( ayuda) (12/06/89)
In article <794@excelan.COM> avnish@ka.excelan.com (Avnish Aggarwal) writes: > If you have an IP router that is connected to subnets (which > are all part of the same IP network), what is the router > supposed to do with an directed IP broadcast datagram? > (i.e. destination address is <net><-1> where <net> is same > as the local net) > > Any opinions? You'd like to simply rebroadcast (MAC-layer) that datagram on all connected subnets EXCEPT the one you got the original datagram from. That won't make it if there are topological cycles though because the same datagram will be back (and back ...) until it's time-to- live expires. Another way is to support RPF (reverse path forwarding). I don't have any references handy, but briefly this means that you translate the source address into a route and then only rebroadcast on those connected subnets which ARE NOT on the chosen route back to the source. If the virtual distributed routing database (a highly stable beast ;>) is self-consistent, then that should not result in a gateway/router seeing that datagram again. I personally would think counting on the consistency of the routing database is a risky business. If I were implementing a router (again), I'd only do rebroadcasting if I also implemented a cache of source addresses and IP ID numbers which could be checked. Since whole-network broadcasts of that type are pretty expensive, you'd hope that implementors would only resort to them as a last ditch effort to find some resource which could then be directly talked to, so the checking of such a cache should be infrequent during times of network stability. When it's not stable, who can blame the router if it errs in a conservative manner by pitching abundant broadcasts? Also, I'd relegate the processing of such broadcasts to a lower priority processing thread than the handling of other traffic of the same precedence. Happy Holidays! ++msd