In one of my previous posts I have mentioned great piece of software called PackEth and I have also promised that will write up a separate article about it as I just think this amazing tool deserves as much attention as I can give it. So what does this software do? Well let me quote the author ” PackETH is GUI and CLI packet generator tool for Ethernet…It allows you to create and send any possible packet or sequence of packets on the Ethernet link.” I would add that that it is the only tool I have found that actually allows you to assemble Ethernet frames and a IP packets that actually does what you would expect it to do while being multi-platform and incredibly stable. I think I have never seen it crashing which speaks for itself. This article will focus around version 1.6 as that is the one that has both Linux and Windows versions available. The drawback is that at the time of writing the L3 IPv6 support is not included.
DHCP option 82 and DHCP relay
I was actually playing with DHCP relay and what I did find out is kind of interesting. For what is DHCP relay look for rfc3046 .
In short it is when the client sends a DHCP a broadcast message (discover) some device – usually the switch that is the client directly connected to – intercepts the packet and sends a unicast discover instead of it to remote server over L3. The advantage is that the amount of boadcasts in the networks drops and secondly the DHCP server can be in different subnet. This is great because you can now use centralised dhcp server for all networks.
Unlocking cisco devices for unsupported SFPs
Cisco as well as many other vendors locks their equipment to only work with their own branded SFPs. The problem is that none of the big vendors actually manufactures the modules themselves – they use 3rd parties like avago or finisar. This extremely shameful practice is wide spread so almost everyone does this – Cisco, Juniper, Brocade or NetApp all are guilty of this. One issue is price – the aforementioned companies are willing to ask you 10 or even 100 times more for a branded sfp under the pretense of supportability.
EtherSam (Y.1564) explained
This is the last article (at least for now) from the series about testing methodologies and testing standards. I will cover some bits and pieces in the region of testing in general but it won’t be as heavy on the theory as I want to write some “hands-on” scenarios for combined use of Wireshark and PackEth as well as about some multicast scenarios. Also I will be doing more Cisco and Juniper stuff so it is quite likely I will be blogging some configs and labs. Anyway enough about the future plans and let’s start with the topic at hand.
Port isolate vs. Mac Forced Forwarding
Let me first say that these two features are supposed to do very similar things – they are designed to separate access users so their traffic cannot go directly between them without any control. The firs possible solution is a port-isolate command which separates L2 and L3 traffic between the isolated (access) ports. This leads to complete separation with all the advantages and disadvantages. The biggest disadvantage is that all traffic trunked up to another switch where it will be dealt with – usually it will be routed. As the separation is also on L2 and L3 you cannot use arp proxy which could resolve the overhead on access switch. The advantage is that the separation is absolute which could be quite useful in ISP’s access networks.