cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
1297
Views
5
Helpful
11
Replies
Jared Oliver
Beginner

GRE tunnel - does it forward 255.255.255.255 UDP broadcasts?

Hi,

 

I have a GRE tunnel setup between two sites. An application is setup at each site that makes use of 255.255.255.255 UDP broadcasts to help make setup easier. 

 

Technically, these broadcast packets are not supposed to be forwarded through routers. However, I have been receiving conflicting information about this. 

 

Will these packets be blocked or forwarded by default? If these packets are forwarded, is there a way to block them? Should I look to block the ports these broadcasts are on anyway with some sort of ACL?

 

Thanks,

Phatduny

1 ACCEPTED SOLUTION

Accepted Solutions
Peter Paluch
Hall of Fame Cisco Employee

Hello,

The 255.255.255.255 address is called a limited broadcast address, and for a good purpose: A router receiving such a broadcast will never forward it anywhere, neither through a GRE tunnel nor through any other interface. There is a very simple reason for that: As opposed to network-specific broadcast addresses such as 192.168.1.255 for the 192.168.1.0/24 network, the 255.255.255.255 address has no specific, unique network prefix part, and therefore cannot be routed because it is not clear at all where it should be routed in the first place.

The conflicting information you may have come across could be rooted in the fact that the IP Helper feature configured with the ip helper-address actually operates on UDP broadcasts sent to 255.255.255.255. However, you would need to have the ip helper-address configured in order for the UDP broadcasts to be actually considered to be forwarded to the specified address, and even then, only selected UDP-based services are considered eligible to be forwarded - TFTP, DNS, Time, NetBIOS, ND, BOOTP or DHCP, TACACS, IEN-116 by default. See the following two URLs:

ip helper-address Command Reference:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp/command/iap-cr-book/iap-i1.html#wp1413119578

ip forward-protocol Command Reference:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp/command/iap-cr-book/iap-i1.html#wp1776761080

Please read both descriptions of these commands carefully and in their entirety.

Nonetheless, I do not believe that your application happens to use any of the ports handled by default by the IP Helper Address feature, so even if you have it configured, I do not believe that the broadcasts to 255.255.255.255 would be forwarded by it. And, as I explained before, broadcasts to 255.255.255.255 are never forwarded by routers alone.

Best regards,
Peter

View solution in original post

11 REPLIES 11
Peter Paluch
Hall of Fame Cisco Employee

Hello,

The 255.255.255.255 address is called a limited broadcast address, and for a good purpose: A router receiving such a broadcast will never forward it anywhere, neither through a GRE tunnel nor through any other interface. There is a very simple reason for that: As opposed to network-specific broadcast addresses such as 192.168.1.255 for the 192.168.1.0/24 network, the 255.255.255.255 address has no specific, unique network prefix part, and therefore cannot be routed because it is not clear at all where it should be routed in the first place.

The conflicting information you may have come across could be rooted in the fact that the IP Helper feature configured with the ip helper-address actually operates on UDP broadcasts sent to 255.255.255.255. However, you would need to have the ip helper-address configured in order for the UDP broadcasts to be actually considered to be forwarded to the specified address, and even then, only selected UDP-based services are considered eligible to be forwarded - TFTP, DNS, Time, NetBIOS, ND, BOOTP or DHCP, TACACS, IEN-116 by default. See the following two URLs:

ip helper-address Command Reference:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp/command/iap-cr-book/iap-i1.html#wp1413119578

ip forward-protocol Command Reference:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp/command/iap-cr-book/iap-i1.html#wp1776761080

Please read both descriptions of these commands carefully and in their entirety.

Nonetheless, I do not believe that your application happens to use any of the ports handled by default by the IP Helper Address feature, so even if you have it configured, I do not believe that the broadcasts to 255.255.255.255 would be forwarded by it. And, as I explained before, broadcasts to 255.255.255.255 are never forwarded by routers alone.

Best regards,
Peter

View solution in original post

Thanks Peter :) great explination!

The more you know

Joseph W. Doherty
Hall of Fame Expert

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Broadcasts are not, by default, forwarded between L3 networks.  A GRE tunnel provides a L3 interface demarcation, so it will, also by default, not forward your 255.255.255.255 broadcasts.

"Technically, these broadcast packets are not supposed to be forwarded through routers. However, I have been receiving conflicting information about this."

Well that statement isn't 100% true, which might be the cause of your conflicting information.

Often routers will support some form of L2 bridging.  They might support L2 tunnels.  Such routers will then forward 255.255.255.255 broadcasts because it's a continuation of the same L2 domain.  (Technically, it's not routing 255.255.255.255, because it's L2 forwarding, but it might take place on a "router".)

PS:

Peter mentions ip helper-address will forward 255.255.255.255 to a specific address, and he's correct.  However, I believe the specific address might be a directed network broadcast address.  If so, you would be able to forward a broadcast to another network (even one more than one hop away).  For example, 255.255.255.255 on 192.168.1.0/24 might be sent to 192.168.2.255/24.

Peter Paluch
Hall of Fame Cisco Employee

Hi Joseph,

Thanks for joining!

Often routers will support some form of L2 bridging.  They might support L2 tunnels.  Such routers will then forward 255.255.255.255 broadcasts because it's a continuation of the same L2 domain.

Yes, that is true. However, this feature would need to be explicitly configured - you cannot turn it on just by accident. A pure router would not forward packets to 255.255.255.255 anywhere. In addition, the bridge-group command does not seem to be supported on GRE tunnel interfaces so bridging disparate Ethernet segments across a GRE tunnel is most probably impossible.

Peter mentions ip helper-address will forward 255.255.255.255 to a specific address, and he's correct.  However, I believe the specific address might be a directed network broadcast address.

Yes. definitely, the destination in an ip helper-address command can indeed be a directed broadcast address of another subnet in which the servers are located. This would actually allow the limited broadcasts be forwarded as directed broadcasts further.

But I believe that the original poster would like to have the 255.255.255.255 broadcasts blocked in the first place, and to my best knowledge, that is what the routers will do implicitly.

Best regards,
Peter

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Peter, from your reply to my posting, we don't disagree, but I wonder if what I posted wasn't clear to you or others; just in case in wasn't . . .

"However, this feature would need to be explicitly configured - you cannot turn it on just by accident."

When I wrote "Broadcasts are not, by default, forwarded between L3 networks.  A GRE tunnel provides a L3 interface demarcation, so it will, also by default, not forward your 255.255.255.255 broadcasts.",  "not, by default, forwarded" was intended to convey, what you wrote "would need to be explicitly configured".  So, I think we're saying the same thing, but in two different ways.

You also wrote "A pure router would not forward packets to 255.255.255.255 anywhere."  I agree.  You also wrote "... bridging disparate Ethernet segments across a GRE tunnel is most probably impossible."  Again, I agree.  But when you wrote "But I believe that the original poster would like to have the 255.255.255.255 broadcasts blocked in the first place, . . ." that's true (and you addressed it in your usual excellent manner) but the OP also wrote "Technically, these broadcast packets are not supposed to be forwarded through routers. However, I have been receiving conflicting information about this."  It's the second sentence, the conflicting information, I was addressing.  I.e. I believe, we both agree you cannot forward the 255.255.255.255 at L3, but we also both agree, you can forward the 255.255.255.255 as a directed broadcast.  The latter will, I further believe, behave much as a 255.255.255.255 on the destination subnet.  That I think can be a point of conflicting information, and it was that point I was attempting to clarify.  I.e. you can "sort of" forward a 255.255.255.255 on a pure router, but not as a 255.255.255.255, and it isn't done by default (i.e. it will require explicit configuration).

Hopefully, the foregoing helps the OP too, as also hopefully does your response to my posting.

 

Peter Paluch
Hall of Fame Cisco Employee

Joseph,

No problem, and don't worry - I wasn't trying to correct you in any way :) The difference between my and your understanding of the original poster's question is, I believe, in the fact that I have understood the original question as looking for a confirmation that the flooding of 255.255.255.255 across routers does not take place, while your answer seemed to gear more toward the ways to allow that flooding to happen. So in my next response, I focused on re-insuring that by default, limited broadcasts will remain limited.

I hope I have not offended you in any way.

Best regards,
Peter

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

''I wasn't trying to correct you in any way"

Peter, if I'm providing inaccurate information, anyone is welcome to correct, especially you!

"The difference between my and your understanding of the original poster's question is, I believe, in the fact that I have understood the original question as looking for a confirmation that the flooding of 255.255.255.255 across routers does not take place, while your answer seemed to gear more toward the ways to allow that flooding to happen."

I think, we both understand the OP's primary question.  You, again, answered that so well (as also again, you usually do), nothing I could add to that.

However, the OP mentioned getting conflicting information.  Conflicting information could be due to receiving inaccurate information, or it might be due to information received based on a slightly different variation of the question.  For example, when OP wrote: "Will these packets be blocked or forwarded by default?" the simple answer is "they will be blocked by default".

The OP also wrote "Technically, these broadcast packets are not supposed to be forwarded through routers. However, I have been receiving conflicting information about this."

There's no question there, but the first statement is inaccurate unless you clarify conditions, i.e. "it depends".  "By default" wasn't part of that statement, and we both agree a router can forward 255.255.255.255 broadcast packets.  For example if it's configured for bridging, or using a L2TPv3 tunnel, or using MPLS XCONNECT.  It can also "sort of" forward 255.255.255.255 if you consider conversion to a directed network broadcast.  With such possibilities, I wondered if such may have been the cause or source of some of the "conflicting information".

So, yes, you're correct when you write ". . .  your answer seemed to gear more toward the ways to allow that flooding to happen."

"I hope I have not offended you in any way."  Certainly not!!!

My only concern is whether I've only confused the OP, while trying to be helpful.

To recap what Peter, I believe, and I are saying:

"Will these packets be blocked or forwarded by default?"

They will, by default, be blocked.

"Technically, these broadcast packets are not supposed to be forwarded through routers."

Technically, 255.255.255.255 might be forwarded through routers, but not by default, i.e. they need to be configured to do so.

"If these packets are forwarded, is there a way to block them?"

As a special configuration is configured to allow them, blocking all of them would be just not providing the special configuration.

"Should I look to block the ports these broadcasts are on anyway with some sort of ACL?"

If there is a special configuration to forward broadcasts, but you only wanted to forward some broadcasts, then yes, I believe, ACLs might be used to further restrict what broadcasts are forwarded.  However, there may be other methods to control what broadcasts are forwarded.  Peter's original post's information on IP helper-address and IP forward-protocol are such an example, although they also converted 255.255.255.255 to non-255.255.255.255 IP addresses.

Peter / Joseph

Don't know about the OP but now I'm getting confused :-)

Definitely not offended though :-)

Sorry Joe, just couldn't resist.

Jon

Just so you guys know, the conflicting information is from a guy with 25+ years experience who claims he's a networking expert. He said they definitely were forwarded and that threw me off. 

I've now tested it and have verified that these packets are not forwarded by default through a GRE tunnel.

Thanks guys :)

Well, Jon, it's understandable you would be confused.  After all, I'm using American English instead of the English English.  ;)
 

Joe

:-)

It's pretty easy to get me confused to be honest :-)

Just goes to show how good Peter is considering his native language isn't either version.

Jon