On 2006/10/12 14:39, Girish Venkatachalam wrote:
> On Thu, Oct 12, 2006 at 01:41:49AM +0100, Stuart Henderson wrote:
> > On 2006/10/12 01:15, ropers wrote:
> > > Neither do I understand what really goes on during IP forwarding as
> > > opposed to bridging
> >
> > with forwarding(routing) tcp/ip packets have a destination IP address
> > which isn't bound to an interface on the router but the MAC address _is_
> > the address of the routers (destination address is not ARP'd for because
> > the previous router knows it's not a directly-connected destination).
> >
> > with bridging, the MAC address is of the final destination, and is
> > learned by the previous router by ARPing for it (ethernet broadcasts
> > cross the bridge unaltered).
> >
> > see "tcpdump -e"
>
> I read and reread the previous paragraph but I am not able to
> understand it.
>
> Let me try to express my understanding. Please point out
the holes in that( I am sure there are many).
>
> I am especially confused since you have mentioned
"forwarding(routing)".
> Routing protocols have two phases or components called
> building the routing table and actual forwarding of IP packets. It
> is the building of routing tables that happen over TCP(BGP),UDP(RIP)
> or IP(OSPF). This happens independently or real packet forwarding
> which is the primary job of a router.
Ignore dynamic routing protocols for now, they don't help you to
learn the basics and most networks get along fine without them.
You don't need to run a dynamic routing protocol to route packets
between directly-connected networks, it happens automatically when
you turn on net.inet.ip.forwarding. Let's create a few directly
connected networks: (I could of course have used physical nics)
# ifconfig vlan100 create
# ifconfig vlan101 create
# ifconfig vlan100 vlan 100 vlandev em0
# ifconfig vlan101 vlan 101 vlandev em0
# ifconfig vlan100 172.16.100.0 netmask 255.255.255.0
# ifconfig vlan101 172.16.101.0 netmask 255.255.255.0
# ifconfig vlan
vlan100: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:0a:e4:2d:99:ee
vlan: 100 priority: 0 parent interface: em0
groups: vlan
inet6 fe80::20a:e4ff:fe2d:99ee%vlan100 prefixlen 64 scopeid 0x8
inet 172.16.100.0 netmask 0xffffff00 broadcast 172.16.100.255
vlan101: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:0a:e4:2d:99:ee
vlan: 101 priority: 0 parent interface: em0
groups: vlan
inet6 fe80::20a:e4ff:fe2d:99ee%vlan101 prefixlen 64 scopeid 0x9
inet 172.16.101.0 netmask 0xffffff00 broadcast 172.16.101.255
# netstat -rnfinet
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Interface
default 85.158.44.145 UGS 5 427136 - ath0
85.158.44.144/28 link#2 UC 4 0 - ath0
85.158.44.145 00:00:24:c2:e1:f8 UHLc 2 14390 - ath0
85.158.44.146 00:0e:9b:93:23:e4 UHLc 0 2 - lo0
127/8 127.0.0.1 UGRS 0 0 33224 lo0
127.0.0.1 127.0.0.1 UH 7 144072 33224 lo0
172.16.100/24 link#8 UC 0 0 - vlan100
172.16.101/24 link#9 UC 0 0 - vlan101
224/4 127.0.0.1 URS 0 0 33224 lo0
Any packets arriving on vlan100 with a destination address of 172.16.101.xx
first get ARP'd for, then assuming a suitable MAC address was found they get
passed on.
> Now, once an IP packet arrives thro' an interface of a router,
> its destination IP address is looked up in the routing table, its TTL
> value checked and decremented, its IP checksum recomputed since we
> modified the TTL, and then finally(and most importantly), the
> destination MAC address of the packet modified to match the longest
> prefix match of the routing table lookup.
>
> Thus, if you see actually it is the destination MAC address
> stored in the ethernet header that is actually modified at every hop
> of the router. The IP header is largely untouched.
Yes that's it. Then it's shoved out the relevant interface.
> Now, briding is actually the job of a layer 2 device like a
> switch/hub and mostly happens in hardware since it is a dumb function.
A bridge learns which addresses are on each side and only forwards
those frames across: a hub is not a bridge. A switch is a multi-port
bridge. (In the olden days a common setup might be to have two
buildings with hub-based networks <or more likely coax or 10base5>
with a bridge separating them so that local traffic stayed within
the building).
> What OpenBSD hopes to achieve thro' providing briding in
> software is to do that same job intelligently. The man page clearly
> says that. If you add pf to briding then voila!, you have a
> marvellous way to filter packets transparently without actually
> modifying the routing topology of the network.
Yes, though the setup can become more confusing when you're using
bridging than IP routing.
> > > or, for that matter, why I needed to enable
> > > net.inet.ip.forwarding=1 in /etc/sysctl.conf for the bridge to work.
just checked and you definitely don't need net.inet.ip.forwarding=1
to bridge. net.inet.ip.forwarding is for IP packets, not ethernet frames.
> You need to do the same if you are using IPsec as well.
You don't need forwarding=1 to run IPsec to the host itself either,
only if you forward packets between hosts.
