From: Sean C. (Upp_and_Upp@hotmail.com)
Date: Mon Nov 19 2007 - 16:37:08 ART
Scott M and Scott V - thanks for both of your responses. Validates with
what I was thinking.
Scott V - I appreciate your due diligence on this one. Don't worry about
reposting with new findings, I think everyone's reposted something different
once they've been on here long enough - we're all here to learn! I'm
wondering what action on a PC would make a local broadcast (10.1.1.255) be
sent. A particular program or something? Scott Morris caught me like a
deer in headlights with the RIP comment, I should have thought of that one.
Thanks again,
Sean C #17085
----- Original Message -----
From: "Scott Vermillion" <scott_ccie_list@it-ag.com>
To: "'Sean C'" <upp_and_upp@hotmail.com>; <ccielab@groupstudy.com>
Sent: Thursday, November 15, 2007 4:41 PM
Subject: RE: Secondary IPs and broadcasts
So in an effort to salvage this response into something of potential value,
what I learned here was:
1. If you ping the subnet broadcast address of an attached network from a
Cisco router CLI (such as 'ping 10.1.1.255' from a router R1 with fa0/0 in
the 10.1.1.0/24 network), the router actually sends it out on the wire as
all-ones/all-fs 255.255.255.255/ffff.ffff.ffff. If, for whatever reason,
you truly want the echo requests to go out as 10.1.1.255/ffff.ffff.ffff,
then you need to source from a Windows (or presumably OS X or Linux?) box
instead. Perhaps somebody knows a stupid router trick to force the router
to send it out this way, but from what I'm seeing the default is
all-one/all-fs.
1.1 A quick test indicates that Cisco switches likewise send to
all-ones/all-fs even when you've pinged the subnet broadcast address
instead.
2. If a switch forwards an all-fs frame to a Cisco router but the
destination is a L3 network in which the receiving router has no direct
participation, then you will not observe anything in even 'debug ip packet'.
In order to observe this traffic, you need to do something like turn on the
capture function in Dynagen and have a look via a protocol analyzer.
3. Don't post a response to the list that you yourself don't seem to fully
understand unless you don't terribly mind looking foolish.
Regards all,
Scott
-----Original Message-----
From: Scott Vermillion [mailto:scott_ccie_list@it-ag.com]
Sent: Thursday, November 15, 2007 5:09 PM
To: 'Sean C'; 'ccielab@groupstudy.com'
Subject: RE: Secondary IPs and broadcasts
Oh, well, um...
So I never bothered to look closely at the trace files of the traffic as it
was *leaving* the Vista box. Naturally, since I'm pinging an address
outside of my own subnet when trying to hit 10.1.1.255 from 10.1.2.1/24, I'm
simply ARPing for my default gateway and encapsulating the echo request to
10.1.1.255 directly to the gateway's L2 address. Hence I do see the reply
from SW1 but I never see the echo request arrive on R1 because it's not
being encapsulated as L2 broadcast. However, when I'm pinging 10.1.2.255
from 10.1.2.1/24, the Vista box is naturally encapsulating that directly
into all-fs L2 broadcast and thus the switch both replies from the SVI and
forwards out other ports in that VLAN.
That makes much more sense than some strange check of L3 source, LOL.
That's what I get for doing an IP Services CoD session and mucking around on
the side at the same time (I'm at day 10 and finding it very difficult to
stay focused -- no two-week bootcamps for me EVER!).
Regards,
Scott
-----Original Message-----
From: Scott Vermillion [mailto:scott_ccie_list@it-ag.com]
Sent: Thursday, November 15, 2007 2:33 PM
To: 'Sean C'; 'ccielab@groupstudy.com'
Subject: RE: Secondary IPs and broadcasts
Hey Sean,
Interesting questions and a few interesting lab results in response. I set
this up quickly using my IEWB topology. In that, both R1 and R3 connect to
SW1. I set up the VLAN 1 IPs exactly as you have below on SW1. My hosts
are R1 and R3, again with the below IPs. They each simply have their
default routes pointed out their fa0/0 connections to SW1 and furthermore to
the appropriate SW1 VLAN 1 IP for their own network. The 'debug ip packet'
results surprised me a little, so I used the capture function of Dynagen to
have a look for myself as to what was going on using WireShark.
Basically...
When R1 (IP = 10.1.1.1) pings 10.1.1.255, I see that on R3 as a ping from
10.1.1.1 -> 255.255.255.255 and R3 actually replies (as does SW1 from the
10.1.1.254 address). This is the debug output on R3:
IP: s=10.1.1.1 (FastEthernet0/0), d=255.255.255.255, len 100, rcvd 2
IP: s=10.1.2.1 (local), d=10.1.1.1 (FastEthernet0/0), len100, sending
The conversion from the 10.1.x.255 to 255.255.255.255 is confirmed in the
trace file. I initially suspected SW1 of doing this conversion but it is
the routers themselves (I guess this is a behavior I should have been aware
of but was not). When I look at a trace file from a router that I'm pinging
*from*, the packets are leaving the interface with the 255.255.255.255
destination address, even though on the CLI I'm pinging the subnet broadcast
addresses for the 10.1.1.0 and 10.1.2.0 networks.
When R1 pings 10.1.2.255, I see replies from SW1 but nothing appears in my
debug output on R3. Digging through my trace file supports this result.
The same happens in reverse with R3 pinging 10.1.1.255 or 10.1.2.255. Also,
either router pinging to 255.255.255.255 from the CLI obviously is seen on
the other router.
Now just to be cute, I put secondary addresses on R1 and R2 such that they
each had an IP in both subnets. Since the routers convert pings to subnet
broadcast addresses for networks in which they have an interface to an
all-ones broadcasts, I am obviously able to see the traffic from each router
to the other, regardless of what subnet broadcast I'm pinging.
Also of note but no real surprise is that SW1 never responds from its
secondary IP; all replies are always from the primary IP:
R3#ping 10.1.2.255
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.2.255, timeout is 2 seconds:
Reply to request 0 from 10.1.1.254, 24 ms
Reply to request 0 from 10.1.1.1, 36 ms
Reply to request 1 from 10.1.1.254, 12 ms
Reply to request 1 from 10.1.1.1, 12 ms
Reply to request 2 from 10.1.1.254, 16 ms
Reply to request 2 from 10.1.1.1, 20 ms
Reply to request 3 from 10.1.1.254, 4 ms
Reply to request 3 from 10.1.1.1, 8 ms
Reply to request 4 from 10.1.1.254, 16 ms
Reply to request 4 from 10.1.1.1, 16 ms
R3#
So out of curiosity, I replaced R3 with my own Vista box to see what would
happen. It turns out the Vista box will ping the broadcast address as
entered (validated via WireShark running on the box). If I ping 10.1.2.255,
I get a reply from SW1 @ 10.1.1.254 *only*. My 'debug ip packet' on R1
produces nil. If I try to ping 10.1.1.255, I get nothing unless I enter a
static route on the Vista box to the 10.1.1.0/24 network via 10.1.2.254.
Then, once again, I get a response from SW1 @ 10.1.1.254 only; my debug on
R1 remains silent. Now this is the interesting part...
If I ping 10.1.2.255 from Vista, I see that in my trace file captured from
R1 fa0/0 (R1 obviously doesn't reply but I see the echo requests showing
up). However, when I ping 10.1.1.255 from Vista, I see nothing in my trace
file on R1. So it seems there's some kind of anti-smurf behavior enabled by
default on the switch? It will still respond to pings to that address
itself, but doesn't seem to be pushing it out other ports.
So to distill this all down, it appears as though the switch will indeed
switch out traffic throughout the broadcast domain if destined for the
subnet broadcast address of either the primary or secondary subnet -- IF the
source address passes a sanity check. It will of course switch traffic to
255.255.255.255 throughout the broadcast domain. Also, I was able to see
multicast being sourced from my Vista box showing up over on R1.
Comments on the anti-smurf thing would be very welcome...
Regards,
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Sean
C
Sent: Thursday, November 15, 2007 10:35 AM
To: ccielab@groupstudy.com
Subject: Secondary IPs and broadcasts
Hi Group,
If I have a 3550 with Vlan 1:
int vlan 1
ip address 10.1.1.254 255.255.255.0
ip address 10.1.2.254 255.255.255.0 secondary
Interface f0/1 is in Vlan1 and has a host connected (host1) with IP 10.1.1.1
/24
Interface f0/2 is also in Vlan1 and has a host connected (host2) with IP
10.1.2.1 /24
If host1 sends a local broadcast (10.1.1.255), will host2 receive this since
both IP subnets are in the same layer 2 segment?
This leads me into other areas, like what if it's an IP broadcast
(255.255.255.255) or layer 2 broadcast (f.f.f) or if host2 is across a
couple
of 3550s, with each switch's SVI in both IP subnets. I'm thinking that
host2
will receive the frame (what host2 does with the frame is a different
story).
I'm just curious to see how the packets are switched.
I looked pretty hard on-line, but can't find a definitive answer. Here's
some
things I found for guidance (buyer beware):
http://www.groupstudy.com/archives/cisco/199912/msg00535.html
http://books.google.com/books?id=77h9SA94kasC&pg=PA53&lpg=PA53&dq=%22seconda
r
y+address%22+broadcast+interface&source=web&ots=ZK2MDq5iey&sig=niwz8-D79xoTW
M
Jt97wCCinJfcQ
http://tcpmag.com/forums/forum_posts.asp?tid=1383&pn=10
Even found a decent post from Howard Berkowitz (I miss his posts):
http://www.groupstudy.com/archives/cisco/200306/msg01434.html
I don't have immediate access to a LAN sniffer or I'd bang on this myself.
Curious to hear the group's thoughts. Thanks in advance,
Sean C. CCIE #17085
This archive was generated by hypermail 2.1.4 : Sat Dec 01 2007 - 06:37:30 ART