IpTraffic encloded in EthBroadcasts should be routed

Routers do not normally pass broadcast packets.

What do you mean by "full correct IpTraffic?" IIRC, unicast IP is not supposed to be carried in a broadcast frame. Also, IIRC, IP routers are not supposed to forward IP datagrams carried in broadcast frames.

So, what sort of IP traffic do you have being carried in a broadcast frame?

rick jones

Hello,

its unicast IP. The Sender doenst know the gateway IP and also not the Gateway mac. Thats the reason why Its an broadcast. But its save that the connection between sender and Gateway is an P2P Connection.

But may be there is an Ethernet Broadcast frame which on triggers the Gateway to say something. Because if I recieve a frame from the gateway I know his MAC due to the P2P connection. Due you know some kind of ethernet broadcast which triggers a normal Router to send an answer?

Thanks a lot Immo

Rick Jones schrieb:

But can I change this behavior ? Espacially for Extreme Networks Summit L3Switches ?

Perhaps a better solution would be to find out why you're trying to do something that goes against common practice. What is it that you're trying to do, that requires a broadcast to go through a router. Incidentally, routers are configured to avoid passing broadcasts, to limit how far they'll travel, in order to avoid polluting the Internet with a lot of useless garbage.

In article , wrote: :its unicast IP. The Sender doenst know the gateway IP and also not the :Gateway mac. Thats the reason why Its an broadcast. But its save that :the connection between sender and Gateway is an P2P Connection.

You mean something like ICMP Router Discovery, RFC1256?

:But may be there is an Ethernet Broadcast frame which on triggers the :Gateway to say something. Because if I recieve a frame from the gateway :I know his MAC due to the P2P connection. Due you know some kind of :ethernet broadcast which triggers a normal Router to send an answer?

In another message in the thread, you mentioned a very specific kind of router and asked how it might be configured for forwarding. If you have that level of control, then you could configure the router to send out RIPv1 or RIPv2 packets announcing the default route. Hearing such a route would tell you where the router was.

:But may be there is an Ethernet Broadcast frame which on triggers the :Gateway to say something. Because if I recieve a frame from the gateway :I know his MAC due to the P2P connection. Due you know some kind of :ethernet broadcast which triggers a normal Router to send an answer?

Let's have another look at that. You are trying to find out the IP address of the "gateway" and you propose to do that by provoking the "router". But if one examines the context of your request, then the "gateway" is -not- the same as the "router".

If the P2P traffic knows the remote IP address, then all it has to do is unicast to that IP: all details about the path it takes to get there will be handled by the IP stack, and you don't need to worry about router MACs and so on... not unless you are programming the IP stack itself.

If the P2P traffic does -not- know the remote IP address, then it is not going to be able to get traffic to the remote endpoint by sending a unicast traffic to the router's IP + MAC: the router itself would end up processing the traffic, since the router would see it's own IP. "normal" routers would drop such traffic unless it happened to be management traffic (e.g., SNMP or ssh to the router), or NTP, or unless the router was configured for "small services" such as chargen.

Thus in the context of your messages, the "gateway" that you are trying to provoke must be a device that actively participates in the P2P transaction (even if only in "call setup".) If that active device is beyond a router, then learning the MAC of that active device wouldn't help you because you need the router's MAC to send to, not the active device's MAC.

If you have enough control over the context that you can specify switch models end to end, then there are three technologies that I suggest you investigate: multicast, DHCP, and bootp {DHCP is actually a kind of bootp, but your research will be easier if you treat them as nearly two different protocols.)

What about configuring the router for proxy arp? Then add a host route on the client that tells it that the other side of the P2P connection is local, i.e. give it a zero metric and specify the gateway as the local IP address. That should force it to arp the remote IP which the router can then answer.

It is my impression (And I may be wrong...) That the normal behavior for IP traffic is to use ARP on a broadcast when the local stack does not know the MAC for the IP Address. The Router should respond with his MAC as an answer to Route the packets. From there, the end station knows to forward the packet using the Routers MAC.

I think that doing Unicast IP inside of an Ethernet Bcast is bad ...

What you describe here is not an unusual state of affirs. Unicast has to go out to another IP subnet. Sender doesn't know the IP address of the router, which means also doesn't know the MAC address.

One solution is for the sending host to monitor for RIP frames, to find the router that way. Another is to use ICMP router discovery (RFC

Once the sending host has the IP address of the router, it proceeds with ARP to find the MAC address, and sends the frame to that MAC address.

Routers rarely forward frames with broadcast addresses. One of the few times is when doing BOOTP or DHCP to a remote DHCP server (a server that isn't co-located with the router).

Bert

Your right. But for a arp you have to know the IP Address of the router.

In article , wrote: :Your right. But for a arp you have to know the IP Address of the :router.

Not if the router is doing proxy-arp, which is the case for most routers that are handling a default route.