[AFMUG] fiber cost per home directional and pole attach
I'm looking at venturing into fiber, I've done enough research and bugged most of you on the list that I think I have enough knowledge to get going (and be dangerous). I'm looking at two options for our area, 1. Service newer subdivisions of houses that are currently served by cable and dsl with speeds up to 1G in certain areas, average is about 50mbps, this would be an all directional drill job underground. What is a good cost per ft, or cost per house passed for drilling, conduit and fiber? 2. Service the older side of town that has mostly overhead utilities by signing an attachment agreement with the local power company, much lower deployment cost and generally a more 'under served' area but also a lower income area, using almost 100% pole attachments. What is a good cost per ft or house passed (these are all small 1000-2000ft2 homes with small parcels) for cable, and pole attachment fee's, lashing, etc? I'm looking at PON but may go AE depending on some factors Anyone bored enough to throw some advice my way? Thank you! TJ Trout
Re: [AFMUG] OT where to eat
Just got back from pappadeux. Good cajun seafood. Not cheap. 15-20min drive. On Mar 5, 2018 8:35 PM, "Jaime Solorza" wrote: Pappadeux or Texas de Brasil says my younger brother who travels through there allot. Waffle House great for breakfast Jaime Solorza On Mar 5, 2018 6:19 PM, "Chuck McCown" wrote: > In BHM Sheraton. Where to eat? >
Re: [AFMUG] OOB management port bridging MAC tables
Take two Tecates and call me in the morning...all will be well... Jaime Solorza On Mar 5, 2018 7:40 PM, "Steve Jones" wrote: > > no, as it turns out, its called "read the fucking manual, you dolt". (im > the dolt) > I dont know If SAF words things odd, or if im full shortbus anymore > > "The Integra-W link with out-band management implements two Ethernet > connections – one for > management traffic and the second for user traffic. Since user traffic and > management circuits > are parallel, an Ethernet loop will occur. To avoid the loop, management > on WAN interfaces has > to be disabled by entering this command in CLI “modem management 0”. > Thereby management > Link aggregation/bonding and load balancing with SAF products 31 > traffic will only pass through the wireless link via the user traffic > connection egressing the MNG > port." > > > Id like to blame them, but thats pretty straight forward right there, And > I read it like 10 times, they even recommended trying that command, it just > never registered... im off to go lick windows. > > > On Mon, Mar 5, 2018 at 7:21 PM, Jaime Solorza > wrote: > >> It's called loopis destructusturn off management port on far side and >> see if that clears it up... >> >> Jaime Solorza >> >> On Mar 5, 2018 5:32 PM, "Steve Jones" wrote: >> >>> scratch that. My powercode DHCP server is freaked out getting queries >>> from both sides >>> >>> On Mon, Mar 5, 2018 at 5:44 PM, Steve Jones >>> wrote: >>> I may be helmet here, but am I correct in assuming that OOB managment ports should not participate in bridging traffic across wireless links of any kind? this 2+0 has OOB on the radios, I have the management ports run into a switch on each side. Loop protection is kicking the ports on and off. The customer traffic is flowing over the wireless via LACP bonding in the same switch, but isolated via VLAN. I should not, under any circumstances see MAC addresses from the other side of a link via the management port should I? Im not only seeing the remote switch, but every mac in the MAC table from the remote switch. both sides have the OOB in ports 21 and 22, in the following, both switched have port 22 blocked due to detected loop, but it flip flops back and forth between 21 and 22 when the detection timer expires. I havent had calls of any issues with customer traffic (both are independent DHCP subnets) A SIDE Switch MAC Address - 74:46:a0:e8:ed:00 A SIDE MAC Table 38:ea:a7:bc:24:40 21 Learned B SIDE Switch MAC Address - 38:ea:a7:bc:24:40 B SIDE MAC Table 74:46:a0:e8:ed:0021 Learned >>> >
Re: [AFMUG] OOB management port bridging MAC tables
lol, i noticed that. I dont know how customers werent impacted since theyre all DHCP with 24 hour leases and we cut over yesterday. I feel dumb, so dumb Im wondering if I should identify as a woman. On Mon, Mar 5, 2018 at 8:17 PM, Jaime Solorza wrote: > In simplest terms you seem to running to long Ethernet cables to same > switch... > > Jaime Solorza > > On Mar 5, 2018 5:36 PM, "Jaime Solorza" wrote: > >> It's called loopis destructusturn off management port on far side and >> see if that clears it up... >> >> Jaime Solorza >> >> On Mar 5, 2018 5:32 PM, "Steve Jones" wrote: >> >>> scratch that. My powercode DHCP server is freaked out getting queries >>> from both sides >>> >>> On Mon, Mar 5, 2018 at 5:44 PM, Steve Jones >>> wrote: >>> I may be helmet here, but am I correct in assuming that OOB managment ports should not participate in bridging traffic across wireless links of any kind? this 2+0 has OOB on the radios, I have the management ports run into a switch on each side. Loop protection is kicking the ports on and off. The customer traffic is flowing over the wireless via LACP bonding in the same switch, but isolated via VLAN. I should not, under any circumstances see MAC addresses from the other side of a link via the management port should I? Im not only seeing the remote switch, but every mac in the MAC table from the remote switch. both sides have the OOB in ports 21 and 22, in the following, both switched have port 22 blocked due to detected loop, but it flip flops back and forth between 21 and 22 when the detection timer expires. I havent had calls of any issues with customer traffic (both are independent DHCP subnets) A SIDE Switch MAC Address - 74:46:a0:e8:ed:00 A SIDE MAC Table 38:ea:a7:bc:24:40 21 Learned B SIDE Switch MAC Address - 38:ea:a7:bc:24:40 B SIDE MAC Table 74:46:a0:e8:ed:0021 Learned >>>
Re: [AFMUG] OOB management port bridging MAC tables
no, as it turns out, its called "read the fucking manual, you dolt". (im the dolt) I dont know If SAF words things odd, or if im full shortbus anymore "The Integra-W link with out-band management implements two Ethernet connections – one for management traffic and the second for user traffic. Since user traffic and management circuits are parallel, an Ethernet loop will occur. To avoid the loop, management on WAN interfaces has to be disabled by entering this command in CLI “modem management 0”. Thereby management Link aggregation/bonding and load balancing with SAF products 31 traffic will only pass through the wireless link via the user traffic connection egressing the MNG port." Id like to blame them, but thats pretty straight forward right there, And I read it like 10 times, they even recommended trying that command, it just never registered... im off to go lick windows. On Mon, Mar 5, 2018 at 7:21 PM, Jaime Solorza wrote: > It's called loopis destructusturn off management port on far side and > see if that clears it up... > > Jaime Solorza > > On Mar 5, 2018 5:32 PM, "Steve Jones" wrote: > >> scratch that. My powercode DHCP server is freaked out getting queries >> from both sides >> >> On Mon, Mar 5, 2018 at 5:44 PM, Steve Jones >> wrote: >> >>> I may be helmet here, but am I correct in assuming that OOB managment >>> ports should not participate in bridging traffic across wireless links of >>> any kind? >>> this 2+0 has OOB on the radios, I have the management ports run into a >>> switch on each side. Loop protection is kicking the ports on and off. The >>> customer traffic is flowing over the wireless via LACP bonding in the same >>> switch, but isolated via VLAN. >>> >>> I should not, under any circumstances see MAC addresses from the other >>> side of a link via the management port should I? Im not only seeing the >>> remote switch, but every mac in the MAC table from the remote switch. both >>> sides have the OOB in ports 21 and 22, in the following, both switched have >>> port 22 blocked due to detected loop, but it flip flops back and forth >>> between 21 and 22 when the detection timer expires. I havent had calls of >>> any issues with customer traffic (both are independent DHCP subnets) >>> >>> A SIDE Switch MAC Address - 74:46:a0:e8:ed:00 >>> >>> A SIDE MAC Table >>> >>> 38:ea:a7:bc:24:40 21 Learned >>> >>> >>> >>> B SIDE Switch MAC Address - 38:ea:a7:bc:24:40 >>> >>> B SIDE MAC Table >>> >>> 74:46:a0:e8:ed:0021 Learned >>> >>> >>
Re: [AFMUG] OT where to eat
Pappadeux or Texas de Brasil says my younger brother who travels through there allot. Waffle House great for breakfast Jaime Solorza On Mar 5, 2018 6:19 PM, "Chuck McCown" wrote: > In BHM Sheraton. Where to eat? >
Re: [AFMUG] OT where to eat
At mugshots bar and grill. 100 yards to the right from hotel > On Mar 5, 2018, at 19:19, Chuck McCown wrote: > > In BHM Sheraton. Where to eat?
Re: [AFMUG] OOB management port bridging MAC tables
Depends on the device. Lots of radios have an OOB channel across the link. Cielo for example. It's only like 256K but great for management if your running a real oob mgmt network. Sent from my iPhone > On Mar 5, 2018, at 7:31 PM, Steve Jones wrote: > > I may be helmet here, but am I correct in assuming that OOB managment ports > should not participate in bridging traffic across wireless links of any kind? > this 2+0 has OOB on the radios, I have the management ports run into a switch > on each side. Loop protection is kicking the ports on and off. The customer > traffic is flowing over the wireless via LACP bonding in the same switch, but > isolated via VLAN. > > I should not, under any circumstances see MAC addresses from the other side > of a link via the management port should I? Im not only seeing the remote > switch, but every mac in the MAC table from the remote switch. both sides > have the OOB in ports 21 and 22, in the following, both switched have port 22 > blocked due to detected loop, but it flip flops back and forth between 21 and > 22 when the detection timer expires. I havent had calls of any issues with > customer traffic (both are independent DHCP subnets) > > A SIDE Switch MAC Address - 74:46:a0:e8:ed:00 > A SIDE MAC Table > 38:ea:a7:bc:24:40 21 Learned > > B SIDE Switch MAC Address - 38:ea:a7:bc:24:40 > B SIDE MAC Table > 74:46:a0:e8:ed:0021 Learned >
Re: [AFMUG] AF Summer Session
Just don't embarrass yourself like I did in Vegas many years ago at an HP booth and I assumed the very attractive lady was just a booth babe model...she was an EE Jaime Solorza On Mar 5, 2018 6:31 PM, "Jaime Solorza" wrote: Any pics of booth babe? Jaime Solorza On Mar 5, 2018 6:24 PM, "Chuck McCown" wrote: > Stop by our booth at WISPAmerica and help us get the AnimalFarm Summer > 2018 session on the calendar. I am thinking the first week in June. >
Re: [AFMUG] AF Summer Session
Any pics of booth babe? Jaime Solorza On Mar 5, 2018 6:24 PM, "Chuck McCown" wrote: > Stop by our booth at WISPAmerica and help us get the AnimalFarm Summer > 2018 session on the calendar. I am thinking the first week in June. >
Re: [AFMUG] OOB management port bridging MAC tables
In simplest terms you seem to running to long Ethernet cables to same switch... Jaime Solorza On Mar 5, 2018 5:36 PM, "Jaime Solorza" wrote: > It's called loopis destructusturn off management port on far side and > see if that clears it up... > > Jaime Solorza > > On Mar 5, 2018 5:32 PM, "Steve Jones" wrote: > >> scratch that. My powercode DHCP server is freaked out getting queries >> from both sides >> >> On Mon, Mar 5, 2018 at 5:44 PM, Steve Jones >> wrote: >> >>> I may be helmet here, but am I correct in assuming that OOB managment >>> ports should not participate in bridging traffic across wireless links of >>> any kind? >>> this 2+0 has OOB on the radios, I have the management ports run into a >>> switch on each side. Loop protection is kicking the ports on and off. The >>> customer traffic is flowing over the wireless via LACP bonding in the same >>> switch, but isolated via VLAN. >>> >>> I should not, under any circumstances see MAC addresses from the other >>> side of a link via the management port should I? Im not only seeing the >>> remote switch, but every mac in the MAC table from the remote switch. both >>> sides have the OOB in ports 21 and 22, in the following, both switched have >>> port 22 blocked due to detected loop, but it flip flops back and forth >>> between 21 and 22 when the detection timer expires. I havent had calls of >>> any issues with customer traffic (both are independent DHCP subnets) >>> >>> A SIDE Switch MAC Address - 74:46:a0:e8:ed:00 >>> >>> A SIDE MAC Table >>> >>> 38:ea:a7:bc:24:40 21 Learned >>> >>> >>> >>> B SIDE Switch MAC Address - 38:ea:a7:bc:24:40 >>> >>> B SIDE MAC Table >>> >>> 74:46:a0:e8:ed:0021 Learned >>> >>> >>
[AFMUG] AF Summer Session
Stop by our booth at WISPAmerica and help us get the AnimalFarm Summer 2018 session on the calendar. I am thinking the first week in June.
Re: [AFMUG] OOB management port bridging MAC tables
It's called loopis destructusturn off management port on far side and see if that clears it up... Jaime Solorza On Mar 5, 2018 5:32 PM, "Steve Jones" wrote: > scratch that. My powercode DHCP server is freaked out getting queries from > both sides > > On Mon, Mar 5, 2018 at 5:44 PM, Steve Jones > wrote: > >> I may be helmet here, but am I correct in assuming that OOB managment >> ports should not participate in bridging traffic across wireless links of >> any kind? >> this 2+0 has OOB on the radios, I have the management ports run into a >> switch on each side. Loop protection is kicking the ports on and off. The >> customer traffic is flowing over the wireless via LACP bonding in the same >> switch, but isolated via VLAN. >> >> I should not, under any circumstances see MAC addresses from the other >> side of a link via the management port should I? Im not only seeing the >> remote switch, but every mac in the MAC table from the remote switch. both >> sides have the OOB in ports 21 and 22, in the following, both switched have >> port 22 blocked due to detected loop, but it flip flops back and forth >> between 21 and 22 when the detection timer expires. I havent had calls of >> any issues with customer traffic (both are independent DHCP subnets) >> >> A SIDE Switch MAC Address - 74:46:a0:e8:ed:00 >> >> A SIDE MAC Table >> >> 38:ea:a7:bc:24:40 21 Learned >> >> >> >> B SIDE Switch MAC Address - 38:ea:a7:bc:24:40 >> >> B SIDE MAC Table >> >> 74:46:a0:e8:ed:0021 Learned >> >> >
[AFMUG] OT where to eat
In BHM Sheraton. Where to eat?
Re: [AFMUG] OOB management port bridging MAC tables
scratch that. My powercode DHCP server is freaked out getting queries from both sides On Mon, Mar 5, 2018 at 5:44 PM, Steve Jones wrote: > I may be helmet here, but am I correct in assuming that OOB managment > ports should not participate in bridging traffic across wireless links of > any kind? > this 2+0 has OOB on the radios, I have the management ports run into a > switch on each side. Loop protection is kicking the ports on and off. The > customer traffic is flowing over the wireless via LACP bonding in the same > switch, but isolated via VLAN. > > I should not, under any circumstances see MAC addresses from the other > side of a link via the management port should I? Im not only seeing the > remote switch, but every mac in the MAC table from the remote switch. both > sides have the OOB in ports 21 and 22, in the following, both switched have > port 22 blocked due to detected loop, but it flip flops back and forth > between 21 and 22 when the detection timer expires. I havent had calls of > any issues with customer traffic (both are independent DHCP subnets) > > A SIDE Switch MAC Address - 74:46:a0:e8:ed:00 > > A SIDE MAC Table > > 38:ea:a7:bc:24:40 21 Learned > > > > B SIDE Switch MAC Address - 38:ea:a7:bc:24:40 > > B SIDE MAC Table > > 74:46:a0:e8:ed:0021 Learned > >
[AFMUG] OOB management port bridging MAC tables
I may be helmet here, but am I correct in assuming that OOB managment ports should not participate in bridging traffic across wireless links of any kind? this 2+0 has OOB on the radios, I have the management ports run into a switch on each side. Loop protection is kicking the ports on and off. The customer traffic is flowing over the wireless via LACP bonding in the same switch, but isolated via VLAN. I should not, under any circumstances see MAC addresses from the other side of a link via the management port should I? Im not only seeing the remote switch, but every mac in the MAC table from the remote switch. both sides have the OOB in ports 21 and 22, in the following, both switched have port 22 blocked due to detected loop, but it flip flops back and forth between 21 and 22 when the detection timer expires. I havent had calls of any issues with customer traffic (both are independent DHCP subnets) A SIDE Switch MAC Address - 74:46:a0:e8:ed:00 A SIDE MAC Table 38:ea:a7:bc:24:40 21 Learned B SIDE Switch MAC Address - 38:ea:a7:bc:24:40 B SIDE MAC Table 74:46:a0:e8:ed:0021 Learned
[AFMUG] Birmingham Hotel
Does anyone need a room at the DoubleTree? Booked this morning, now I don't need it. 815-739-5582 -Mike HammettIntelligent Computing SolutionsMidwest Internet ExchangeThe Brothers WISP
[AFMUG] OT: Stuff I didn't know about Lithium battery chemistry
Before I read this article, my understanding of "Lithium Ion" batteries was rather limited. I had not been aware of the many and varied chemistries for these batteries and the cost implications with the amount of cobalt. From reading this, it appears that the next big step in Lithium Ion batteries is "NMC", and more specifically the "811" ratio of Nickel, Manganese, & Cobalt. Fascinating read for those of you interested: https://cleantechnica.com/2018/03/04/exciting-developments-nmc-811-lithium-battery-technology/ They are looking at energy density of 300 WH/Kg. By way of comparison, SLA batteries are in the 40-50 WH/Kg. -- bp
[AFMUG] SAF OMT Labels backward
We finally got our first 2+0 deployed this weekend. LEAX-Arkivator OMT label is backward on the polatity FYI. If you have these out, you might check to make sure that youre not operating on the wrong polarity. the stamp on the face is correct though
Re: [AFMUG] Ot: homeland
Really fun. Did you read the Ruby Ridge book. Sent from my iPhone > On Mar 4, 2018, at 10:48 PM, CBB - Jay Fuller > wrote: > > > After watching tonight's episode I find it very interesting they are tying > the narrative right into what is happening in our country right now with fake > news > > When you have seen the episode comment we will discuss > > Sent from my smartphone >
