RE: Secondary IPs and broadcasts

From: Scott Vermillion (scott_ccie_list@it-ag.com)
Date: Thu Nov 15 2007 - 18:33:05 ART


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