That's what I always do too, I almost never use the internal speedtest on backhaul radios. I do like having the ability to directly access the radio if the ethernet port were to die on the router on the far side or something like that, which is a problem if the management IP is only accessible from the router on the far side... of course, I guess you could always just setup that IP on the router at the other end if you needed to. ________________________________ From: Af [[email protected]] on behalf of Bill Prince via Af [[email protected]] Sent: Tuesday, October 07, 2014 10:52 AM To: [email protected] Subject: Re: [AFMUG] managing radios in an ospf network with a failed link
When we speedtest a link, we generally go router<->router via their private router IDs. Leave the privates of the backhauls out of the equation (let them be transparent). bp On 10/7/2014 8:38 AM, That One Guy via Af wrote: good deal, so im not going to monkey things up? if it is ospf, even with /30 on each end, the radios should be able to communicate, only via their ethernet ports through the routers if you were going to run speedtest? On Tue, Oct 7, 2014 at 10:34 AM, Bill Prince via Af <[email protected]<mailto:[email protected]>> wrote: If the backhaul is in a chain, we generally put their management IPs in a /30 from the local router. So there is a separate /30 at each end of the link. If the backhaul is in a cul-de-sac, we might put them in a /29 from the near-end (the end closest to the backbone). However, we mostly do the /30, as it is an easy way to prevent the management IPs becoming part of a public route. bp On 10/6/2014 7:44 PM, That One Guy via Af wrote: This came up before, but I cant find the thread. is the attached configuration the correct way to set up access to the radios? I had initially thought having the radios in the same subnet is how it is supposed to be, primarily because thats how it always was, but with having the radios in a /30 on each side of the link you would be able to access the local side radio if the link were to drop. Is this the correct way of looking at this or is there a better method of maintaining access in a dynamic environment?? -- All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer. -- IBM maintenance manual, 1925 -- All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer. -- IBM maintenance manual, 1925
