And/or see if bell canada can sell you something diverse.
If all else fails, you could setup a pair of static IPIP or GRE
tunnels using the static provider-assigned address on your link into
the non-bgp speaking provider. Then, terminate the 'far side' of the
tunnel on a router collocated somewhere upstream of if the brain-dead
provider. This would get you a 'unicast overlay' across the brain-dead
reseller of the bell.ca transit to a router where you could speak bgp
to real-er transits providers, peers, or others networks.
If you had the luxury of a cisco 720x/7301 pair (for your local router
and upstream tunnel endpoint), you could take advantage of the
transparent ip fragmentation and virtual-reassembly in 12.4, ip tcp
mss 'adjustment' (to handle the 20+ bytes of lost MTU via the tunnel),
and some shaping/fancy-QoS for making the (likely) congested-as-heck
path in or out of this network a bit less horrible for end-users.
Best,
-Tk
The short story behind this deployment is that Charle's infrastructure is at the tail end of a submarine cable on an island, where there is only 1 competitor, but the ILEC, on the island side of the submarine cable.
The ILEC owns the submarine cable
But the ILEC will not do BGP
The competitor will do BGP
But the the ILEC will not do BGP
Because the ILEC has yet to do BGP with anyone in its serving territory. Its a SMALL ILEC which does not have ISP customers wishing to do BGP elsewhere in its territory.
I have told Charles that should he wish to complain to the regulator, to force the ILEC to do BGP, then we would help him.
His question is rather - how to do multihoming on the same /22, when one the two upstream ISPs, will not do BGP.
And the obvious answer is, S.O.L.
The not so obvious answer, is ANYONE OUT THERE knows how to do multihoming without BGP on one of the two legs...
F.