Re: tcp hostcache and ip fastforward for review
I agree in that flow cache is bad and it should not be used. It only takes x num. of kpps with diverse destinations to knock off a router running flow based caching. Extreme switches use flow based caching (called ipfdb) and any DoS attack that uses diverse destinations will kill it pretty quickly.. -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN On Wed, Nov 12, 2003 at 11:36:27AM +0100, Andre Oppermann wrote: > popsong old wrote: > > > > --- Andre Oppermann <[EMAIL PROTECTED]> wrote: > > > > BTW, we'll get even better performance if we keep both > > > > interfaces' MAC addresses in cache (and call > > > > ifp->if_start directly). This requires to keep > > > > ethernet header in mbuf untouched and is only relevant > > > > in ethernet though. I implemented such layer 2 cache > > > > in a local version of IPFilter and got some good > > > > results. > > > > > > I don't understand why you want to do that unless you > > > are doing bridging. We have to look up the mac address > > > of the next hop anyway. If that is not already in the > > > routing table it needs to do a arp lookup. > > > > > > -- > > > Andre > > > > Ah, my fault. I didn't read your patch carefully and assumed that ip > > fastforward do flow caching as ip_flow does. However, I think ip flow > > caching is a good thing and maybe implementing it in ip fastforward is > > a good idea. > > Please explain why flowcaching is good. Cisco did away with it > quite some time ago because it didn't scale at all. Plus it is > very complex in the context of the BSD network stack. > > For IP fastforward we look at one thing, that is the destination IP > address. In a flow cache we need look at the destination IP address > and the destination host. Then we have to make a hash based cache > of size n. Problem number one: Is it really faster to look into the > hash table than the routing table? Problem number two: Is there any > caching effect at all in the hash table? Answer number one: No, it > is not faster on today's hardware. And if we don't find it in the > hash table we have to do the routing table lookup anyway. Answer > number two: Unless you have only a couple of flows the hit rate is > very low. If you have a couple of flows only then the routing table > stays in L1/2 cache of the CPU anyway as does the routing table. No > gain there. With too many flows you simply start thrashing the hash > table for no benefit. > > -- > Andre > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp hostcache and ip fastforward for review
> Everything is not black or white. > > A flow cache can accelerate for example Access Control Lists > and/or firewalling, since only the first packet needs to be > verified. That is true , yea. But also note that ACLs in provider environment are often used during times of diverse DoS attacks which flow-based routing systems can faint easily.. :-( [ ... snip ... ] > > Cisco's newer stuff does the flow-cache independent of the forwarding, i.e. > the > flow is more of an accounting cache. Yup, and we use it extensively at the border (Netflow) to do accounting and traffic statistics as well. But still, Cisco relies on use of CEF to actually route, I believe Netflow is used for accounting purposes now (although back in the old days, netflow used to be the acceleration mechanism, but CEF took over the routing part..).<--But, I may be wrong here :) Where as at the same time, many "layer-3 switches" vendors (the E vendor, the F vendor, tsk tsk) completely rely on use of flow based for actual _routing_ of the packet while marketing their stuff "OMG 16GBPS BACKBPLANE". Well, 16Gbps is good and all during well behaved traffic, but good luck handling a diverse DoS :( I've had an E-vendor switch that went haywire during 56kpps diverse-destination DDoS a while back.. Regards, -hc -- Haesu C. TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | POC: HAESU-ARIN > > --Anders, not affiliated with Cisco > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Sourcing ICMP reply to a different ip address
Hi, Is there anyway to source the ICMP reply (i.e. ttl-exceeded for traceroute) on a FreeBSD box acting as router to an IP address different than the one bound on the interface, in which the destination route is pointed at? For example: Let say we have an asymmetric routing situation here... A client host is 1.2.3.4, and the FreeBSD box has fxp0 with 2.2.2.2, and fxp1 with 3.3.3.3, Client runs traceroute to a host routed by the FreeBSD router. The packet arrives on FreeBSD router's FXP0 interface. But the route for 1.2.3.4 (client) on router's routing table points out to FXP1. Here in this case, the icmp ttl-exceeded message from the FreeBSD router will be sourced from 3.3.3.3, which is the main ip address of FXP1 (hence, the interface where route for 1.2.3.4(the client) is bound to) I'm looking to make it so that if a packet arrives on FXP0, I'd like the FreeBSD box to respond icmp ttl-exceeded OUT via FXP0, with source address of FXP0's IP. So in other words, I'd like to have icmp replies go out via the interface the packet originally hit the box, instead of via the interface that holds the route for the source of the packet. This type of implementation is done on some vendors (including Cisco) and sometimes can be helpful troubleshooting asym. routing situations.. Any suggestions would be appreciated. Thanks ` -- James Jun (formerly Haesu) Network Operations TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sourcing ICMP reply to a different ip address
For those who's a little confused in my email below sent before, here is a similar post that describes what I mean (hopefully): http://www.monkey.org/openbsd/archive/misc/9903/msg00109.html Thanks in advance! -hc On Mon, Dec 08, 2003 at 01:53:20PM -0500, [EMAIL PROTECTED] wrote: > Hi, > > Is there anyway to source the ICMP reply (i.e. ttl-exceeded for traceroute) on > a FreeBSD box acting as router to an IP address different than the one bound on > the interface, in which the destination route is pointed at? > > For example: > > Let say we have an asymmetric routing situation here... > > A client host is 1.2.3.4, and the FreeBSD box has fxp0 with 2.2.2.2, and fxp1 > with 3.3.3.3, > > Client runs traceroute to a host routed by the FreeBSD router. The packet > arrives on FreeBSD router's FXP0 interface. But the route for 1.2.3.4 (client) > on router's routing table points out to FXP1. > > Here in this case, the icmp ttl-exceeded message from the FreeBSD router will > be sourced from 3.3.3.3, which is the main ip address of FXP1 (hence, the > interface where route for 1.2.3.4(the client) is bound to) > > I'm looking to make it so that if a packet arrives on FXP0, I'd like the FreeBSD > box to respond icmp ttl-exceeded OUT via FXP0, with source address of FXP0's IP. > So in other words, I'd like to have icmp replies go out via the interface the > packet originally hit the box, instead of via the interface that holds the > route for the source of the packet. This type of implementation is done on > some vendors (including Cisco) and sometimes can be helpful troubleshooting > asym. routing situations.. > > Any suggestions would be appreciated. Thanks > ` > -- > James Jun (formerly Haesu) > Network Operations > TowardEX Technologies, Inc. > Consulting, colocation, web hosting, network design and implementation > http://www.towardex.com | [EMAIL PROTECTED] > Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 > Fax: (978)263-0033 | AIM: GigabitEthernet0 > NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- James Jun (formerly Haesu) Network Operations TowardEX Technologies, Inc. Consulting, colocation, web hosting, network design and implementation http://www.towardex.com | [EMAIL PROTECTED] Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Windows 2000 <-> FreeBSD IPsec problem
Hi,
I am trying to setup an IPSEC transport between a Windows 2000 box
and a FreeBSD server for a customer... Both systems are on live
public IP's and packets are not filtered by any intermediate systems
or firewalls/routers in between.
I have the following setup:
Windows 2000 box: 1.1.1.2
FreeBSD Server: 2.2.2.3
(The actual IP's have been changed to above to protect the innocent..)
I have racoon setup on the FreeBSD server with following configuration[1]
And I have Windows configured correctly (verified many times after Googling
and looking at various howto docs...) as well. I will provide more info about
how its setup on Windows if anyone wants specific detail. But basically its set
using the howto from http://asherah.dyndns.org/~josh/ipsec-howto.txt
But when I try to have Windows box ping 2.2.2.3 (going over ipsec that is),
I get the following error in the freebsd server running racoon[2].
If anyone can assist with this, I would really appreciate it. I've been scratching
my head for a day trying to figure out what's going on.. Thanks!
-J
!< [1] Racoon Configuration below ->
path include "/usr/local/etc/racoon" ;
path pre_shared_key "/usr/local/etc/racoon/psk.txt" ;
# "log" specifies logging level. It is followed by either "notify", "debug"
# or "debug2".
#log debug;
# "padding" defines some parameter of padding. You should not touch these.
padding
{
maximum_length 20; # maximum padding length.
randomize off; # enable randomize length.
strict_check off; # enable strict check.
exclusive_tail off; # extract last one octet.
}
# if no listen directive is specified, racoon will listen to all
# available interface addresses.
listen
{
isakmp 1.1.1.2 [500];
}
# Specification of default various timer.
timer
{
# These value can be changed per remote node.
counter 5; # maximum trying count to send.
interval 20 sec;# maximum interval to resend.
persend 1; # the number of packets per a send.
# timer for waiting to complete each phase.
phase1 15 sec;
phase2 30 sec;
}
remote anonymous
{
#exchange_mode aggressive,main;
doi ipsec_doi;
exchange_mode main,aggressive;
nonce_size 32;
situation identity_only;
lifetime time 1 min;# sec,min,hour
initial_contact on;
support_mip6 on;
passive on;
proposal_check claim; # obey, strict or claim
proposal {
encryption_algorithm 3des;
hash_algorithm md5;
authentication_method pre_shared_key ;
dh_group 2 ;
}
}
sainfo anonymous
{
pfs_group 1;
lifetime time 36000 sec;
encryption_algorithm 3des,des,cast128,blowfish ;
authentication_algorithm hmac_sha1,hmac_md5;
compression_algorithm deflate ;
}
!<--- End of [1]--->
!< [2] Racoon Debug/Error msgs below ->
# racoon -v -F -f /usr/local/etc/racoon/racoon.conf
Foreground mode.
2004-01-08 15:26:03: INFO: main.c:172:main(): @(#)package version freebsd-20030826a
2004-01-08 15:26:03: INFO: main.c:174:main(): @(#)internal version 20001216 [EMAIL
PROTECTED]
2004-01-08 15:26:03: INFO: main.c:175:main(): @(#)This product linked OpenSSL 0.9.7c
30 Sep 2003 (http://www.openssl.org/)
2004-01-08 15:26:03: WARNING: cftoken.l:514:yywarn(): racoon.conf:49: "support_mip6"
it is obsoleted. use "support_proxy".
2004-01-08 15:26:03: INFO: isakmp.c:1358:isakmp_open(): 1.1.1.2[500] used as isakmp
port (fd=5)
2004-01-08 15:26:17: INFO: isakmp.c:894:isakmp_ph1begin_r(): respond new phase 1
negotiation: 1.1.1.2[500]<=>2.2.2.3[500]
2004-01-08 15:26:17: INFO: isakmp.c:899:isakmp_ph1begin_r(): begin Identity Protection
mode.
2004-01-08 15:26:17: INFO: vendorid.c:128:check_vendorid(): received Vendor ID: MS NT5
ISAKMPOAKLEY
2004-01-08 15:26:17: ERROR: ipsec_doi.c:1318:get_transform(): Only a single transform
payload is allowed during phase 1 processing.
2004-01-08 15:26:18: NOTIFY: isakmp.c:255:isakmp_handler(): the packet is
retransmitted by 2.2.2.3[500].
2004-01-08 15:26:20: NOTIFY: isakmp.c:255:isakmp_handler(): the packet is
retransmitted by 2.2.2.3[500].
2004-01-08 15:26:24: NOTIFY: isakmp.c:255:isakmp_handler(): the packet is
retransmitted by 2.2.2.3[500].
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
