<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    After hours of debugging, I got this 20MHz single-polarity link
    moving up to 55Mbit.  A high resolution spectrum analysis on both
    sides did indeed show a better frequency to use for the link. 
    Spectrum analysis captures here:<br>
    <br>
    <a class="moz-txt-link-freetext" href="https://imgur.com/a/4H7GB">https://imgur.com/a/4H7GB</a><br>
    <br>
    There was also an IP conflict between two modems @ Capitol Park. 
    The conflicting IP has been removed from CapitolPark-S3.<br>
    <br>
    The QueenAnne modem used for the link is not one used anywhere else
    on the network.  It's a very low-end modem, and as a result it was
    having CPU/RAM starvation issues when running our regular diagnostic
    tools, which lead to out-of-memory conditions and kernel crashes.  A
    different test methodology had to be used to verify the link speed
    (testing through the modem, instead of to the modem).<br>
    <br>
    The modem that links QueenAnne with the Westin building (on the
    QueenAnne side) had a mis-configured OSPF router-id.  This was
    fixed.<br>
    <br>
    I'm still seeing weird routing decisions being made by OSPF.  These
    are triggered by our point-to-point route entries (44.24.242.0/24
    space).  More research needs to be done here, and perhaps a re-write
    of how we define point-to-point interface addresses.  Any OSPF
    experts in the house?<br>
    <br>
    I also discovered R1.QueenAnne was still vulnerable to hacking due
    to a mis-configuration of its control software.  It missed the
    updates that were sent out to the whole network.  This has been
    fixed now.  R1.QueenAnne also didn't have the diagnostic
    bandwidth-server setup correctly.  This was fixed.<br>
    <br>
    With the CapitolPark-QueenAnne link performing well now:<br>
    <br>
    <tt>[eo@CapitolPark-QueenAnne] /system resource> /tool
      bandwidth-test 44.24.241.81 direction=both</tt><tt><br>
    </tt><tt>                status: running</tt><tt><br>
    </tt><tt>              duration: 57s</tt><tt><br>
    </tt><tt>            tx-current: 28.0Mbps</tt><tt><br>
    </tt><tt>  tx-10-second-average: 28.4Mbps</tt><tt><br>
    </tt><tt>      tx-total-average: 27.5Mbps</tt><tt><br>
    </tt><tt>            rx-current: 27.6Mbps</tt><tt><br>
    </tt><tt>  rx-10-second-average: 28.0Mbps</tt><tt><br>
    </tt><tt>      rx-total-average: 27.0Mbps</tt><tt><br>
    </tt><tt>          lost-packets: 288</tt><tt><br>
    </tt><tt>           random-data: no</tt><tt><br>
    </tt><tt>             direction: both</tt><tt><br>
    </tt><tt>               tx-size: 1500</tt><tt><br>
    </tt><tt>               rx-size: 1500</tt><tt><br>
    </tt><tt><br>
    </tt>its OSPF config has been reset to a normal preference level, so
    that packets no longer try to avoid that link as they are routed
    through the network.  This link can be sped up by upgrading to a
    dual-polarity modem @ CapitolPark.<br>
    <br>
    While testing if the OSPF hop cost was being calculated correctly in
    the Beacon-Haystack-QueenAnne RF link (they both connect to the same
    dish @ Haystack), I discovered a mis-config on the Haystack.Beacon
    modem (bad LAN IP binding) which was preventing it from bringing up
    OSPF on its LAN interface.  This was fixed and that modem should act
    like an actual router now, moving traffic.<br>
    <br>
    During the same Beacon testing, I was reminded that our Baldi-Beacon
    RF link <a moz-do-not-send="true"
href="https://monitoring.hamwan.net/cacti/graph.php?action=view&local_graph_id=919&rra_id=all">sucks</a>. 
    It was optimized for speed to Tukwila, which is now gone, so a trip
    needs to be scheduled to Baldi to rotate the dish a few degrees
    north and get that link going strong.<br>
    <br>
    I normally wouldn't send this kind of verbose email to psdr@, but I
    hope it's illuminating as to the type and extent of work required to
    keep this network running well.<br>
    <br>
    --Bart<br>
    <br>
  </body>
</html>