On Tue, Apr 11, 2006 at 11:35:44AM -0700, Sangeeta Misra wrote: > >>I got the M_BREAK cleanup ( justification and the code cleanup) checked > >>out by THiru, but yet we will test this as you point out above. > > > > > >You may be able to get rid of the b_next massaging too. If you can't, please > >restate why you need to massage b_next in ip_rput(). > > Yes. We should get rid of the b_next assigmentas well.
Ahhh, cool! Glad to help reduce lines of code. (Meem would be so proud!) > Also you state: > -------- > This part of the block comment: > > * M_BREAK are also used to pass back in multicast packets > * that are encapsulated with a source route. > > Bothers me *just* enough so that we should probably make sure we aren't > hitting this codepath. A simple test: > > ping -g <Surya-router-1> -g <Surya-router-2> 224.0.0.1 > > Would check if you get an M_BREAK on your Surya box. Assuming that's > kosher,you're in good shape. > ---------- > Can you explain how the above ping command would trigger the M_BREAK > logic? Also I plan to run this with onnv first to see if it works there. The high-probability target is Surya-router-2. It will process the source-route packet it receives, swap it's own destination for the 224.0.0.1, and then transmit it as if it originated a packet destined for 224.0.0.1. If there's any M_BREAK left relating to source routing and a multicast destination, Surya-router-2 in my example above will have to deal with it. So put onnv on Surya-router-2 (and you can even eliminate Surya-router-1 or make it onnv also), and see if it works at all. > What should surya-router-1/Surya-router-2 config be? Enable IP source route forwarding, IP forwarding, and possibly multicast forwarding on Surya-router-2. > Should it be running as multicast routers ( ie mrouted daemon). It doesn't need to run mrouted, AFAIK. > I hope this does not require multicast tunnels, as that is already broken > in onnv( I filed a bug against this). My suggested ping does NOT require multicast tunnels, fortunately. BTW, I'd suggest *eliminating* multicast tunnels in favor of our existing generic ip-in-ip tunnels instead, but that's another discussion for another time. Thanks, Dan _______________________________________________ networking-discuss mailing list [email protected]
