On Tue, Mar 23, 2010 at 11:53:18AM -0700, James Carlson wrote: > Ray Van Dolson wrote: > > I tried the following: > > > > (1) block out log quick on igb0 to igb2 from 10.49.2.111 to any > > (2) pass out log quick on igb0 to igb2 from 10.49.2.111 to any > > > > But, while these rules don't complain and seem to show matches in the > > log, the packets never reach the destination. > > > > Any suggestions? Do I _have_ to specify a next-hop? I just want the > > system to rely on its local ARP table for delivery, especially if the > > packet is destined to the local subnet... > > > > I'm wondering if I could use dup-to to duplicate the packet to igb2 > > then drop it before it goes out the igb0 interface... > > > > Any ideas? I've seen other threads discussing this, but most folks are > > able to use the nexthop/gateway for their needs... > > I suspect the other threads you've seen are subtly different -- they > represent the multihomed case, where the two interfaces in question are > on completely different networks (e.g., links to different ISPs), and > the steering logic takes advantage of that.
I did notice that seemed to be the case. > > In your case, you've got two links on the same network, so you've likely > got a fair amount of ARP confusion going on. That's probably what's > causing the behavior you're seeing. > > The really short answer is "don't do that." Use IPMP instead. It works > better and is supported. It's hard to imagine a case where it would be > advantageous to try to steer individual packets to particular interfaces > on a single network. > > However, if you do have such a case, details would be interesting to > see. Why isn't IPMP the right solution for this sort of configuration? > If it's not, have you considered 802.3ad link aggregation instead? Yep, this is probably the direction we'll go -- at least some sort of infrastructure reorganization to do this better. I was more or less curious if ipf could take care of it as well as a short-term fix while we coordinate the changes... (The short-term fix we ended up using was injecting an ARP packet into our Cisco switch's CAM tables every 10 seconds or so so it doesn't Unicast flood after the MAC for igb2 expires -- probably a static CAM table entry would have worked too... but this way I don't need to put in a request :). > > If they don't actually connect to the same network (if you have two > distinct 10.49.0.0/16 networks in your world), then I think you're off > the edge of the charted Universe. That's unlikely to work well no > matter how much hacking is done. Thanks for the feedback James. Ray > > -- > James Carlson 42.703N 71.076W <[email protected]> > -- Ray Van Dolson ESRI, Systems Administrator 909-793-2853 x2892 _______________________________________________ networking-discuss mailing list [email protected]
