arp.py reply SENDER and TARGET mac address filled as broadcast

[javierGL]

Hello,

I´ve noticed in arp.py that when arp reply packet is generated SENDER and TARGET mac address of ARP Header are filled as broadcast (FF:FF:FF:FF:FF:FF):

• Inside ARP Header sender and target IP´s are filled OK with expected values
• In Ethernet Headers the MAC src and dst are expected ones (Not broadcast).

Is there a way to fix that (or explain me how pyretic fill this arp Header in order to try to force it myself) in order that mac addresses inside of arp Header are the same as the ones in Ethernet Headers ??. Current behaviour leads to an ip-mac bind in end hosts with mac as broadcast, not the espected one from my side.

Thanks.

[ngsrinivas]

Hi javierGL,

The sender and target hardware addresses in the ARP header are set inside pyretic's packet module (pyretic/core/packet.py, see arp_packet_gen()), and subsequently in the Ryu packet generation module (pyretic/vendor/ryu/ryu/lib/packet/arp.py, see class arp constructor). We don't set them in Pyretic currently -- there's no "hardware address" field defined in pyretic. But I could imagine adding an additional parameter to the functions involved to do so.

It's reasonable to expect the target MACs to be visible on the host ARP table, but is there a reason to want that despite the controller responding to all ARPs?

[javierGL]

Thanks for answering ngsrinivas,

If host arp table is populated with broadcast mac address (by arp.py), packets sent from the host are going to be broadcasted/flooded through all ports of the network for example in case of mac_learner module (if you don´t have the mac-port bind you flood and broadcast is then flooded) and you are wasting a lot of bandwidth for traffic not needed.

am i missing something or this is the expected behavior ??

It´s very appreciate your help trying to understand better how it works.

[ngsrinivas]

javierGL, you're right that this is indeed the behavior you expect to see
with the current arp module. The arp header hardware addresses must be set
to avoid flooding when using the mac learner policy.

To get the arp controller working without flooding, you must modify the
pyretic functions mentioned in the previous response. Let me know if you're
interested in pursuing this route and we could discuss it.

Srinivas

On Sun, Aug 30, 2015 at 2:23 PM, javierGL notifications@github.com wrote:

Thanks for answering ngsrinivas,

If host arp table is populated with broadcast mac address (by arp.py),
packets sent from the host are going to be broadcasted/flooded through all
ports of the network for example in case of mac_learner module (if you
don´t have the mac-port bind you flood and broadcast is then flooded) and
you are wasting a lot of bandwidth for traffic not needed.

am i missing something or this is the expected behavior ??

It´s very appreciate your help trying to understand better how it works.

—
Reply to this email directly or view it on GitHub
#57 (comment)
.

[javierGL]

I´m interested.

I have seen the origin of the problem:
as you said:
def arp_packet_gen(): in pyretic/core/packet.py define the packet with default values arp.arp().
pkt = packet.Packet()
pkt.protocols.append(ethernet.ethernet("ff:ff:ff:ff:ff:ff", "ff:ff:ff:ff:ff:ff", ARP))
pkt.protocols.append(arp.arp())
return pkt

in pyretic/vendor/ryu/ryu/lib/packet/arp.py are defined this default values where MAC_Address are the broadcast we see when generating our arp packets:
def init(self, hwtype=ARP_HW_TYPE_ETHERNET, proto=ether.ETH_TYPE_IP,
hlen=6, plen=4, opcode=ARP_REQUEST,
src_mac='ff:ff:ff:ff:ff:ff',
src_ip='0.0.0.0',
dst_mac='ff:ff:ff:ff:ff:ff',
dst_ip='0.0.0.0'):

Thanks to your help i have understand source problem, but don´t know how to begin to add a new Header in Pyretic Packet in order to make this values access by modify function (Sender Hardware Addresses and Target Hardware Addresses) --> Very few experience in programming with Python (more Networking background)

[javierGL]

Any help in order to get what would be best way to "make accesible" HW Addresses (inside ARP Header) in Pyretic packet class ???
Don´t know what is best way to implement this change --> Some guidance in order to follow best / recommended path to do it??? Don´t really know if pyretic philosophy itself allows this definition of new header...
Any help would be very appreciate