Re: PCIe adapters supporting long distance 10GB fiber?

[Jason Alderfer]

On Tue, Jun 20, 2017 at 11:15 AM, Baldur Norddahl  wrote:

> The real question here is: will my NIC support other SFP+ modules than the
> few options carried by the NIC vendor?



Has anyone tried changing the vendor ID of an SFP+ with one of these?
https://sfptotal.com/

I am highly intrigued and skeptical.

Jason

Re: AS205869, AS57166: Featured Hijacker of the Month, July, 2018

[Jason Alderfer]

radar.qrator.net serves as a complementary view to bgp.he.net and AS205869
does show as peered with AS6939 there.

Jason



On Tue, Jul 24, 2018 at 3:02 PM Ronald F. Guilmette 
wrote:

>
> In message <20180724.090316.47077931.sth...@nethelp.no>,
> sth...@nethelp.no wrote:
>
> >All prefixes still visible here (Oslo, Norway), through HE. Here's your
> >original table augmented with the AS paths I see on our border routers:
> >
> >ASN   RouteAS path
> >---
> >10510 216.238.64.0/18  6939 205869 32226 10510
> >10737 207.183.96.0/20  6939 205869 7827 10737
> >10800 192.110.32.0/19  6939 205869 11717 10800
> >19529 104.143.112.0/20 6939 205869 11324 19529
> >19529 198.14.0.0/206939 205869 7827 19529
> >19529 198.32.208.0/20  6939 205869 7827 19529
> >19529 206.41.128.0/20  6939 205869 11324 19529
> >30237 192.73.128.0/20  6939 205869 11717 30237
> >30237 192.73.144.0/20  6939 205869 11717 30237
> >30237 192.73.160.0/20  6939 205869 11717 30237
> >30237 192.73.176.0/20  6939 205869 11717 30237
>
> Thanks for checking this.  I gather from the other posts in this thread
> that this has already been rectified, and that the above CIDRs are no
> longer reachable via HE.NET, correct?
>
> Even if that's the case, I'm still left scratching my head.  There's a
> bit of a mystery here, or at least something that I don't quite understand.
> (NOTE: I've never laid claim to being anything like an "expert" when it
> comes to all this routing stuff.  I just muddle along and try to do the
> best I can with the limited knowledge and understanding that I have.)
>
> So, here's what's perplexing me.  You reported that all eleven of the
> routes in the table above had AS paths that directly connected
> Universal IP Solution Corp. (AS205869) to Hurricane Electric (AS6939).
> And yet, when I looked at the following page, both yesterday and today,
> I see no reported connection between those two ASNs:
>
>  https://bgp.he.net/AS205869#_peers
>
> I already knew before now that each of the alleged peerings reported on
> similar pages on the bgp.he.net web site had to be taken with a grain of
> salt, mostly or entirely because of the kinds of hanky panky and path
> forgery being undertaken by various bad guys.  In at least some cases,
> these screwy games appear to have caused bgp.he.net to list peerings that
> didn't actually exist.
>
> But this is a rather entirely different case.  In this case, it seems
> that one very notable peering that -did- in fact exist, between AS205869
> and AS6939, was not reported at all on the bgp.he.net page linked to
> above.
>
> To be clear, I most definitely am *not* suggeting any sort of deliberate
> obfsucation here, on anybody's part.  Rather, I just suspect that some
> of the algorithms that are used to produce the peers lists on bgp.he.net
> could use some... ah... fine tuning.  It certainly seems to be  true that
> in this case, one very important peering was utterly missed by the
> algorithms
> that power bgp.he.net.
>
>
> Regards,
> rfg
>

Re: Wifi Calling Firewall Holes to Punch

[Jason Alderfer]

In our university environment, wifi calling works just fine over NAT and
we have not made any inbound port exceptions in the firewall for it.  The
critical piece for (non-enterprise) VoIP traffic is that your firewall must
not try to function as a SIP ALG, but I'm not sure that's directly relevant
to wifi calling for the major carriers.

Jason Alderfer
Director of Technology SystemsEastern Mennonite University


On Fri, Jul 17, 2020 at 12:40 PM Lyden, John C  wrote:

> Hey gang.
>
>
>
> We’re setting up a unified wireless network for the students here, and to
> get around the issues with Nintendo and NAT we devoted a large chunk of
> public IP space to them.
>
>
>
> We’re aware that this is causing issues with wifi calling on Verizon, TMo
> etc because it appears they initiate the SIP session inbound.
>
>
>
> Does anybody have a handy list of IP blocks and ports? T-Mobile had a
> decent page but other providers just said “open up 4500 and 500” and our
> ISO guys don’t like that.
>
>
>
> Thanks if someone can help.
>
>
>
> John C. Lyden
>
> Manager of Network Infrastructure, Infrastructure Services
>
> Division of Information Resources & Technology, Rowan University
>
>
>