Connecting two LANs via VPN and Filtering
Thomas Gielfeldt [EMAIL PROTECTED] wrote on 26-10-02 20:22:15: Hi I have now finally bridged my two networks over the internet using vtun + netgraph. +--+ public ip | Cisco Router | --- +--+ 172.16.0.1/16 | | | +--+ |Switch| +--+ /\ / \ /\ / \ 172.16.1.1/16 +---++---+ 172.16.2.1/16 - | Gateway A || Gateway B | - 10.0.1.1/16 +---++---+ 10.0.2.1/16 || || || +--++--+ | Network A || Network B | | || | | || | | || | | +-++-+ || +-++-+ | | | Host A1 || Host A2 | || | Host B1 || Host B2 | | | +-++-+ || +-++-+ | | 10.0.1.2/16 10.0.1.3/16 || 10.0.2.2/16 10.0.2.3/16 | +--++--+ The VTun creates the interface tap0 and I use the ether.bridge script (found in /usr/share/examples/netgraph/) to bridge the tap0 interface and the LAN interface. However, mow I'm faced with a new problem. Each net has its own DHCP-server, which causes the problem that hosts on e.g. Network B receives an IP from the DHCP-server on Network A. This not actually a problem, but I would still like to make the separation if the IP-ranges to each Network. I was thinking of something like filtering the tap0 on IP level. Ipfilter cannot be used though, as it thinks it receives all data from the LAN interface due to the bridge. So you probably have to filter via netgraph? Could somebody please help me on how to solve this. Examples will be appreciated. Thanks in advance. Best Regards Thomas Gielfeldt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: ng_fec hash mechanism versus cisco etherchannel
It does not matter if you send using the other link as long as you send all packets for the same stream over the same link to avoid reordering. So yes, it does interoperate. Pete Don Bowman wrote: Examining the source code to ng_fec, in ng_fec_output(), it uses the IP address to form the hash to pick the port. This is the same behaviour that 802.3ad specifies, and yields good behaviour since: a: it works in routed environments as well as local area b: packets are not reordered within L4 sessions. However, cisco seems to imply they use a hash based on MAC: http://www.cisco.com/warp/public/cc/techno/media/lan/ether/channel/prodlit/f aste_an.htm for some devices (e.g. a cat5000). Others (e.g. cat7500, cat8500) use L3 as ng_fec does. Yet others use SA based distribution (e.g. the cat1900, 2820). Does the ng_fec interoperate with the L2 only devices of cisco? --don ([EMAIL PROTECTED] www.sandvine.com) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
RE: ng_fec hash mechanism versus cisco etherchannel
From: Petri Helenius [mailto:pete;he.iki.fi] It does not matter if you send using the other link as long as you send all packets for the same stream over the same link to avoid reordering. So yes, it does interoperate. can you end up with a link flap? e.g. the catalyst does SA learning to pick the port, so it sends it out port 1. We respond via port 2 since we use the SIP^DIP. The catalyst switches that through to the other end, which replies, and comes back via port 1. I guess this isn't tragic. --don ([EMAIL PROTECTED] www.sandvine.com) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: ng_fec hash mechanism versus cisco etherchannel
The forwarding table points to the channel, not a specific interface on the channel. This also allows adding and dropping links on the fly. Pete Don Bowman wrote: From: Petri Helenius [mailto:pete;he.iki.fi] It does not matter if you send using the other link as long as you send all packets for the same stream over the same link to avoid reordering. So yes, it does interoperate. can you end up with a link flap? e.g. the catalyst does SA learning to pick the port, so it sends it out port 1. We respond via port 2 since we use the SIP^DIP. The catalyst switches that through to the other end, which replies, and comes back via port 1. I guess this isn't tragic. --don ([EMAIL PROTECTED] www.sandvine.com) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
MPD + Win2K + broadcast
Hi I'm still tampering with VPN and I want to say thanks for the advice I've gotton from here and elsewhere. Now I'm trying to connect a Win2k client to my internal network through mpd + netgraph. This works fine. However, there's something I don't understand. The ip assigned to the client is on the same subnet as the LAN, but broadcast data is not sent through the tunnel? Proxy-Arp is enabled. I also would like to tunnel ipx through. can mpd do this? Thanks in advance Br, Thomas Gielfeldt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Problem in High Speed and Long Delay with FreeBSD
you might want to have a look at the sysctl variable
kern.ipc.sockbuf_waste_factor too.
Remember that memory is charged to socket buffers depending on how
many clusters are allocated, even if they are not fully used.
E.g. in your example you are probably doing 1KB writes each of
which consumes a 2KB cluster plus a 256byte mbuf, so no
matter what you will never manage to reach more than (roughly)
a window larger than kern.ipc.maxsockbuf/2.
The max raw amounf of memory allocated in a socket buffer is
typically
min( tcp_{send|recv}buf * kern.ipc.sockbuf_waste_factor,
kern.ipc.maxsockbuf)
and probably you are hitting the roof on the second one.
cheers
luigi
On Thu, Oct 31, 2002 at 01:56:01PM -0500, Fran Lawas-Grodek wrote:
Hello,
Hopefully someone might have some advice on our problem.
We are setting up a testbed consisting of FreeBSD 4.1 on the sender
and receiver machines. (This older version of FreeBSD is necessary
due to subsequent TCP development patches that are to be tested.)
The problem that we are seeing is that on a 100Mbps link with a
250millisecond delay, our overall throughput does not exceed 32Mbps.
We expect to see at least 60Mbps with the 250ms delay. Without a
delay, throughput is acceptable at 87Mbps. Tcptrace output shows no
retransmissions and no out-of-order packets under the delay.
With the delay, we are setting up a 3MByte sender and receiver socket
buffer size, but through the time sequence plot, we only see about 1MB
used of the buffer on the sender side. Additional tests were run with an
80ms delay and requesting a 1MB buffer, and yet it appears only are
allowed to use up to 500KB of the window. Raising the requested
socket buffer size shows no affect -- we keep running into some
invisible threshold that is much smaller than the requested socket
buffer size. A hacked version of the ttcp application prints out that
what we request in the -b buffer size via setsockopt, is what we get
(via getsockopt). Unfortunately, the xplots show that our transfers
reach a lower threshold (1MB instead of 3MB, 500KB instead of 1MB).
Testing commands used:
receiver ttcp -b 312500 -l 1024 -r -s
sender ttcp -b 312500 -l 1024 -n 10 -s -t receiverhost
The -b above is set to the value of the Bandwidth Delay Product
for a 100Mbps link and 250ms delay.
Per the Pittsburgh Supercomputing site, we have already increased the
maxsockbuf, nmbclusters, memory, tcp_sendspace, tcp_recvspace sysctl
values, but are still resulting in this low throughput.
The network cards that we are using are 3Com95-TX 100BaseT cards. The
machines with the FreeBSD installations are Pentium II 400Mhz with
Xeon chips, 400 Mb RAM each.
Using two other non-FreeBSD machines, we have verified that it is not
the intermediary network routers or delay emulator equipment, as the
non-FreeBSD machines give the expected throughput under delayed and
no delay conditions. (60+Mbps under 250ms delay)
Has anyone else any experiences in this type of testing?
Perhaps there might be something wrong with our network card driver?
Any other suggested network cards to try?
Does anyone know of a limit that needs to be tweaked in the TCP
stack or FreeBSD operating system that would allow us to actually
use more than this invisible socket buffer limit? One thought is
that there is some sort of calculated limit that won't allow us to
send more packets than our requested socket buffer will allow, but
not having any the kernel expertise, we are not sure where to look.
Thanks in advance for any suggestions,
Fran Lawas-Grodek
Cindy Tran
NASA Glenn Research Center
Cleveland OH USA
(ps: We have already consulted with Mark Allman at our lab, and he
is just as stumped. The feeling is that the cause of the problem
is buried somewhere in the kernel, not due to the network cards.)
--
Frances J. Lawas-Grodek |
NASA Glenn Research Center| phone: (216) 433-5052
21000 Brookpark Rd, MS 142-4 | fax : (216) 433-8000
Cleveland, Ohio 44135| email: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message
Re: Connecting two LANs via VPN and Filtering
Thomas Gielfeldt writes: So you probably have to filter via netgraph? This can be done with ng_bpf(4). -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: MPD + Win2K + broadcast
Thomas Gielfeldt writes: [reformatted to 80 columns] I'm still tampering with VPN and I want to say thanks for the advice I've gotton from here and elsewhere. Now I'm trying to connect a Win2k client to my internal network through mpd + netgraph. This works fine. However, there's something I don't understand. The ip assigned to the client is on the same subnet as the LAN, but broadcast data is not sent through the tunnel? Proxy-Arp is enabled. I also would like to tunnel ipx through. can mpd do this? No mpd does not do that. Might be a good idea for a sysctl.. e.g. net.inet.ip.fwd_bcast_tunnel to enable forwarding of broadcast packets across any point-to-point links whos local address lies on the broadcast subnet. If what you're really trying to solve is NBNS, use a WINS server. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
