[EMAIL PROTECTED] wrote: > On Mon, Jun 26, 2006 at 09:22:17PM -0400, wireless wrote: > >>This cisco equipment could be filtering based on MAC addresses. > Good idea, but, nope.
MAC address filtering is but one of a myriad of things that cisco IOS can do to manage data traffic. > >>You could put one of the dhcp clients on the same LAN as the >>server and see if they work together. > > They do. That was the "testing" to which I had (vaguely) referred. > Not sure what you are exactly saying here. But if they work on the same (local) segment, then proper routing should do the rest unless the data traffic is being managed by other devices...... >>If they do, then your >>problem is your campus network security. > > > I really don't think so. Again, note the two packet dumps I posted > earlier. In both cases, we're on the same IP address, same physical > network cable; only difference is the switch from old RedHat/Dell to new > GNAP/WRAP. In both cases, networking in general works fine, inbound and > outbound connections work as expected, and the DHCP request packet gets > through. But, a dump of the DHCP packet on the RedHat box shows a lot > more data, including an ethernet address for the client, which isn't > present in a packet dump on the GNAP box. > If the cisco switches are 'managed' that means they have IOS and many, many things you can do to the configurations on the switches and the resulting traffic shaping. I do not know your network, so these suggestions are 'sanity checks'. Check the arp (cache) tables on the cisco equipment.... Also, many folks use Windows based software to configure cisco equipent, (in lieu of comman line). This often leads to multiple things happening inside the configurations of cisco routers and managed cisco switches and pix firewalls that are undesirable. Often the admins are unaware of these nuances because they do not know IOS. I'm not saying this is your problem, just sharing a little bit of info...... > While I've been in this business too long to say that anything is > impossible, it strikes me as highly unlikely that a network switch would > make a decision to edit packets like this based on the receiving end's > MAC address, unless the switch operater had some very specific measures > in place to make that happen. That's unlikely since the networking > folks are working with us on this, and saying that everything on their > end should be allowing what we want. Still, putting a dhcp client on a 'hub with the new server and a portable running ethereal will tell you much more that going through tcpdump, in my opinion. You can capture packets and watch the hanshaking (protocol negotiations) in detail and find eactly what's missing or incompatible. > Knowing that DHCP conversations are often confined to a single segment, > it wouldn't surprise me to learn that there's some kind of tunneling > operation necessary to get the broadcast DHCP request off the local > segment to where it needs to go, and it also wouldn't surprise me to > learn that the receiving end of that operation would be present in > glibc, but left out of uclibc as too rarely used to deserve the code > space. Hey, it's only a suggestion, but I always get things working on a simple flat hub (that I can sniff real time traffic with ethereal) then move to the network or Internet..... It just simplifies debugging and tracking down problems. hth, James -- [email protected] mailing list
