[PATCH] Re: Reading Stevens, playing routing games
On Fri, Mar 16, 2001 at 08:19:16PM +0200, Ruslan Ermilov wrote:
> Hi!
>
> First of all, I would like to commit the attached patch; it removes
> duplicate code. Please review.
>
This got already committed as part of another bugfix.
See ip_input.c, revision 1.164.
> Also, I found a nasty bug in IP routing. The new route added may not
> take immediate effect for routing decisions, because ip_forward() may
> use the cached route (rt_forwarding).
>
The attached patch fixes this.
> DEMO (only relevant routes are shown).
>
> Step 1. On a router, add a route to the network (192.168.1).
>
> : # route add -net 192.168.1 gateway
> : add net 192.168.1: gateway gateway
> :
> : # netstat -rn
> : Routing tables
> :
> : Internet:
> : DestinationGatewayFlags Refs Use Netif Expire
> : 192.168.1 gatewayUGSc00 rl0
>
> Step 2. From some other host for which this machine is the default router,
> run ``traceroute -m 2 -n 192.168.1.1''. Observe, on the router,
> that the reference count grown on the 192.168.1 route.
>
> : # netstat -rn
> : Routing tables
> :
> : Internet:
> : DestinationGatewayFlags Refs Use Netif Expire
> : 192.168.1 gatewayUGSc13 rl0
>
> Step 3. Add RTF_REJECT host route to the destination:
>
> : # route add 192.168.1.1 -iface lo0 -reject
> : add host 192.168.1.1: gateway lo0
> : # netstat -rn
> : Routing tables
> :
> : Internet:
> : DestinationGatewayFlags Refs Use Netif Expire
> : 192.168.1 gatewayUGSc13 rl0
> : 192.168.1.1lo0UHRS00 lo0
>
> Step 4. The fun begins. What you would expect if you run traceroute to
> 192.168.1.1 again? Obviously host route should take precedence
> over network route, and I expected ICMP Destination Unreachable.
> But... what's a hell? the new route did not take immediate effect,
> traceroute succeeded (192.168.1.1 still has zero refcound and use):
>
> : # netstat -rn
> : Routing tables
> :
> : Internet:
> : DestinationGatewayFlags Refs Use Netif Expire
> : 192.168.1 gatewayUGSc16 rl0
> : 192.168.1.1lo0UHRS00 lo0
>
> Step 5. The fun continues. From another host, run traceroute to another
> destination (to help router change rt_forward.ro_dst).
> traceroute -m 2 -n 192.168.1.2:
>
> : # netstat -rn
> : Routing tables
> :
> : Internet:
> : DestinationGatewayFlags Refs Use Netif Expire
> : 192.168.1 gatewayUGSc19 rl0
> : 192.168.1.1lo0UHRS00 lo0
>
> Step 6. Run traceroute again to 192.168.1.1. The fun ends.
>
>
> The solution I found so far is to unstaticize the ``rt_forward'', and
> invalidate the rt_forward.ro_rt in in_addroute() (in_rmx.c). Any better
> ideas?
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
Index: in_rmx.c
===
RCS file: /home/ncvs/src/sys/netinet/in_rmx.c,v
retrieving revision 1.38
diff -u -p -r1.38 in_rmx.c
--- in_rmx.c2001/03/15 14:52:12 1.38
+++ in_rmx.c2001/03/18 15:08:25
@@ -54,6 +54,7 @@
#include
#include
#include
+#include
extern int in_inithead __P((void **head, int off));
@@ -137,6 +138,16 @@ in_addroute(void *v_arg, void *n_arg, st
RTFREE(rt2);
}
}
+
+ /*
+* If the new route successfully added, and we are forwarding,
+* and there is a cached route, free it.
+*/
+ if (ret != NULL && ipforwarding && ipforward_rt.ro_rt) {
+ RTFREE(ipforward_rt.ro_rt);
+ ipforward_rt.ro_rt = 0;
+ }
+
return ret;
}
Index: ip_input.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v
retrieving revision 1.164
diff -u -p -r1.164 ip_input.c
--- ip_input.c 2001/03/18 13:04:07 1.164
+++ ip_input.c 2001/03/18 15:08:26
@@ -257,7 +257,7 @@ ip_init()
}
static struct sockaddr_in ipaddr = { sizeof(ipaddr), AF_INET };
-static struct route ipforward_rt;
+struct route ipforward_rt;
/*
* Ip input routine. Checksum and byte swap header. If fragmented
Index: ip_var.h
===
RCS file: /home/ncvs/src/sys/netinet/ip_var.h,v
retrieving revision 1.53
diff -u -p -r1.53 ip_var.h
--- ip_var.h2001/
Re: same interface Route Cache
Nick Rogness wrote: > > On Sat, 17 Mar 2001, Wes Peters wrote: > > > > > > > > > > > > > Packet 1 comes in through ISP #2 network. It comes into your > > > > internal network to machine 1. Machine 1 replies to the > > > > packet...but where does it go? It will exit through interface > > > > to ISP #1 because of the default gateway. It came in ISP #2 and > > > > left out ISP #1. There is your problem. > > > > > > There is no way to tell your packet to go back out to ISP #2. That is the > > > point I'm trying to get across. Unless your running a routing > > > daemon. But is that really practical with cable modems, dsl, etc?...I > > > don't think so. > > > > Why would the physical media have anything to do with routing protocols? > > Just TRY to ask your cable or DSL provider to do BGP or any > routing...it aint going to happen. Watch them laugh in your face. Oh, just about any of the DSL providers that sell "small business" services will provide at least RIPv1 routing info. They charge more, but then again you're getting more from them, so that makes sense. Cable Modems are toys, because they rely on cable tv operators for networking expertise, and as far as I've seen, they don't have any. I'm willing to be proven wrong here. > The point here is getting way out of hand. Of course a routing > daemon would work. That has been said by myself throughout this > thread. That's not the point. Sure you can run a routing > daemon...it won't do any good if it is not recieving any routes > from your upstreams because they won't peer with you because you > only pay $40 a month for the service. Not everyone can afford a > damn T1 to an ISP, get IP space and setup BGP. Those same people > most often look for a UNIX box of some sort to do what they want. > > Yes, there is a time and place for policy routing. Any Network > engineer that has been actually supporting large networks can tell > you why you would use it, and there ARE very good reason to do it. See comments about "network engineer" below. Unless you have a CS degree and experience working with routing protocols or at least a CCIE, calling yourself a network engineer is exactly analagous to the garbage collector calling himself a sanitation engineer. > The fact is, many FreeBSD machines are running this type of > setup. Wouldn't it be nice to say "yeh we can do > that"? No, it would be nice to say "yeah we can do that WELL." We know we can't, so why implement some half-assed non-solution. Now you can see why Linux has this and we don't; Linux is the domain of the half-assed non-solution. > Unfortunetly, that does not appear to be the case because > adding flexibility seems to cause problems in the traditional ways > of the BSD folk...which is understandable...because you would be > breaking the rules. I understand. It's not just a matter of breaking the rules; nothing about the little Linux route-table manipulator is breaking any rules of IP routing, they're just basing routing decisions on very questionable data. If you wanted to port their little hack to FreeBSD and put it in ports, I don't think anyone would stop you, but nobody wants to waste their time on such a hack when they could be adding useful, working features. > PS: > This is not a hack for me, Wes, I suggested it after working with > several people having this same problem. There is a workaround > that is pretty ugly so I was looking for a cleaner > solution...that's all! There is a cleaner solution, it's called BGP4. This is simply a case of "you get what you pay for." IP routing is a complex nightmare, and CIDR didn't make it any easier. Trying to implement routing with anything less than support for routing to CIDR blocks and understanding the importance of intermediate routers is doomed to failure; your route table will grow to encompass all available kernel memory. I am *far* more familiar than you can imagine with this situation; questions like this and the ugly hacks (read this as "policy routing") put in place to answer the resulting customer demands are one of the reasons I avoid the "enterprise networking" marketplace. This is yet another proof of the old saw "a little knowlege is a dangerous thing", and 99% of "network engineers" (and all other IT staff) are possesors of "a little knowlege." Very little knowlege, unfortunately. It struck me last night that if you want to load-balance between two ISPs, you could simply pick a bit in the address and use it to select one or the other. If you pick your bit appropriately -- I'd go for something in the second byte -- you might luck out and get a nearly 50/50 spread. That would be no less hackish and a lot easier to maintain. -- "Where am I, and wh
GRE tunnels
good day, does any information exist on how set up a GRE tunnel in freebsd 4.3-BETA? i have read the netgraph, ngctl, ng_pptpgre man pages and unfortunately i am unable make heads or tails on how to set one up. i have the 'other' end set up using linux iproute2. it works (at least i see via tcpdump the ping packets arrive at the freebsd gateway). i have allowed gre packet thusly: ipfw add xxx pass gre from any to any but i am not sure what to do next. i would be very grateful for any assistance! bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: GRE tunnels
bill writes: > does any information exist on how set up a GRE tunnel in freebsd 4.3-BETA? > > i have read the netgraph, ngctl, ng_pptpgre man pages and unfortunately i > am unable make heads or tails on how to set one up. > > i have the 'other' end set up using linux iproute2. it works (at least i > see via tcpdump the ping packets arrive at the freebsd gateway). > > i have allowed gre packet thusly: ipfw add xxx pass gre from any to any > > but i am not sure what to do next. > > i would be very grateful for any assistance! FreeBSD doesn't have built-in support for that kind of GRE tunnel. You'd have to write your own program to open a raw socket and read and write packets to tun(4) or somesuch. The ng_pptpgre(4) node is (as the name implies) designed for PPTP's type of GRE. It could be used for 'generic' tunnelling between two FreeBSD machines but this is probably incompatbile with the Linux system. -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: Can't install FreeBSD 4.1
[follow-up set to freebsd-questions, net/hackers bcc:'d] [please don't only reply to me alone] -On [20010317 17:30], petro ([EMAIL PROTECTED]) wrote: >I try to install FreeBSD 4.1 >when the proces of copying begin, (near 20% of /bin copied) >I receive such error > >panic: general protection fault >syncing disks .. 99.. 99 99 99 >automatic reboot in 15 seconds, press any key to abort. Have you tried 4.2-RELEASE yet? It might be that this particular fault has already been correct since. Have you checked the errata? Have you monitored the interactive debug screen on vty2? -- Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 The administration of justice is the firmest pillar of government... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Kernel panic with MPD PPTP
Hi, I have an ADSL line that uses PPPoE encapsulation. I've been trying to get a PPTP connection working with FreeBSD 4.2 release on the same box that connects to the ADSL. The process is as follows: 1) Bring up PPPoE connection, using either user-space PPP or MPD. This part works flawlessly using either method. 2) Bring up PPTP connection using MPD. The result is always the same: Kernel panic in the next 30 seconds. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x70 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01a7dd0 stack pointer = 0x10:0xc0388328 frame pointer = 0x10:0xc038834c code segment = base 0x0, limit 0xf, type 0x1b = dpl 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, iopl = 0 current process = idle interrupt mask = net tty bio cam trap number 12 panic: page fault Can anyone help? I would be willing to help with debugging this, but I'm not a kernel hacker, and I really don't know where to start. I have log files, etc, but I didn't want to post that much stuff here. Brent Voltz Integrated Technical Services www.itsco.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: same interface Route Cache
Wes Peters wrote: > > > It struck me last night that if you want to load-balance between two ISPs, > you could simply pick a bit in the address and use it to select one or the > other. If you pick your bit appropriately -- I'd go for something in the > second byte -- you might luck out and get a nearly 50/50 spread. That would > be no less hackish and a lot easier to maintain. exactly what I suggested before, but the return packets will all come back on a single interface, unless you pass all teh packets that are going out one of the interfaces through natd first. That in turn breaks incoming sessions that come in through the 'plain' interface but get outbound routed through natd. You need to have stateful rules in teh incoming firewall that remember that a session was incoming and keep it from being shifted to the natd. This CAn be done using NATDs stateful rules I think but I haven't done it. > > -- > "Where am I, and what am I doing in this handbasket?" > > Wes Peters Softweyr LLC > [EMAIL PROTECTED] http://softweyr.com/ > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: strange arp packets!!!
On Fri, 16 Mar 2001, Jeroen Ruigrok/Asmodai wrote: > -On [20010316 06:25], Mohana Krishna Penumetcha ([EMAIL PROTECTED]) wrote: > >16:41:25.623476 arp who-has 0.0.0.0 tell 10.0.36.130 > >16:41:30.639372 arp who-has 0.0.0.0 tell 10.0.36.130 > >16:41:40.649838 arp who-has 0.0.0.0 tell 10.0.36.130 > >16:41:45.631430 arp who-has 0.0.0.0 tell 10.0.36.130 > >16:41:50.640533 arp who-has 0.0.0.0 tell 10.0.36.130 > >16:42:00.651104 arp who-has 0.0.0.0 tell 10.0.36.130(--> pcs130) > > > >i am little confused what this means, since 0.0.0.0 means "this host"? > > Not necessarily, 0.0.0.0 can also mean default gateway, which is the > more common use nowadays. 0.0.0.0 for `this host' is an old use IIRC. > i should check the code to see under what conditions the 0.0.0.0 is used. > >or is it that, it is meant to update the arp entry corresponding to > >pcs130 on other hosts in the subnet? in this case, it can as well say > >"10.0.36.130" instead of "0.0.0.0". > > I am not sure right now, might be because my head's a little foggy. > > What does arp -a and netstat -rn look like on the FreeBSD box and on the > Linux box? i didn't capture all that data, but i think, it is not very difficult to reproduce the same dump, i will check out for what ip addr, these packets are generated. Thanks, mohan > > -- > Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org] > Documentation nutter/C-rated Coder BSD: Technical excellence at its best > D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 > All of us visionaires with a rope around our neck... > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: strange arp packets!!!
On Sunday, March 18, 2001, at 08:42 PM, Mohana Krishna Penumetcha wrote: > > On Fri, 16 Mar 2001, Jeroen Ruigrok/Asmodai wrote: > >> -On [20010316 06:25], Mohana Krishna Penumetcha ([EMAIL PROTECTED]) wrote: >>> 16:41:25.623476 arp who-has 0.0.0.0 tell 10.0.36.130 >>> 16:41:30.639372 arp who-has 0.0.0.0 tell 10.0.36.130 >>> 16:41:40.649838 arp who-has 0.0.0.0 tell 10.0.36.130 >>> 16:41:45.631430 arp who-has 0.0.0.0 tell 10.0.36.130 >>> 16:41:50.640533 arp who-has 0.0.0.0 tell 10.0.36.130 >>> 16:42:00.651104 arp who-has 0.0.0.0 tell 10.0.36.130(--> pcs130) >>> >>> i am little confused what this means, since 0.0.0.0 means "this host"? >> >> Not necessarily, 0.0.0.0 can also mean default gateway, which is the >> more common use nowadays. 0.0.0.0 for `this host' is an old use IIRC. >> > > i should check the code to see under what conditions the 0.0.0.0 is > used. > >>> or is it that, it is meant to update the arp entry corresponding to >>> pcs130 on other hosts in the subnet? in this case, it can as well say >>> "10.0.36.130" instead of "0.0.0.0". >> >> I am not sure right now, might be because my head's a little foggy. >> >> What does arp -a and netstat -rn look like on the FreeBSD box and on >> the >> Linux box? > > i didn't capture all that data, but i think, it is not very difficult > to > reproduce the same dump, i will check out for what ip addr, these > packets > are generated. The "default route" usage is internal-only; I think the only time that this address can trigger anything in the arp code is - assigning that address to an interface (which may inadvertently occur on something like "ifconfig IF up"). - sending or receiving a packet with that address in the IP header, which should only occur for BOOTP/DHCP client startup. Regards, Justin Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Director of Technology| If you're not confused, Nexsi Corp. | You're not paying attention 1959 Concourse Drive | San Jose, CA 95131 | *-*---* To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Beowulf ethernet channel bonding on FreeBSD
A FreeBSD port of this would be nice: http://www.beowulf.org/software/bonding.html Anyone working on a similar solution? Regards +-- Dan Larsson | Tel: +46 8 550 120 21 Tyfon Svenska AB | Fax: +46 8 550 120 02 GPG and PGP keys | finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Beowulf ethernet channel bonding on FreeBSD
Dan Larsson wrote: > > A FreeBSD port of this would be nice: > > http://www.beowulf.org/software/bonding.html > > Anyone working on a similar solution? there are two methods of doing this already. Bill Paul recently asked for testers for a module he wrote that implements a cisco bonding protocol, and you can use the netgraph one-to-many node to achieve similar ends if you have a very simple configuration. see man 4 ng_one2many > > Regards > +-- > Dan Larsson | Tel: +46 8 550 120 21 > Tyfon Svenska AB | Fax: +46 8 550 120 02 > GPG and PGP keys | finger [EMAIL PROTECTED] > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000-2001 ---> X_.---._/ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
