[c-nsp] Set a L3 routed interface on a 6500 + SUP2 to'promiscuous'mode?

Stig Johansen stig.johansen at ementor.no
Fri May 16 00:20:12 EDT 2008


Sorry, but this sounds like a "won't work".

Your server is depending on sending spoofed packets. If this was on a
local VLAN, you could simply put if2 in the same VLAN as the sniffer-if
and let it work from there. I see you mentioned the traffic is fed by
RSPAN, so I guess the traffic isn't local, and may even be from
different VLAN's. That's when it would be a problem.

Put your server in a central place where all traffic must pass and do it
from there, and if you have redundant paths you should also have
redundant servers.

Alternatively, you should look into building a "blackbox" to accept
these packets and forward into the network. The Cisco gear won't do this
for you.

That said, if you want to experiment further, look into using RSPAN to
send these packets out on the network again... This may mean you'll need
a third if for management, but it could be worth a try.

Best regards,
Stig Meireles Johansen

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Rafael Rodriguez
Sent: 16. mai 2008 04:57
To: david at davidcoulson.net; Ryan.Otis at webtrends.com; jmaimon at ttec.com;
dcp at dcptech.com; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Set a L3 routed interface on a 6500 + SUP2
to'promiscuous'mode?

Thanks for the replies.  Post below is a bit long but easy to read,
please let me know if you guys have any advice.

>What mac is it sending too? where does it get the arp entry from?

Unfortunately this server does not attempt to 'arp' for the remote
address, proxy-arp would be the solution in that case.

Let me give some more details on what this server does:

The server (just windows 2003 with software) is a content filter.  It
has two phy interfaces, one interface is the sniffer interface, the
other/regular interface is were you manage the server and were the
server sends its 'block' and tcp rst messages to end users.

The sniffer interface just listens for traffic, it does not TX on this
interface at all.
The sniffer interface is being fed by rspan.

The other/regular interface is were everything else happens.  On this
interface, any locally traffic generated by server works as one would
expect... Oh, im trying to get to a remote network, let me send packet
with dst mac address of my default gateway, let my default gateway
figure out the rest.  The part of locally generated traffic works
perfectly.

Now the problem.

When the content filter makes a decision of 'blocking' someones web/http
traffic based on traffic it sees on its sniifer interface, the server
sends a 'block' message out the other/regular interface.

The server sets the src IP of the packet to the 'bad' website and sets
the dst IP to that of the offending end user.  The server also sends a
tcp rst to offending end user.
ALL of that is perfectly fine.

Problem comes down to how the server sends the data-link address part.

Server is using the wrong dst MAC Address to send packets that reside on
remote subnets.  By wrong dst MAC Address I mean NOT the MAC Address of
the servers default gateway.
The server uses the src MAC Address of the 'offending' traffic from the
sniffer interface as the dst MAC Address of the 'block' message.  Why is
this a problem?  Well, dst MAC Address is not the MAC Address of the
default gateway router - packet just gets dropped in hardware, never
makes it up to L3 for processing.  The information contained in this
paragraph was confirmed/figured out with the help of wireshark.

I am looking for a way to have router interface process all data-link
packets regardless if the dst MAC Address is for the router interface.

Thanks for reading, please reply with any info.


Cheers,
 
RR


More information about the cisco-nsp mailing list