2

Can anyone explain how exactly works translation from broadcast to unicast? What is changed or modified in IP packet? Already I have read how it works and configured it properly for my network but still main question has left.

Example: I want to create IP helper from whole subnet 192.168.1.0/24(R1) to 192.168.2.0/24(R2) To manage this I have configured:

R1:
- ip forward-protocol 10,
- int vlan100
    ip addr 192.168.1.254
    ip helper-address 192.168.2.255

R2:
- access-list 200 permit udp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 eq 10
- int vlan200
    ip addr 192.168.2.254
    ip directed-broadcast 200

Now when I take a look on wireshark it looks like: PCA sends packet to 192.168.2.255 with source 192.168.1.10 and here is the question how that 192.168.2.255 is translated to unicast? At R2 it's source 192.168.1.10 and dest 255.255.255.255 with ff:ff:ff:ff:ff:ff

Improve this question
  • 3
    You seem to be attempting to use two/three features: ip helper-address, ip forward-protocol and ip directed-broadcast, where the first two of these come with some default ports list they act upon, but these features are doing different things. What is the goal of this configuration? – Marc 'netztier' Luethi Apr 16 '19 at 10:24
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer. – Ron Maupin♦ Dec 15 '19 at 2:02
4

There's no translation or modification of a packet.

The router receive a broadcast packet that contains a DHCP request. Then it send a new unicast packet to the configured DHCP server requesting a lease on behalf of the host. Among other thing it contains the MAC address of the host.

The DHCP server send the response to the router. Then the router send an unicast packet to the originator (since it knows its mac address), and so on.

In human language it's something like:

  • host: yell "Hello, I'm Joe, I need an IP address"
  • router: ear Joe and send a call to DHCP "Joe need an IP address, can you give me one?"
  • DHCP: respond to router "Sure, I can give Joe IP address A"
  • router: respond to Joe "You can get IP address A, is it ok for you?" etc...
Improve this answer
  • That is correct for the DHCP relay feature of ip helper-address, but I think the OP is trying to achieve/understand something else, what with udp/10 being in the mix. – Marc 'netztier' Luethi Apr 16 '19 at 10:25
  • Ok, but how we determine that new packet is unicast? If it's sitll addressed as broadcast x.x.x.255? I'm using other proto than DHCP but as I understand it works in similar way. – szkolek Apr 16 '19 at 10:49
  • Just for reference DHCP relaying is defined to be the same as BOOTP relaying, as laid out in some detail of section 4 of RFC 1542 "Clarifications and Extensions for the Bootstrap Protocol". tools.ietf.org/html/rfc1542 – jonathanjo Apr 16 '19 at 11:58
1

I'll base my answer on what I believe to have understood from your description, which is this:

  • R1 has a directly a attached subnet with 192.168.1.254 ( I'll assume /24)
  • R2 has a directly a attached subnet with 192.168.2.254 ( I'll assume /24)
  • there is some form of connectivity between R1 and R2, distinct from these two subnets.
  • adjacent to R1, there is a sender (192.168.1.10), broadcasting "something" to 192.168.1.255 or 255.255.255.255, with udp port 10.
  • Goal: you want the sender's udp/10 broadcast to be picked up by R1, be forwarded towards R2, and be disseminated in R2's attached subnet as a broadcast.

Based on the config snippets you gave, this is what will be happening:

  • PC1 at R1 broadcasts an udp/10 packet to 255.255.255.255 or 192.168.1.255 (src: 192.168.1.10, dst ...255)
  • on R1, interface vlan100with ip helper 192.168.2.255 will pick up that broadcast (because it's been enabled to work on udp/10, by virtue of ip forward protocol 10)
  • R1 will rewrite this into a unicast packet with destination address 192.168.2.255 and will send out that unicast, according to its routing table. The packet now has Src 192.168.1.10 and Dst 192.168.2.255. R1 has no knowlegde (and doesn't need it) if 192.168.2.255 happens to be a broadcast address in that remote subnet "somewhere else"
  • R2 will receive this packet on its R1 facing interface (still with Src 192.168.1.10 and Dst 192.168.2.255)
  • R2, by looking up the routing table (well, maybe CEF table) will decide that this packet needs to be forwarded out through interface vlan 200.
  • R2 will detect that the destination address is the given subnet's broadcast address, will check for the presence of ip directed broadcast [ACLofAllowedSourceIPs] and check if 192.168.1.10 is in that ACL
  • If checks succeed, R2 will rewrite the packet's destination IP address to 255.255.255.255 (and Dst MAC to ff:ff:ff:ff) and send out that packet/frame through its interface vlan200. And there you are.
Improve this answer
  • Thanks for your answer but that's what I've already know :) Main point is that what you have bolded - R1 will rewrite this into a unicast packet with destination address 192.168.2.255 and will send out that unicast - and this is what I don't exactly understand... How am I suppose let's say in wireshark to determine that THIS packet is unicast not broadcast? What is the difference? Because it's still addressed to broadcast address... – szkolek Apr 17 '19 at 5:26
  • Well, that's what ip helper-address does. It picks up an incoming broadcast (of certain types), rewrites the destination address to the configured helper-address, and forwards the packet according to the current state of its routing table. At this point, R1 has no idea that "somewhere else in the network", this unicast helper address might happen to be the broadcast address in the destination network (and it does not need to know - it's a unicast packet like any other). Only the last hop router (R2, in your case) can know if that address is actually a broadcast address. – Marc 'netztier' Luethi Apr 17 '19 at 6:19
  • If you looked at the packet on an intermediate link between R1 and R2, even at the ingress interface of R2, you'd see SrcIP 192.168.1.10, DstIP 192.168.2.255, and unicast Src/Dst MACs to match the given underlying L2/DataLink (might be PPP, HDLC, Ethernet, TokenRing...). At this point, you can not know that this packet is supposed to become a broadcast beyond R2, nor that it had been a broadcast at R1. – Marc 'netztier' Luethi Apr 17 '19 at 6:22
  • So if I use ip helper-address command with broadcast addres let's say 192.168.2.255 how routers know that it should be forwarded not discarded as normal broadcast packet? Let's create a small modification and insert between R1-R2 another router R1-R3-R2. To make it works we do not need to configure anything on R3, how that routers knows that it should forward that packet and not discard it? And to make it clear - PC1 when sends broadcast packet it sends it also to directed mac address not to broadcast one. – szkolek Apr 17 '19 at 6:27
  • how routers know that it should be forwarded not discarded as normal broadcast packet? That's because none of the routers along the path (except R2, eventually) have any clue that 192.168.2.255 is actually a broadcast address of a network. Eventually, only R2 can tell, because it is (in a well-addressed network) the only router that has the given subnet locally attached. To any other router, 192.168.2.255 is just "a destination address" - they don't know. They cannot even know if the L2 medium "somewhere over there" is even broadcast cabable. – Marc 'netztier' Luethi Apr 17 '19 at 6:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.