-----BEGIN PGP SIGNED MESSAGE----- My apologies, my question was apparently unclear. In the common situation where a downstream is allocated a sub-net from an upstream's super-block, and that downstream wishes to announce that sub-net to its neighbors, be those neighbors upstream, peer, or downstream of itself, or of the allocating upstream, the BGP algorithm does not appear to be equipped to handle the routing decision in an optimal manner. Thus far, I've encounter three methods of dealing with this situation. 1. Ignore routing aggregation - Everybody announces the sub-net. This works, but runs counter to a long standing goal of the community - reducing the size of the routing table. 2. Ignore the route announcement (netmask length) may work in some situations, but proves the point. 3. Local announcement only May be the result of 2 above, but again - proves the point. My question is, would the creation of a "multi-homed" flag in the BGP protocol be worth while discussing? I see this flag causing the algorithm to drop through the netmask test, and pick up at the metrics decision. Before persuing the question with the protocol folks, I thought I'd try to determine if there is enough interest in the capability to make it worth while.
Hi all, I've occasionally noticed a requirement to disregard mask when determining preferred route in the BGP algorithm. Specifically, when a multi-homed customer wishes to announce both his delegated networks through both connections. The goal is to achieve true multi-homing, with out requiring the customer to get independent address space. Thus far, I've used various "miserable hacks". Has anyone else perceived a similar requirement? if so, has anything being done to get such a flag added?
Or am I just missing the obvious?
- -- Rusty Zickefoose | The most exciting phrase to hear in science, rusty@cw.net | the one that heralds new discoveries, is not | "Eureka!", but "That's funny ..." | -- Isaac Asimov -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Public key may be found at http://pgpkeys.mit.edu:11371 iQCVAgUBNrYZNe4+ch/bGDylAQEWggP/cmvcOAg5gQd1oETTMBZu/j00RgQ2v1/M dmDayiIhZpVcNEiDnkoZlPh875Lw3Czo+8JlFXooHeznXyBt8YdZq1aXs4Xa62O5 jOrrh1gHPpiOxIT5Qi4356Nx77PHbGGjPD/LtWXU/oZWH6rsQhl1DWZSvBZyQdnd lpOb3PV5ths= =zw4l -----END PGP SIGNATURE-----
On Mon, 1 Feb 1999, Rusty Zickefoose wrote: :1. Ignore routing aggregation - Everybody announces the sub-net. : This works, but runs counter to a long standing goal of the : community - reducing the size of the routing table. My understanding of this setup is that they do not have portable space and have been allocated a block from you, and one from their other provider. If this is the case: Wouldn't this depend on what they were using multihoming for? If the customer site were able to send communities to their other provider that would tag the routes that you had assigned them as no-export, you wouldn't be crowding the global table. If you also recieved their other peers route, you would not export that route into the global table. You would continue announcing your supernet, as would the other provider theirs, and there is no pollution in the tables. :3. Local announcement only : May be the result of 2 above, but again - proves the point. Is this what I just described? : :My question is, would the creation of a "multi-homed" flag in the BGP :protocol be worth while discussing? How is this different than the multi_exit descriptor? (CCO is down as I write this so I can't look it up.) -- jamie.reid Chief Reverse Engineer Superficial Intelligence Research Division Defective Technologies
participants (2)
-
batz -
Rusty Zickefoose