Date: Fri, 28 Jan 2000 15:50:01 +0100 From: Roelof Osinga <roelof@nisser.com> To: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> Cc: Kuzak <kuzak@kuzak.net>, freebsd-stable@FreeBSD.ORG Subject: Re: Odd DoS Message-ID: <3891AC99.CC9F8D3@nisser.com> References: <200001281411.GAA81282@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
"Rodney W. Grimes" wrote: > > > ifconfig_ep1="inet 212.187.0.39 netmask 255.255.248.0" > ^^^^^^ > Are you really supernetted here? This could be a major part of > your problem. Don't you mean ``255.255.255.248''? You had me going there for a second <g>. Though I'd written 5 bytes. Alas, nothing so simple. That netmask is as it should be. Besides, it is a totally different route, the messages have to do with the other subnet. > > #ifconfig_ep1_alias0="inet 194.134.130.170 194.134.128.1 netmask > > 255.255.252.0" > > The above won't even parse correctly by ifconfig, 2 ip's???? and > again, is this network SUPERNETTED? Or is the netmask suppose to > actually be 255.255.255.252? Not only parses it just fine, it is also as documented. As to being supernetted, talk to the ISP's in question. Defining their network is their responsability. These are both CATV networks. Mind you, if you can provide an URL that explains 'being supernetted' it will be appreciated. For as per RFC 1519 This plan is primarily directed at the first two problems listed above. We believe that the judicious use of variable-length subnetting techniques should help defer the onset of the last problem problem, the exhaustion of the 32-bit address space. Note also that improved tools for performing address allocation in a "supernetted" and variably-subnetted world would greatly help the user community in accepting these sometimes confusing techniques. Efforts to create some simple tools for this purpose should be encouraged by the Internet community. I'm confused <g>. If it's to be interpreted as the (virtual) sum of all the individual subnets, then yep, I'm supernetted. Twice <g>. Can't see why you're so surprised. Surely it's a good thing compared to octet, class based, route exploding manner? RFC 1519 seems to think so. > And you'll probably get even less if your really have an off by <<8 > in your netmask and you fix it... Alas. But do see the archives. What happens is that the ARP daemon can not handle the case where one MAC is coupled to two distinct IP adressess, i.e. gateways. You're looking for complexity where simplicity is all there is. One GW is 212.187.0.39, the other 194.134.128.1. They're on different nets. They don't have the same MAC address. arplookup 194.134.128.1 failed: host is not on local network is bogus. For 194.134.128.1 *is* on the local network, local to the 194.134.130.170/duh network in fact. It just isn't local to the 212.187/21 network. > What does your routing table look like??? Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 212.187.0.1 UGSc 66 4014481 ep1 10/24 link#1 UC 0 0 ep0 10.0.0.1 link#1 UHLW 1 1556 ep0 10.0.0.2 0:0:e8:ee:c8:fb UHLW 20 932933 ep0 1016 10.0.0.3 0:40:95:4:37:2a UHLW 2 1007505 ep0 1061 10.0.0.4 0:4f:49:0:8a:ba UHLW 1 596948 ep0 1156 10.0.0.55 0:60:97:14:31:a7 UHLW 0 474 lo0 10.0.0.255 ff:ff:ff:ff:ff:ff UHLWb 3 16681 ep0 127.0.0.1 127.0.0.1 UH 3 278986 lo0 194.134.130.170 0:60:97:e4:98:db UHLW 0 67 lo0 => 194.134.130.170/32 link#2 UC 0 0 ep1 212.187/21 link#2 UC 0 0 ep1 212.187.0.1 0:90:6d:e4:30:0 UHLW 65 68 ep1 946 212.187.0.37 link#2 UHLW 1 2330 ep1 212.187.0.39 0:60:97:e4:98:db UHLW 0 915 lo0 212.187.7.255 ff:ff:ff:ff:ff:ff UHLWb 0 62 ep1 Again, all this information and more - way more - is in the archives. We - other we <g> - have been over this again and again. And now again again. To no avail. > I do this all the time to route between 2 subnets on the same > physical ethernet on 1 physical interface on 1 box. It works > just fine, I don't get bottles of arplookup's unless I blow one > of the netmask some place or a -interface route. Ok, I've shown you mine now you show me yours. Yeah, have done that too <g>. However, these settings: inet 212.187.0.39 netmask 255.255.248.0 defaultrouter=212.187.0.1 inet 194.134.130.170 netmask 255.255.252.0 defaultrouter=194.134.128.1 are at least as advertised. The latter I've worked with for some three years. I've also tested it as the only IF and not an ARP message in sight. Same holds for the former as only IF. The poblem only occurs when one of the is aliassed. Doesn't matter which one. In your case, have both subnets different gateways for their respective supernets? E.g. the EuroNet network has some servers that only be gotten at when coming from a 194.134/16 range. Though their INN supports the password option. Silly thing is that what I'm doing here is akin to what I was doing in '93 with the KA9Q NOS. With it it did work. This is not to say I'm not doing anything wrong this time, just that it can work. Roelof -- Dog's house @ http://cairni.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3891AC99.CC9F8D3>