Pat, Sorry about this very late response. Please see the post to Hal for a sort-of excuse.
OSPF depends on routing by consolidation of many routes into one route. This is done just like subnetting is done, namely by having an, in effect, partial address - although it's still 4 bytes long - and a mask. The mask is also 4 bytes long although I suspect, in practice if not in theory, the 1 bits are contiguous and so the mask could be represented as the number of contiguous 1 bits, for example, 24 for the ever popular 255.255.255.0. OSPF depends on consolidation when a destination needs to be advertised throughout a network of OSPF areas - although it may only be one Area 0 in practice. I imagine it is a typical situation that one needs those host routes only in the stub area. The Area border router will - as RFC 1583 has it - "distill" the routes within the stub area for the benefit of routing in Area 0. I'm not familiar with the sorts of statements that may be available to, say, a Cisco router. I would expect to have to define the subnet that the dynamic VIPAs (corresponding to the host routes) belong to in the Area border router so that only this subnet is advertised to Area 0 routers - keeping to the simple model of an Area 0 with attached stub areas. It's unreasonable to expect the router to try to work out how to consolidate on the basis of received routing information, especially host routes. Actually one can say that a host route is a subnet route where the subnet mask happens to be 32 1 bits. This is not so far away from a subnet of 30 contiguous 1 bits which is also unreasonable as a basis for consolidation, the subnet of 30 contiguous 1 bits being the smallest subnet it is possible to have where the subnet mask still contains 0 bits. I expect the router would be capable of comparing the received routing information with the routing information it has been asked to advertise and realising that the former is encompassed by the latter. I've a vague idea I read something like this in the RFC, that a route range is advertised only when an advertisement for some subset of the range is received - but I could be wrong. > In other words, I think the fixation was in OSPF, not in the specific OMPROUTE implementation. I blamed OMPROUTE because OSPF doesn't prohibit host routes; it's just uncomfortable with them in practice[1]. The fact that OMPROUTE has managed to come up with Advertise_VIPA_Routes=Host_Only shows that it was just a matter of throwing off blinkers. The excuse in the response from 4 years ago I sent to you was "They (OMPROUTE instances) have to broadcast subnet routes in case there are routers out there that do not recognize host routes." This seems to assume that routers are so very likely to be averse to host routes that users shouldn't even be allowed to think about not sending subnet routes. :-) [1] I say "in practice" because the theory of OSPF actually starts with point-to-point routes, "vectors". This is fully worked out before having to introduce complicated constructions such as "shared access transport facilities", for example, LANs. Does this have a familiar ring for you? Thanks for looking up the parameter. I'd imagined you knew about it already. Chris Mason ----- Original Message ----- From: "Patrick O'Keefe" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Friday, 24 February, 2006 11:11 PM Subject: Re: TCP/IP over Cisco router CIP > Chris, > > It probably looks like I have a seriously broken ALU if I say "4 years ago" > on list and "you were about 3 years ahead of me" in the off-list > email. Faulty memory is probabably more to blame, but I actually had 2 > introductions to this issue. The first was when I was first playing with > OSPF and was trying to duplicate as best I could the RIP filters I had in > place. I was (correctly) told that I could not do that; that all the > participants in an OSPF area really had to have identical (or at least > compatable) routing information, and filtering would prevent that. I > was also told (correctly) that OSPF depends heavily on routing by subarea. > > It wasn't until several years later, when getting heavily into application- > specific DVIPAs, that I ran into this perpetually looping routing issue. > > >... > >It may be that enough people pointed out that this fixation on subnet > routes > >was ridiculous and the dam gave way. > >... > > I got the impression that, for most situations, OSPF *does* depend heavily > on subnet routes, but DVIPAs do not fit well in that simple universe. An > "interface" that appears and disappears, that moves from host to host, > just wasn't considered in OSPF. In other words, I think the fixation was > in OSPF, not in the specific OMPROUTE implementation. > > DVIPAs were (obviously) not considered by RIP either, but with RIP2 and > an appropriate set of filters (that I will never be able to come up with > again, I fear!) the chance of the perpetual routing loop is lessened. > (Or maybe I was just never aware that we had the problem!) > > Anyway, this conversation, on and off list, has been a life saver. Later > this year my current shop is going from RIP to OSPF (and the core network > will be moving from Cisco's EIGRP to OSPF). In the same time frame we > will be moving fairly heavily to application-specific DVIPAs. If I hadn't > seen your posting I would not have seen that new parm that will save our > cookies. Many thanks for requesting the change. > > Regards, > Pat O'Keefe ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
