On Mon, Mar 21, 2005 at 08:45:36AM +0000, Cyprian Clement wrote: > Hi Peter, > > Yes, you are absolutely right. It's a serious mistake from my side. > Somehow I have just been pressing reply button without > double-checking whether the addresses included the vlan community > address. I have realised that i have actually done this to few > other community members, not only you, which is a big mistake of > course. Thanks for bringing it into my attention as now i see the > mistake i have been doing. I will be careful in future. That's excellent! :) > On Fri, Mar 18, 2005 at 02:15:18PM +0000, Cyprian Clement wrote: > > Hi Peter, > > > > Thanks so much for your email with these useful answers to my > > query. We just happened to have a specific test where we were > > looking for a possibility of several VLANs with the same IP addr. > > But thanks for you help. > > > > By the way, do you know of any way or tool that i can use at linux > > level to test the vlans i have created on on my linux machines. In > > other words to try at linux level to send packets over different > > vlans and check if they are mapped/sent to a correct vlan(s). > > Yes, but unless you are interested in negotiating a private support > contract, your message should be sent to the list. I will not answer > this message in private. Since you want to have the same IP address on more than one interface I suggest you create a bridge and add those interfaces to the bridge, all using the brctl tool. Also make sure 802.1d Ethernet Bridging is enabled in the kernel. Then, assign the desired IP address to the new bridge interface instead of any of the member interfaces in the bridge. With this setup, you can control which traffic is sent to which interface (ie. VLAN) using iptables and the physdev match in 2.6 kernels. Another trick is to filter at a lower using ebtables. http://ebtables.sf.net/ As for analyzing network traffic, I saw another poster mentioning packet sniffers, which are great tools. To get the best results you will want to run the packet sniffer (tcpdump, ngrep, snort, ethereal, etc) on a separate machine from the one(s) involved in the communication. I always use a hub (_not_ a switch) to tap into ethernet communication, and run the sniffer on a dedicated system, usually a laptop, also connected to the hub. To clarify: Disconnect the ethernet cable from one of the communicating systems and connect it to the hub, usually to the uplink port. If the hub is too simple to have an uplink or crossover port, you may have to switch to a crossover cable. Then, using a regular cable, connect the hub to the system. This puts the hub conveniently in the way of any traffic. Finally connect a laptop or other available system to another port of the hub, using a regular cable. The laptop will now see any and all traffic going through the hub. This is really the only way to be sure about what is sent on the network, since either communicating system's networking stack may consume or delay packets before the packet sniffer can get to see them, had it been run on the sending or receiving system. Yes, this requires a hub and another system, but that's a small price to pay to be really sure about what is going on. Hope this helps! //Peter
