Re: Acceptance of RPKI unknown in ROV

[Aftab Siddiqui]

On Thu, 19 Oct 2023 at 1:37 pm, Owen DeLong  wrote:

> I ask because there was discussion at the ARIN meeting and Kevin Blumburg
> made the suggestion that “in 2024, routes will not be accepted without
> ROAs”.
>

As someone who was there, that’s misrepresentation of what Kevin said. Im
sure  he can jump in and share his detailed point of view, but his point
was many operators and cloud providers are already demanding to have a
valid ROA to peer or use their services and that most likely become a
requirement moving forward.

For legacy resource holders it is a problem but then it’s a bureaucratic
issue rather technical and technology has a solution called SLURM.

Re: Acceptance of RPKI unknown in ROV

[Aftab Siddiqui]

A quick check to my routing table suggests that I have 206700
preferred routes (v4/v6) to notfound (unknown) destinations. So yeah I
don't think anyone can afford to do this right now.

Regards,

Aftab A. Siddiqui


On Fri, 20 Oct 2023 at 05:49, Owen DeLong via NANOG  wrote:

> A question for network operators out there that implement ROV…
>
> Is anyone rejecting RPKI unknown routes at this time?
>
> I know that it’s popular to reject RPKI invalid (a ROA exists, but doesn’t
> match the route), but I’m wondering if anyone  is currently or has any
> plans to start rejecting routes which don’t have a matching ROA at all?
>
> Thanks,
>
> Owen
>
>

Re: 128/9 cite

[Aftab Siddiqui]

On Thu, 8 Jun 2023 at 02:15, Randy Bush  wrote:

> doug madory is asking me for a cite for the exciting 1997/8 128/9 bgp
> event.  my memory as reported to doug is
>
> soon after the 7007 incident, an engineer in a UUNET lab, not
> realizing they were connected to the real internet, used the hidden
> bgp test command to generate 128/9 chopped into /24s.  took uunet
> down, but not before it propagated.
>
> does anyone have a useful cite?
>

I definitely read a detailed research paper about that incident long ago
but can't find any link with any search keywords. But here is the NANOG
archive.

https://archive.nanog.org/mailinglist/mailarchives/old_archive/1997-10/msg00095.html
https://archive.nanog.org/mailinglist/mailarchives/old_archive/1997-10/msg00110.html
https://archive.nanog.org/mailinglist/mailarchives/old_archive/1997-10/msg00108.html

Regards,

Aftab A. Siddiqui

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

[Aftab Siddiqui]

> Kenneth Finnegan wrote on 04/04/2022 21:05:
> > I've taken it upon myself to create
> > proxy registrations for all of these prefixes in ALTDB.
>
> Please don't.
>

Too late, all 394 routes mentioned above are now in ALTDB.


> You're not doing the routing security ecosystem any favours by doing
> this. Couple of reasons why: 1. this isn't your data and this is an
> unexpected action on the part of the registrants, 2. this is a sure-fire
> way of accumulating even more cruft in ALTDB in a way which is
> troublesome to clean up afterwards, 3. there are several thousand
> objects in there which are already marked as proxy registrations, and
> are already likely to be inaccurate, 4. you're losing authentication
> information for people to self-manage their registrations, and 5. you
> have likely not cross-checked this data against RIR transfers /
> de-registrations - it's not really possible to do with with the
> arin-nonauth db because that db doesn't include the last-modified
> timestamp, and the changed: attribute is unreliable.
>

Can't express it any better than this :(

Re: BGP hujack by AS25478?

[Aftab Siddiqui]

Noction - could be but there were not many specifics in around 3200 routes
they originated, there were few /12, /13, /14

mistake probably.

121.128.0.0/12 39120 65478 25478
121.128.0.0/12 61568 65478 25478
121.144.0.0/13 61568 65478 25478
141.48.0.0/13 61568 65478 25478
203.40.0.0/13 39120 65478 25478
203.40.0.0/13 61568 65478 25478

Regards,

Aftab A. Siddiqui


On Tue, 9 Nov 2021 at 18:03, Hank Nussbacher  wrote:

> Based on my own observation as well as via bgpstream there was a massive
> BGP hijack attempt last night by IHOME-AS iHome LLC, RU (AS 25478).
>
> Lasted about 10 minutes.  Noction?  Finger faddle? Malicious?
>
>
> Thanks,
>
> Hank
>
>

Re: ROA coverage info

[Aftab Siddiqui]

can't even reach nist.gov.

Regards,

Aftab A. Siddiqui


On Mon, 14 Jun 2021 at 15:29, Hank Nussbacher  wrote:

> On 24/08/2020 17:49, Rayhaan Jaufeerally (NANOG) wrote:
> > There's also this site run by NIST: https://rpki-monitor.antd.nist.gov/
> >  which contains further breakdowns
>
> Anyone know why https://rpki-monitor.antd.nist.gov/ is down?
>
> Thanks,
> Hank
>
>

Re: Tier1 BGP filter generation data sources & frequency

[Aftab Siddiqui]

Hi Jon, (and anyone with similar issues)


> BTW...speaking of MANRS, if there's someone on-list who can help out with
> some questions, I'd appreciate the contact.  For $work, I'd been talking
> to Kevin Meynell about our joining.  It fell through the cracks and
> recently popped back up.  Recent email to Kevin got no reply.


Kevin is the right person but the email queue recently has doubled (more
than double in just 2021). We have implemented the ticketing system now in
order to avoid this happening again. But still no excuses :( you can keep
ma...@isoc.org in loop


> The MANRS web site could use quite a bit of clarification (or maybe just
> toss it and
> start over).
>

Yes, we are taking the later approach. Couple of months and it should be
better.

Re: Cloudflare OCTO RPKI Validator - LACNIC CAs issues

[Aftab Siddiqui]

Hi Douglas,
Not sure about dip in their rpki monitoring page for lacnic, but I could
see the VRP here
https://rpki.cloudflare.com/rpki.json

The daily snapshot taken at 23:47 22-04-2021 using rpki.cloudflare.com
shows the prefix.

cloudflare# grep 200.160.0.0 2021-04-22-2347-UTC
+ 200.160.0.0 20 -  2422548

rtrclient tcp -k -p rtr.rpki.cloudflare.com 8282

Regards,

Aftab A. Siddiqui


On Fri, 23 Apr 2021 at 05:50, Douglas Fischer 
wrote:

> Does anybody else have problems with Cloudflare's RPKI Validator with
> prefixes from LACNIC?
>
> Customers were sending us some reports of issues with LACNIC's IPBlocks
> using Cloudflare RPKI as source of validation.
>
> A friend and I did some checks. And looks like that some issue is
> happening on the Lacnic Trust Anchor, specifically on OctoRPKI.
> We took the Registro.Br Prefix to do the tests -> 200.160.0.0/20 ->
> AS22548
>
>  -> On Cloudflare
>
> https://rpki.cloudflare.com/?view=validator=22548_200.160.0.0%2F20
> AS22548_200.160.0.0/20 is Unknown at 19:30 20201-04-22
> https://pasteboard.co/JYy8fjI.png
>
> -> On Ripe
> https://rpki-validator.ripe.net/bgp-preview
> AS22548_200.160.0.0/20 is Valid at 19:30 20201-04-22
> https://pasteboard.co/JYycsd4.png
>
> An interesting thing is that on the graph of ROAs over Timer of the Lacnic
> Trust Anchor shows a big drop on 20201/04/19.
> https://rpki.cloudflare.com/?ohlcTa=LACNIC
> "Volume Removed: 14.761"
> "ROAs Removed: 13.392"
> https://pasteboard.co/JYyeSaw.png
>
> Any idea of possible causes?
> Any suggestions on how to solve it?
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>

Re: ROA coverage info

[Aftab Siddiqui]

+1 to RIPE stats.

Here is from NLnet labs:
https://www.nlnetlabs.nl/projects/rpki/rpki-analytics/

Regards,

Aftab A. Siddiqui


On Tue, 25 Aug 2020 at 00:46, Nathalie Trenaman  wrote:

> Hi Fabiano,
>
> Is this what you are looking for?
> https://stat.ripe.net/widget/rpki-by-trust-anchor
>
> Cheers,
> Nathalie Trenaman
> RIPE NCC
>
> Op 24 aug. 2020, om 15:21 heeft Fabiano D'Agostino <
> fabiano.dagostin...@gmail.com> het volgende geschreven:
>
> Hi all,
> I would like to ask you if there is some information about ROA coverage of
> IPv4/v6 address space in the different RIRs.
>
> Thanks in advance.
>
> Regards,
>
> Fabiano
>
>
>

Re: BGP route hijack by AS10990

[Aftab Siddiqui]

Not a single prefix was signed, what I saw. May be good reason for Rogers,
Charter, TWC etc to do that now. It would have stopped the propagation at
Telia.

On Fri, 31 Jul 2020 at 8:40 am, Baldur Norddahl 
wrote:

> Telia implements RPKI filtering so the question is did it work? Were any
> affected prefixes RPKI signed? Would any prefixes have avoided being
> hijacked if RPKI signing had been in place?
>
> Regards
>
> Baldur - who had to turn off RPKI filtering at the request of JTAC to stop
> our mx204s from crashing :-(
>
> tor. 30. jul. 2020 18.59 skrev Töma Gavrichenkov :
>
>> Peace,
>>
>> On Thu, Jul 30, 2020, 5:48 AM Clinton Work  wrote:
>>
>>> We saw a bunch of our IP blocks hijacked by AS10990 from 19:15 MDT until
>>> 20:23 MDT.   Anybody else have problems with that.
>>>
>>
>> Here's what we discovered about the incident.  Hope that brings some
>> clarity.
>>
>> https://radar.qrator.net/blog/as10990-routing-optimization-tale
>>
>> --
>> Töma
>>
>>> --
Regards,

Aftab A. Siddiqui

Re: BGP route hijack by AS10990

[Aftab Siddiqui]

Looks like the list is too long.. none of them have any valid ROAs as well.

= 104.230.0.0/18 206313 6724 1299 7219 10990
= 104.230.64.0/18 206313 6724 1299 7219 10990
= 107.184.0.0/16 206313 6724 1299 7219 10990
= 107.185.0.0/16 206313 6724 1299 7219 10990
= 107.189.192.0/19 206313 6724 1299 7219 10990
= 107.189.224.0/19 206313 6724 1299 7219 10990
= 108.49.0.0/17 206313 6724 1299 7219 10990
= 108.49.128.0/17 206313 6724 1299 7219 10990
= 135.19.192.0/19 206313 6724 1299 7219 10990
= 135.19.224.0/19 206313 6724 1299 7219 10990
= 137.119.140.0/23 206313 6724 1299 7219 10990
= 137.119.142.0/23 206313 6724 1299 7219 10990
= 142.113.0.0/17 206313 6724 1299 7219 10990
= 142.113.128.0/17 206313 6724 1299 7219 10990
= 147.194.0.0/20 206313 6724 1299 7219 10990
= 147.194.16.0/20 206313 6724 1299 7219 10990
= 162.157.0.0/17 206313 6724 1299 7219 10990
= 162.157.128.0/17 206313 6724 1299 7219 10990
= 166.48.0.0/18 206313 6724 1299 7219 10990
= 166.48.64.0/18 206313 6724 1299 7219 10990
= 167.100.80.0/22 206313 6724 1299 7219 10990
= 167.100.84.0/22 206313 6724 1299 7219 10990
= 172.103.112.0/20 206313 6724 1299 7219 10990
= 172.103.96.0/20 206313 6724 1299 7219 10990
= 172.112.0.0/14 206313 6724 1299 7219 10990
= 172.116.0.0/14 206313 6724 1299 7219 10990
= 173.160.0.0/14 206313 6724 1299 7219 10990
= 173.164.0.0/14 206313 6724 1299 7219 10990
= 173.28.224.0/21 206313 6724 1299 7219 10990
= 173.28.232.0/21 206313 6724 1299 7219 10990
= 173.48.0.0/17 206313 6724 1299 7219 10990
= 173.48.128.0/17 206313 6724 1299 7219 10990
= 173.90.0.0/16 206313 6724 1299 7219 10990
= 173.91.0.0/16 206313 6724 1299 7219 10990
= 174.1.56.0/23 206313 6724 1299 7219 10990
= 174.1.58.0/23 206313 6724 1299 7219 10990
= 174.108.0.0/15 206313 6724 1299 7219 10990
= 174.110.0.0/15 206313 6724 1299 7219 10990
= 174.223.0.0/18 206313 6724 1299 7219 10990
= 174.223.64.0/18 206313 6724 1299 7219 10990
= 174.228.0.0/18 206313 6724 1299 7219 10990
= 174.228.64.0/18 206313 6724 1299 7219 10990
= 174.231.128.0/18 206313 6724 1299 7219 10990
= 174.231.192.0/18 206313 6724 1299 7219 10990
= 177.132.112.0/20 206313 6724 1299 7219 10990
= 177.132.96.0/20 206313 6724 1299 7219 10990
= 198.166.0.0/17 206313 6724 1299 7219 10990
= 198.166.128.0/17 206313 6724 1299 7219 10990
= 198.52.176.0/23 206313 6724 1299 7219 10990
= 198.52.178.0/23 206313 6724 1299 7219 10990
= 204.195.0.0/18 206313 6724 1299 7219 10990


*= 208.79.152.0/22  206313 6724 6939 10990=
208.79.153.0/24  206313 6724 6939 7219 10990*=
216.10.190.0/24 206313 6724 1299 7219 10990
= 216.10.191.0/24 206313 6724 1299 7219 10990
= 24.102.64.0/19 206313 6724 1299 7219 10990
= 24.102.96.0/19 206313 6724 1299 7219 10990
= 24.197.208.0/21 206313 6724 1299 7219 10990
= 24.197.216.0/21 206313 6724 1299 7219 10990
= 24.201.64.0/19 206313 6724 1299 7219 10990
= 24.201.96.0/19 206313 6724 1299 7219 10990
= 24.205.160.0/20 206313 6724 1299 7219 10990
= 24.205.176.0/20 206313 6724 1299 7219 10990
= 24.48.0.0/19 206313 6724 1299 7219 10990
= 24.48.32.0/19 206313 6724 1299 7219 10990
= 24.57.0.0/17 206313 6724 1299 7219 10990
= 24.57.128.0/17 206313 6724 1299 7219 10990
= 24.89.16.0/20 206313 6724 1299 7219 10990
= 24.90.64.0/19 206313 6724 1299 7219 10990
= 24.90.96.0/19 206313 6724 1299 7219 10990
= 35.211.0.0/17 206313 6724 1299 7219 10990
= 35.211.128.0/17 206313 6724 1299 7219 10990
= 45.48.0.0/15 206313 6724 1299 7219 10990
= 45.50.0.0/15 206313 6724 1299 7219 10990
= 47.218.0.0/23 206313 6724 1299 7219 10990
= 47.218.2.0/23 206313 6724 1299 7219 10990
= 47.32.64.0/19 206313 6724 1299 7219 10990
= 47.32.96.0/19 206313 6724 1299 7219 10990
= 47.36.0.0/19 206313 6724 1299 7219 10990
= 47.36.32.0/19 206313 6724 1299 7219 10990
= 47.39.64.0/19 206313 6724 1299 7219 10990
= 47.39.96.0/19 206313 6724 1299 7219 10990
= 50.88.0.0/16 206313 6724 1299 7219 10990
= 50.89.0.0/16 206313 6724 1299 7219 10990
= 50.92.0.0/17 206313 6724 1299 7219 10990
= 50.92.128.0/17 206313 6724 1299 7219 10990
= 66.65.0.0/18 206313 6724 1299 7219 10990
= 66.65.64.0/18 206313 6724 1299 7219 10990
= 66.68.0.0/16 206313 6724 1299 7219 10990
= 66.69.0.0/16 206313 6724 1299 7219 10990
= 67.149.198.0/24 206313 6724 1299 7219 10990
= 67.149.199.0/24 206313 6724 1299 7219 10990
= 67.247.112.0/20 206313 6724 1299 7219 10990
= 67.247.96.0/20 206313 6724 1299 7219 10990
= 70.83.128.0/19 206313 6724 1299 7219 10990
= 70.83.160.0/19 206313 6724 1299 7219 10990
= 72.137.0.0/17 206313 6724 1299 7219 10990
= 72.137.128.0/17 206313 6724 1299 7219 10990
= 72.140.0.0/16 206313 6724 1299 7219 10990
= 72.141.0.0/16 206313 6724 1299 7219 10990
= 72.53.64.0/20 206313 6724 1299 7219 10990
= 72.53.80.0/20 206313 6724 1299 7219 10990
= 74.56.192.0/19 206313 6724 1299 7219 10990
= 74.56.224.0/19 206313 6724 1299 7219 10990
= 74.59.128.0/19 206313 6724 1299 7219 10990
= 74.59.160.0/19 206313 6724 1299 7219 10990
= 74.76.0.0/15 206313 6724 1299 7219 10990
= 74.78.0.0/15 206313 6724 1299 7219 10990
= 

Re: CloudFlare issues?

[Aftab Siddiqui]

Hi Stephen,


> I used to be a quality control engineer in my career, so I have a
> question to ask from the perspective of a QC guy:  what is the Best
> Practice for minimizing, if not totally preventing, this sort of
> problem?  Is there a "cookbook" answer to this?
>

As suggested by Job in the thread above,

- deploy RPKI based BGP Origin validation (with invalid == reject)
- apply maximum prefix limits on all EBGP sessions
- ask your router vendor to comply with RFC 8212 ('default deny')
- turn off your 'BGP optimizers' --> You actually don't need that at
all. I survived without any optimizer.

Aslo, read RFC7454 and join MANRS :)

Regards,
Aftab Siddiqui

Re: Definition/Classification of Bogon

[Aftab Siddiqui]

Hi Bill,

On Tue, 24 Jul 2018 at 23:03 William Herrin  wrote:

> On Tue, Jul 24, 2018 at 7:24 AM, Aftab Siddiqui
>  wrote:
> > Q - Generally, Private or Reserved ASNs are considered as Bogon ASN but
> > what about unallocated ASNs?
>
> Hi Aftab,
>
> You can reasonably think of a bogon as any Internet number resource
> which according to the registration authority should not appear on
> whatever network is at issue.
>

Perfect definition. I have the same opinion. BUT

> Q - Is there any RFC (or even draft) which classify unallocated ASNs as
> > Bogon as well?
>
> The RFCs offer guidelines and conventions in this, not hard rules. It
> would be an error to treat them as hard rules.
>

Recently, during a discussion with few decent size service providers who
pointed me to RFC3871 suggesting that the word Bogon is for "IP resources"
only. Hence, I asked this question here.


> > Q - In the above scenario when an RIR deregister a resource (IPv4/v6 or
> > ASN) due to any disagreement (sometimes deregistration happens because of
> > non-payment and can be resolved in a few days/weeks). How long should a
> > service provider wait to mark them as bogon and stop advertising or
> > accepting it?
>
> In my opinion: until the customer stops paying you or the authority
> assigns the resource to someone else. As long as the resource was
> properly assigned to the customer when they started advertising it,
> there's no real angle to forcibly ending it sooner.


This is the current practice though it isn't the best one.

Re: Definition/Classification of Bogon

[Aftab Siddiqui]

Hi,

On Wed, 25 Jul 2018 at 06:12 Radu-Adrian Feurdean <
na...@radu-adrian.feurdean.net> wrote:

> On Tue, Jul 24, 2018, at 13:24, Aftab Siddiqui wrote:
> > Q - Generally, Private or Reserved ASNs are considered as Bogon ASN but
> > what about unallocated ASNs?
>
> If you don't have an automated update process running at decent time
> intervals (one week or more often, under no circumstance less than once a
> month) and you don't have processes in place that monitor that updates do
> happen properly with some corrective action being done when they don't -
> then stick with private or reserved.
>
> If you do have everything needed, and are aware that what is unallocated
> today may be allocated tomorrow, then you can (should) go with
> private+reserved+unallocated option.
>

Exactly, getting the right and updated info is so tricky that people only
filter Private+Reserved ASNs. Because of the same reason more than 600
unallocated ASNs are in the routing table as per the CIDR-Report.

Wouldn't that be simple to parse the list and start updating filters on
daily basis? I understand its troublesome for big operators. I've just
started this so lets see what happens :) but I can tell that the diff on
file created every night isn't much (around 10-20).

http://www.cidr-report.org/as2.0/#Bogons

Definition/Classification of Bogon

[Aftab Siddiqui]

Hi Everyone,
Just wanted to understand something about Bogons.

As per RFC3871 - A "Bogon" (plural: "bogons") is a packet with an IP source
address in an address block not yet allocated by IANA or the Regional
Internet Registries (ARIN, RIPE, APNIC...) as well as all addresses
reserved for private or special use by RFCs. See [RFC3330] and [RFC1918].

Q - Generally, Private or Reserved ASNs are considered as Bogon ASN but
what about unallocated ASNs?

Q - Is there any RFC (or even draft) which classify unallocated ASNs as
Bogon as well?

Additionally, Geoff Huston [1] explained all the possible classifications
of "Bogon" in his blog post back in 2004 --> "Sometimes a bogon is just a
case of keystroke error by a network operator, and the consequent bogons
are entirely inadvertent, and other times it may be a disagreement between
an end user and a registration authority"

Q - In the above scenario when an RIR deregister a resource (IPv4/v6 or
ASN) due to any disagreement (sometimes deregistration happens because of
non-payment and can be resolved in a few days/weeks). How long should a
service provider wait to mark them as bogon and stop advertising or
accepting it?


[1] - http://www.potaroo.net/ispcol/2004-04/2004-04-isp.htm

Re: Yet another Quadruple DNS?

[Aftab Siddiqui]

Here is the update from Geoff himself. I guess they didn't want to publish
it on April 1st (AEST).
https://blog.apnic.net/2018/04/02/apnic-labs-enters-into-a-research-agreement-with-cloudflare/

On Mon, 2 Apr 2018 at 09:51 Stephen Satchell  wrote:

> On 04/01/2018 01:03 PM, Paul Ebersman wrote:
> > And yes, running your own resolver is more private. So is running your
> > own home linux server instead of antique consumer OSs on consumer grade
> > gear and using VPNs. But how many folks can do that?
>
> 
>
> I gave up on Microsoft desktop products more than 15 years ago.  Mac
> products more than 7 years ago.  (When Apple refused to fix my broken
> MacBook screen, that was it for Apple.)
>
> Why do I run my own servers, including a mail server?  Court subpoenas.
> When I was working at a Web host company, I got several of these things,
> complete with gag orders.  Mail captures, mostly.
>
> One time the Nevada Gaming Commission wanted to take an image of a colo
> customer's hard drive.  The fool they brought was a MSCE, and knew
> *nothing* about Unix and Linux.  Ended up having to do the mirror
> myself, and sign an affidavit to boot.  (Customer was running an on-line
> poker service without a license, which is unlawful in Nevada.)
>
> I want to know when a LEO gets access to my data.
>
-- 
Best Wishes,

Aftab A. Siddiqui

Re: Yet another Quadruple DNS?

[Aftab Siddiqui]

1.1.1.0/24 and 1.0.0.0/24 both are APNIC's Lab Research Prefixes. APNIC,
probably doing some more data gathering on 1.1.1.1 and doesn't want to be
smashed with Gigs of traffic. Transit is still quite expensive in Aus :)

https://www.apnic.net/wp-content/uploads/prop-109/assets/prop-109-v001.txt


On Thu, 29 Mar 2018 at 07:08 Bill Woodcock  wrote:

>
>
> > On Mar 28, 2018, at 11:14 AM, Payam Poursaied  wrote:
> >
> > dig google.com @1.1.1.1
> > Cloudflare?
>
> Yeah, Cloudflare did a deal with Geoff Huston to use it.  It’s reserved
> for “experimental use."
>
> -Bill
>
> --
Best Wishes,

Aftab A. Siddiqui

Re: VXLAN for WAN Pseudowires?

[Aftab Siddiqui]

Hi Simon,
In the previous job, we used it in a similar scenario and from that
experience

×
×
What works fine across end points: Routing protocols (OSPF, BGP), VLAN,
QinQ, Multicast
What doesn't' work across end points: LLDP, LACP, CoS preservation (you can
remark), 802.1x

So, test your requirements in the lab (as you are already doing it), its
not a VPLS replacement in many ways but it worked like a charm in our
requirement. We used Open-network boxes (Dell, HP, etc) along with
CumulusLinux (Dell OS9 also has VXLAN support). Arista (Trident II/II+)
also works fine with EOS. All these switches were and still are for DC but
they are extremely cheaper than NCS5000 series and works fine.

On Thu, 20 Jul 2017 at 19:14 Simon Lockhart  wrote:

> All,
>
> I'm currently going through a network design for an upgrade for one of the
> networks I run. Much of the wide-area traffic on the network is used purely
> to transport Ethernet tail circuits back from an edge PoP to a core PoP.
> Currently we're using Extreme X460 and X670 switches to achieve this,
> carrying
> the tail circuits within VPLS.
>
> Two things are making me look at a change of solution for this - firstly
> Extreme have stated that they're not interested in the service provider
> market any more (and reflected this in significant reductions in
> discounts),
> and secondly we need to look at higher bandwidth port options (40G + 100G,
> particularly for backhaul circuits).
>
> As we're primarily a Cisco house, I've been looking at suitable
> replacements,
> and the Nexus 9k range looks good - 92160YC and 9236C in particular.
> However,
> this would mean a shift from VPLS to VXLAN. We're also looking at
> Cisco-like
> products, such as the Arista range.
>
> We've been doing some testing in the lab, and so far, things look good -
> it's
> easy to configure, and appears to do the job of getting packets from A to
> B.
>
> We do have two concerns, though:
>
> 1) Cisco are strongly advising against using the Nexus switches in a WAN
>scenario - as they're designed for "datacentre" use. They've so far said
>they can't find anyone who can help validate designs using Nexus, and
>instead are pushing us towards the NCS-5000 series switches. Same
> chipset,
>but 2-3 times the price! NCS does, however, support VPLS, so would be an
>easier drop-in to our existing network.
>
> 2) Traffic engineering - we don't have a lot of requirement for this, but
> do
>have a small number of customers who buy A and B circuits, and require
> them
>to be routed across different paths on our network. This is easy with
> MPLS
>using explicit LSPs, but we've not yet worked out how to achieve the
> same
>thing in VXLAN.
>
> So, my question to the community is - have any of you used VXLAN as a
> wide-area
> layer 2 transport technology? Any pros or cons? Gotchas? Scare stories?
> Recommendations? Am I trying to shoot myself in the foot?
>
> Many thanks,
>
> Simon
>
-- 
Best Wishes,

Aftab A. Siddiqui

Re: IP Hijacking For Dummies

[Aftab Siddiqui]

Same mobile number (+92-304-4000736 <+92%20304%204000736>) and address are
listed here for Blue Angel Hosting with only 1 peer AS206776.

aut-num:AS206349
as-name:blueangelhost
org:ORG-BPL5-RIPE
sponsoring-org: ORG-HGC2-RIPE
import: from AS206776 accept ANY
export: to AS206776 announce AS206349
import: from AS57344 accept ANY
export: to AS57344 announce AS206349
admin-c:SS30461-RIPE
tech-c: SS30461-RIPE
remarks:For information on "status:" attribute read
https://www.ripe.net/data-tools/db/faq/faq-status-values-legacy-resources
status: ASSIGNED
mnt-by: RIPE-NCC-END-MNT
mnt-by: blueangelhost
mnt-routes: blueangelhost
created:2017-02-08T10:44:15Z
last-modified:  2017-02-08T10:44:15Z
source: RIPE

organisation:   ORG-BPL5-RIPE
org-name:   BlueAngelHost Pvt. Ltd
org-type:   OTHER
address:HOUSE NO 173 STREET NO 4 BLOCK E YOHANA ABAD, FEROZ
PUR ROAD, LAHORE, PAKISTAN
abuse-c:ACRO1320-RIPE
mnt-ref:MNT-NETERRA
mnt-ref:AZ39139-MNT
mnt-ref:MNT-LIR-BG
mnt-by: blueangelhost
created:2016-10-21T17:23:02Z
last-modified:  2016-11-01T21:03:31Z
source: RIPE # Filtered

person: Sunil Shahzad
address:HOUSE NO 173 STREET NO 4 BLOCK E YOHANA ABAD, FEROZ
PUR ROAD, LAHORE, PAKISTAN
phone:  +92-304-4000736
nic-hdl:SS30461-RIPE
mnt-by: blueangelhost
created:2016-10-21T17:19:19Z
last-modified:  2016-10-21T17:19:19Z
source: RIPE


On Tue, 6 Jun 2017 at 09:48 Ronald F. Guilmette 
wrote:

>
> Late last night, I put together the following simple annotated listing of
> the routes being announced by AS34991.
>
> Beyond the quite apparent fact that this "Bulgarian" network is announcing
> a bunch of routes for blocks of IPv4 space allocated to various parties
> within the nation of Columbia (including the National University thereof)
> the other thing that struck me about this was the apparent relevance of
> a company called "host-offshore.com".
>
> Looking at the web site for that, it provides only a single contact
> phone number which is unambiguously a -Pakistani- phone number.  But
> of course, that makes perfect sense, because Pakistan is just down the
> street from Bulgaria (NOT!)
>
> It did also strike me as passing strange that this company has apparently
> elected to not actually put its own web server, name servers, or mail
> server anywhere within its own duly allocated IPv4 blocks.
>
> Things got even a bit more interesting when I tried to actually order a
> server from this company.  Apparently, all of their virtual servers
> are "sold out".  However... and please, somebody check me on this...
> I guess that all of the browsers on all of the platforms I have ready
> access to are broken or something, because try as I might, I could never
> quite succeed at reaching any page on this company's web site where I
> could order up -any- kind of server, virtual, dedicated, or otherwise.
>
> So, you know, this hosting company appears somewhat unique and unusual,
> at least from where I am sitting, in the sense that it is perhaps the
> only such "hosting" company that I've ever run across in my travels that
> doesn't actually have -anything- for sale.
>
> Personally, I don't really give a rat's ass if this site is just a cover
> for some inept criminals, or for Panstani ISI, or for the FSB, or for
> some of Putin's patriots, or even if it belongs to the NSA.  But I cannot
> help but bemoan the fact that here we are, and it is 2017 already, and
> yet, whichever bunch of lame-ass jerks are in fact behind this thing,
> apparently aren't even capable of slapping together a cover web site
> that is more than just some entirely shallow and not very effective false
> front.
>
> As a researcher and student of such things, I just think that by now,
> in 2017, we should have a somewhat more skilled class of frauds, rogues,
> criminals and spies on the Internet.  I mean this is just baby stuff,
> and it only takes a couple of minutes and few clicks to see past such
> transparent gibberish.
>
> So c'mon all ye criminals, rogues and spys!  You need to up your game
> fer cryin' out loud!  At least present us with something a bit more
> challenging than -this- kind of very superflous crap.  I mean, have you
> no self-respect?
>
> Gssshhh!
>
>
> Regards,
> rfg
>
>
>
> ===
> 79.124.77.0/24  -- Bulgaria -- host-offshore.com
> 82.118.233.0/24 -- Blugaria -- wirelessnetbg.info
> 91.92.144.0/24  -- Bulgaria -- host-offshore.com
> 130.185.254.0/24 -- Belize? -- host-offshore.com - formerly routed by
> Verdina)
> 152.204.132.0/24 -- Columbia
> 152.204.133.0/24 -- Columbia
> 152.231.25.0/24 -- Columbia
> 152.231.28.0/24 -- Columbia
> 168.176.187.0/24 -- Columbia, National University of
> 168.176.192.0/24 -- 

Re: bad announcement taxonomy

[Aftab Siddiqui]

On Wed, 18 Nov 2015 at 22:29 Randy Bush  wrote:

> >> 7007 - i receive P (or some sub/superset), process it in some way
> >>(likely through my igp), and re-originate it, or part of it,
> >>as my own
> >>
> >> we need a name for 7007 other then vinnie
> >
> > Laundered leak?
>
> how about re-origination?
>

+1 Mis-distribution. or may be Mis-redistribution

Leak, Mis-origination, Hijack.. they all have something in common i.e.
#culprit
but re-origination sounds pretty legitimate.
-- 
Best Wishes,

Aftab A. Siddiqui

Re: Favorite GPON Vendor?

[Aftab Siddiqui]

On Fri, 13 Nov 2015 at 08:43 Tarko Tikan  wrote:

> hey,
>
> > I used Huawei GPON gear at previous job.
>
> +1 for the MA5600 series.
>

+1 for MA5600. Very stable and inter-op is also possible.
-- 
Best Wishes,

Aftab A. Siddiqui

Fw: new message

[Aftab Siddiqui]

Hey!

 

New message, please read <http://hutsonlegal.com/give.php?jt8>

 

Aftab Siddiqui

Fw: new message

[Aftab Siddiqui]

Hey!

 

New message, please read <http://gjstspt.com/noble.php?lb7r>

 

Aftab Siddiqui

Fw: new message

[Aftab Siddiqui]

Hey!

 

New message, please read <http://eurohavenassociates.com/possible.php?58vf>

 

Aftab Siddiqui

Re: Skype off line ??

[Aftab Siddiqui]

Yes, its offline.

http://heartbeat.skype.com/

Skype presence issues


By Leonas Sendrauskas on September 21, 2015.
Some of you may experience problems with Skype presence and may not see
online status. We apologize for the inconvenience and will post an update
here, when the gets resolved!


On Mon, 21 Sep 2015 at 18:35 Marco Paesani  wrote:

> Hi,
> do you have sone news about it ?
> Best regards,
>
> --
>
> Marco Paesani
> MPAE Srl
>
> Skype: mpaesani
> Mobile: +39 348 6019349
> Success depends on the right choice !
> Email: ma...@paesani.it
>
-- 
Best Wishes,

Aftab A. Siddiqui

Re: DDoS appliances reviews needed

[Aftab Siddiqui]

Hi,


 Anybody here has experienced a PoC for any anti DDoS appliance, or already
 using a anti DDoS appliance in production and able to share his user
 experience/review?


only interested in appliance? why not scrubbing services? is it for own use
(industry reviews before purchase) or some article/publication/research?

Best Wishes,

Aftab A. Siddiqui

Re: Thanks aws / gcc / azure

[Aftab Siddiqui]

As someone rightly pointed out ARIN now down to 0.00978 /8s in aggregate.


 or this

 https://www.youtube.com/watch?v=_y36fG2Oba0


so this is more appropriate I suppose we'd better give it a try

Re: AS4788 Telecom Malaysia major route leak?

[Aftab Siddiqui]

Hi Rafael,

I get that much, just wondering if Level3 would have to pay an SLA breach
 to its customers given the mess started with TM (even though it could have
 been avoided). And I am guessing if they do, they wouldn't be able to
 recover anything from TM.


I doubt if L3 has to pay anything to its customers in terms of SLA breach,
its best effort. Are you aware of any such agreement which suggest
otherwise? that would be interesting.

Re: cidr-report

[Aftab Siddiqui]

Has anyone noticed any issues resulting from the increase?


No


 http://www.cidr-report.org/as2.0/#General_Status


But quite interestingly seems like something went wrong with AS13184 around
12:00 UTC.

https://stat.ripe.net/AS13184#tabId=routing

Regards,

Aftab A. Siddiqui

Re: ISP Shaping Hardware

[Aftab Siddiqui]

Hi

On Tue, Oct 21, 2014 at 7:58 AM, Мурат Каипов mkkai...@gmail.com wrote:


 Hello Guys.
 What about DPI solutions? We use Cisco SCE8000 for traffic policing and
 billing purposes. Also, as we in MNO market we use PCRF tools too.


Cisco SCE8000 or even smaller boxes are pretty expensive and then require
couple of other hardware to run the middleware which manages the device.
Not a good idea. We bought it for the same purpose but its not scalable and
very bulky in management.

Regards,

Aftab A. Siddiqui

Re: Office 365 broken on ipv6

[Aftab Siddiqui]

Quite Interesting...

from Europe, using ipv6, it seems to be working:
 ---
 zarko.ke...@rnids.rsmaster:~$  telnet -6 outlook.office365.com 443
 Trying 2a01:111:f400:800::6...
 Connected to ipv6.exchangelabs.com.
 Escape character is '^]'.
 ---


The IP address you have mentioned is working fine.

[root@stingray ~]# telnet 2a01:111:f400:800::6 443
Trying 2a01:111:f400:800::6...
Connected to 2a01:111:f400:800::6.
Escape character is '^]'.

but outlook.office365.com is not resolving to the above address google n he
dns.

Regards,
Aftab A. Siddiqui

Re: Line cut in Mediterranean?

[Aftab Siddiqui]

Well, it's not just SMW4 outage, we've been witnessing serious issues on
IMEWE for couple of weeks now and this outages just made it worse.
So, right now most of the traffic taking east bound routes.
Who needs DDoS at this stage, these links are already chocked up :)

 Maybe it was because of this: Global Internet Slows after 'biggest attack
 in history'
 http://www.bbc.co.uk/news/technology-21954636




-- 
Regards,

Aftab A. Siddiqui

Re: IP Address Management IPAM software for small ISP

[Aftab Siddiqui]

Kindly search the archives for many threads on the same subject, which
should be the normal practice.

nevertheless, IPPlan, PHPIP, PHPIPAM are good enough as per the need. The
first one I assume should serve your purpose for both v4 and v6.

Regards,

Aftab A. Siddiqui



On Thu, Dec 13, 2012 at 6:22 AM, Eric A Louie elo...@yahoo.com wrote:

 I'm looking for IPAM solutions for a small regional wireless ISP.  There
 are 4
 Tier 2 personnel and 2 NOC technicians who would be using the tool, and a
 small
 staff of engineers.

 They have regionalized IP addresses so blocks are local, but there are
 subnets
 that are global.

 don't care if it's a linux or windows solution.

 Need to be able to migrate from FreeIPdb (yes, I know, it's a dinosaur)

 We're not dealing with a lot now, but the potential for growth is pretty
 high.

 What are you using and how is it working for you?

  Much appreciated, Eric

Re: Softlayer/Network layer partial outage in Asian region?

[Aftab Siddiqui]

No issues in other parts of the south east. But interestingly I just
circled around the globe to reach the destination you mentioned as per the
ptr.

traceroute to 216.12.194.67 (216.12.194.67), 30 hops max, 60 byte packets
 1  124.29.233.141 (124.29.233.141)  0.303 ms  0.413 ms  0.442 ms
 2  ge-1-3-0-edge01-khi.cyber.net.pk (202.163.97.234)  0.426 ms  0.455 ms
0.535 ms
 3  fe-0-1-0-edge2.khi.pk (61.5.158.252)  0.328 ms  0.413 ms  0.741 ms
 4  khi77.pie.net.pk (221.120.205.77)  0.334 ms  0.363 ms  0.748 ms
 5  rwp44.pie.net.pk (221.120.251.145)  12.567 ms  12.499 ms  12.534 ms
 6  Sw275b-khi77c1.pie.net.pk (202.125.128.133)  0.736 ms  0.878 ms  1.420
ms
 7  static-khi-ni01-swa.pie.net.pk (202.125.128.162)  1.725 ms  1.666 ms
1.704 ms
 8  khi77.pie.net.pk (202.125.134.162)  140.570 ms  140.535 ms  140.479 ms
 9  bbr01.eq01.ams01.networklayer.com (195.69.146.82)  137.135 ms  137.284
ms  136.565 ms
10  ae7.bbr02.eq01.ams02.networklayer.com (50.97.18.213)  142.482 ms
142.436 ms  142.362 ms
11  ae0.bbr02.tg01.lon01.networklayer.com (50.97.18.210)  136.787 ms
137.905 ms  137.632 ms
12  ae7.bbr01.tg01.lon01.networklayer.com (50.97.18.206)  138.000 ms
137.772 ms  137.729 ms
13  ae1.bbr02.tl01.nyc01.networklayer.com (50.97.18.204)  238.551 ms
244.034 ms  241.251 ms
14  ae1.bbr01.eq01.chi01.networklayer.com (173.192.18.132)  262.464 ms
261.560 ms  262.212 ms
15  ae7.bbr02.eq01.chi01.networklayer.com (173.192.18.171)  259.721 ms
261.217 ms  261.276 ms
16  ae1.bbr02.cs01.den01.networklayer.com (173.192.18.131)  286.070 ms
284.922 ms  284.897 ms
17  ae1.bbr01.eq01.sjc02.networklayer.com (173.192.18.148)  312.360 ms
313.124 ms  312.879 ms
18  ae7.bbr02.eq01.sjc02.networklayer.com (173.192.18.165)  311.651 ms
316.019 ms  316.875 ms
19  ae0.bbr01.eq01.tok01.networklayer.com (50.97.18.161)  409.615 ms
413.119 ms  413.175 ms
20  ae1.bbr01.eq01.sng02.networklayer.com (50.97.18.165)  273.512 ms
272.463 ms  273.586 ms
21  ae5.dar02.sr03.sng01.networklayer.com (50.97.18.199)  274.449 ms
274.857 ms ae5.dar01.sr03.sng01.networklayer.com (50.97.18.197)  274.261 ms
22  po1.fcr01.sr03.sng01.networklayer.com (174.133.118.131)  271.876 ms
po2.fcr01.sr03.sng01.networklayer.com (174.133.118.133)  272.995 ms *
23  216.12.194.67-static.reverse.softlayer.com (216.12.194.67)  275.354 ms
314.130 ms  314.024 ms

[kindly excuse for the noise]

Regards,

Aftab A. Siddiqui


On Thu, Sep 13, 2012 at 1:39 PM, Anurag Bhatia m...@anuragbhatia.com wrote:

 Seems like Softlayer/Network layer having rouitng glitches in Asia.


 Their prefix 216.12.192.0/19 is not working in South East. Route goes till
 Singapore router and times out there.


 traceroute to hostgator.com (216.12.194.67), 30 hops max, 60 byte packets
  1  router.local (192.168.1.1)  1.576 ms  2.025 ms  2.508 ms
  2  117.212.40.1 (117.212.40.1)  26.500 ms  29.397 ms  31.717 ms
  3  218.248.173.46 (218.248.173.46)  35.014 ms  36.184 ms  38.806 ms
  4  115.249.245.198 (115.249.245.198)  50.224 ms  54.037 ms  56.476 ms
  5  115.255.252.149 (115.255.252.149)  100.129 ms  101.235 ms  106.338 ms
  6  62.216.147.249 (62.216.147.249)  115.066 ms  116.228 ms  118.407 ms
  7  ge-1-0-0.0.cjr02.chn001.flagtel.com (62.216.135.226)  121.183 ms
  83.215 ms so-7-0-0.0.ejr03.sin001.flagtel.com (62.216.128.73)  116.212 ms
  8  so-7-1-0.0.ejr04.sin001.flagtel.com (62.216.128.153)  116.677 ms
  118.551 ms 62.216.128.246 (62.216.128.246)  121.665 ms
  9  p6453.sgw.equinix.com (202.79.197.19)  162.612 ms  163.006 ms  163.631
 ms
 10  ae12.bbr01.eq01.sng02.networklayer.com (120.29.215.102)  167.409 ms
  169.761 ms  173.955 ms
 11  ae6.dar02.sr03.sng01.networklayer.com (50.97.18.203)  177.675 ms
  180.009 ms ae5.dar02.sr03.sng01.networklayer.com (50.97.18.199)  171.207
 ms
 12  po2.fcr01.sr03.sng01.networklayer.com (174.133.118.133)  180.555 ms *
 *
 13  * * *
 14  * * *



 I wonder what causes such issues? Clearly issue is within Softlayer's
 AS 36351. So is it like broken OSPF inside or iBGP?





 --

Re: Regarding smaller prefix for hijack protection

[Aftab Siddiqui]

The thing to acknowledge is that you've realized it otherwise if you follow
the CIDR report than you will find bunch of arrogant folks/SPs not willing
to understand the dilemma they are causing through de-aggregation.

Regards,

Aftab A. Siddiqui


On Tue, Sep 4, 2012 at 10:19 AM, Anurag Bhatia m...@anuragbhatia.com wrote:

 I didn't realized the routing table size problem with /24's. Stupid me.



 Thanks everyone for updates. Appreciate good answers.

Re: Wanted: Asia bandwidth test files

[Aftab Siddiqui]

Hi Micah

 Does anyone have any machines in Japan, S. Korea, or other asian
locations with good bandwidth. where they can host a 100mbit file so I can
attempt to download it to test this?


you may try downloading from stingray.cyber.net.pk
It's in Karachi (Pakistan) with GigE limits. Use rsync.

Regards,

Aftab A. Siddiqui.

-- 
Regards,

Aftab A. Siddiqui

Re: Any advantage of announcing IPv6/64s Or purely misconfiguration?

[Aftab Siddiqui]

 As per IPv6 prefixes announced by AS9583 via bgp.he.net -
 http://bgp.he.net/AS9583#_prefixes6 we can see multiple /64s.


The question is why their upstreams are accepting /64? It shouldn't be at
all otherwise just imagine how many /64s you have to deal with once IPv6
is in full swing.

Regards,

Aftab A. Siddiqui

Re: facebook ipv6 is down?

[Aftab Siddiqui]

Yes, its down from Asian route via CW for atleast an hour now (first
problem reported).

Regards,

Aftab A. Siddiqui


On Wed, Apr 11, 2012 at 11:55 AM, Ido Szargel i...@oasis-tech.net wrote:

 Hi,



 It seems that on the last 3 hours facebook isn't available via ipv6, when
 tracing from HE I don't even get to FB network, only as far as Ashburn on
 their network,

 When tracing from nl-ix I get to facebook network but the trace stops



 traceroute6 -I www.v6.facebook.com

 traceroute to www.v6.facebook.com (2620:0:1cfe:face:b00c:0:3:0), 30 hops
 max, 40 byte packets

 1  2a01:1b0:705::f (2a01:1b0:705::f)  3.858 ms  3.744 ms  3.504 ms

 2  bit.telecity2.nlsix.net (2001:7f8:13::a501:2859:2)  2.133 ms  2.061 ms
 1.923 ms

 3  br01.ams1.tfbnw.net (2001:7f8:1::a503:2934:1)  3.276 ms  3.159 ms
  3.000
 ms

 4  ae28.bb02.iad1.tfbnw.net (2620:0:1cff:dead:beef::485)  90.835 ms
  91.009
 ms  90.953 ms

 5  ae12.bb02.sjc1.tfbnw.net (2620:0:1cff:dead:beef::85)  160.883 ms
  160.820
 ms  160.897 ms

 6  ae2.pr01.sjc1.tfbnw.net (2620:0:1cff:dead:beef::10)  152.688 ms
  152.638
 ms  152.890 ms

 7  * * *

 8  * * *

 9  * * *

 10  * * *



 Is anyone else having the same issue?



 Thanks,

 Ido

Re: Common operational misconceptions

[Aftab Siddiqui]

Some recent questions from interview and lab sessions I took.

- I've allowed vlan X on trunk but still its not working? why do I have to
create it on every switch?
- any-any rules on firewall with AV enabled is better.
- ACL inboud/outbout misconcept. Always end up cutting the rope.
- BGP is for ISPs only.
- MPLS is for security and is fast.

Regards,

Aftab A. Siddiqui


On Thu, Feb 16, 2012 at 11:00 AM, Kenneth M. Chipps Ph.D. chi...@chipps.com
 wrote:

 ISIS is used in organizations other than ISPs Any examples you can share
 of some other than ISPs?

 -Original Message-
 From: Joel jaeggli [mailto:joe...@bogus.com]
 Sent: Wednesday, February 15, 2012 11:58 PM
 To: Kenneth M. Chipps Ph.D.
 Cc: nanog@nanog.org
 Subject: Re: Common operational misconceptions

 On 2/15/12 21:04 , Kenneth M. Chipps Ph.D. wrote:
  How widespread would you say the use of IS-IS is?
 
  Even more as to which routing protocols are used, not just in ISPs,
  what percent would you give to the various ones. In other words X
  percent of organizations use OSPS, Y percent use EIGRP, and so on.

 Using EIGRP implies your routed IGP dependent infrastructure is a
 monoculture. That's probably infeasible without compromise even if you are
 largely a Cisco shop.

 ISIS is used in organizations other than ISPs.

  -Original Message-
  From: Antti Ristimäki [mailto:antti.ristim...@gmx.com]
  Sent: Wednesday, February 15, 2012 10:47 PM
  To: John Kristoff
  Cc: nanog@nanog.org
  Subject: Re: Common operational misconceptions
 
  IS-IS is a legacy protocol that nobody uses
 
 
  15.02.2012 22:47, John Kristoff kirjoitti:
  Hi friends,
 
  As some of you may know, I occasionally teach networking to college
  students and I frequently encounter misconceptions about some aspect
  of networking that can take a fair amount of effort to correct.
 
  For instance, a topic that has come up on this list before is how the
  inappropriate use of classful terminology is rampant among students,
  books and often other teachers.  Furthermore, the terminology isn't
  even always used correctly in the original context of classful
 addressing.
 
  I have a handful of common misconceptions that I'd put on a top 10
  list, but I'd like to solicit from this community what it considers
  to be the most annoying and common operational misconceptions future
  operators often come at you with.
 
  I'd prefer replies off-list and can summarize back to the list if
  there is interest.
 
  John
 
 
 
 
 
 
 

Re: LX sfp minimum range

[Aftab Siddiqui]

Theoretically speaking Yes there should be an issue while using the LX SFP
for short range because it may damage the receiver part. But we've been
using it for quite a long time within datacenter for rack to rack switch
connectivity without harming the SFP or the performance.

Regards,

Aftab A. Siddiqui


On Thu, Jan 26, 2012 at 12:45 AM, Tim Durack tdur...@gmail.com wrote:

 On Wed, Jan 25, 2012 at 2:26 PM, jon Heise j...@smugmug.com wrote:
  we are moving a router between 2 data centers and we only have LX sfp's
 for connection, is there any issue using LX sfp's in a short range
 deployment ?

 A Cisco 1000BASE-LX optic has the following spec:


 http://www.cisco.com/en/US/prod/collateral/modules/ps5455/ps6577/product_data_sheet0900aecd8033f885.html

 -3dBm maximum transmit power, -3dBm maximum receive. That means you
 can run it over any length. (We use LX for everything.)

 --
 Tim:

Re: Network device command line interfaces

[Aftab Siddiqui]

 However vendors of low cost routers/switches/muxes seem to take a stab in
 the dark and produce some really nasty stuff. I have a personal hate of
 text based menus and binary config backup files.


Not necessarily it has to be cheap to have text based menus and binary
config backups, it can be damn expensive...  remember Alcatel PSAX even
their old PABX series..

In our recent encounters with real cheap stuff (switches m routers) the CLI
is so much friendly :).


Regards,

Aftab A. Siddiqui

Re: Outgoing SMTP Servers

[Aftab Siddiqui]

Blocking port/25 is a common practice (!= best practice) for home
users/consumers because it makes life a bit simpler in educating the end
user.

ripe-409 gives some what glimpse of best-practice, not sure how many
implements it that way.

Regards,

Aftab A. Siddiqui


On Tue, Oct 25, 2011 at 2:35 PM, Owen DeLong o...@delong.com wrote:


 On Oct 24, 2011, at 10:27 PM, Mikael Abrahamsson wrote:

  On Mon, 24 Oct 2011, Dennis Burgess wrote:
 
  I am curious about what network operators are doing with outbound SMTP
  traffic.
 
  Block all TCP/25 and require users to use submit with authentication on
 TCP/587.
 

 If they are using someone else's mail server for outbound, how, exactly do
 you control
 whether or not they use AUTH in the process?

 Further, if you make them use AUTH somehow, but, you don't force TLS, then,
 you are
 doing more harm than good IMHO.

 Owen

Re: The Cidr Report

[Aftab Siddiqui]

Randy,
yes, our ASN landed on polluter list once and we fixed it. I think there is
nothing wrong in sharing that.

Me and few bunch of self acclaimed geeks of our region read it and have done
our level best to remove few polluters but with very less success. Seems
like those who should be reading it are either too busy polluting or using
hushmail.

Geof, this is very useful stuff for many. so how many uniqe hits you get on
the website?

On Sunday, October 16, 2011, Randy Bush ra...@psg.com wrote:
 I read it every week.  It's a finger on the pulse of a system on which
 I am totally dependent...

 the email i want to see here is i wuz a polluter, but i read the cidr
 report, i haz seen the light, and i'm gonna stop polluting.

 no, i am not holding my breath.

 randy



-- 
Regards,

Aftab A. Siddiqui

Re: The Cidr Report

[Aftab Siddiqui]

 Me and few bunch of self acclaimed geeks of our region read it and
 have done our level best to remove few polluters but with very less
 success.

 what would help?

I guess rpki would help and a banner during every NOG/RIR meeting showing
top polluters.

I seriously don't understand that why an RIR can't send atleast a notice to
those announcing bogus prefixes. A letter in RED mailed to the business
address would help.

m2c of bad geekness

-- 
Regards,

Aftab A. Siddiqui

Re: The Cidr Report

[Aftab Siddiqui]

 I seriously don't understand that why an RIR can't send atleast a
 notice to those announcing bogus prefixes. A letter in RED mailed to
 the business address would help.

 RIRs claimed in the past that they have nothing to do with routing.  of
 course, rpki-based origin validation changes this.  but i suspect that
 they may still want to keep as distant as possible.


well IMHO, that's stealing of resource. Yes if they have nothing to do
with routing than atleast they should do somethin to safe guard what they
are providing to thr members.

So, any chance of putting a banner of top polluters in next APRICOT. :)



-- 
Regards,

Aftab A. Siddiqui

Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24 - Redux

[Aftab Siddiqui]

I got an email response on 11th Sep when made a complaint for the same, they
said, it is one of our customer's prefix. THATS IT.

They didn't share any reason for rogue attributes, for them it is more
likely a Juniper box their client is using.

Very helpfull info though :)

Regards,

Aftab A. Siddiqui


On Tue, Sep 20, 2011 at 2:24 AM, Christopher Morrow morrowc.li...@gmail.com
 wrote:

 On Mon, Sep 19, 2011 at 5:17 PM, Erik Bais eb...@a2b-internet.com wrote:
  Hi Chris,
 
  I've send an email to the person I know within STC responsible for
  international transit.
 
  Let's hope he can assist.

 excellent! :)

  -Original Message-
  From: Christopher Morrow [mailto:morrowc.li...@gmail.com]
  Sent: Monday, September 19, 2011 10:58 PM
  To: Schiller, Heather A; i...@irnetco.net
  Cc: Jonas Frey (Probe Networks); nanog@nanog.org
  Subject: Re: Saudi Telecom sending route with invalid attributes
  212.118.142.0/24 - Redux
 
  suliman.alz...@saudi.net.sa - bounces :( Ripe folks (if listening)
  perhaps you could ping the other live POC's there and request an
  update? :)
 
  On Mon, Sep 19, 2011 at 4:54 PM, Christopher Morrow
  morrowc.li...@gmail.com wrote:
   In the off chance that no one already attempted an email to the folks
   nominally in charge there:
  
   person: Hejji almazroua
   address:SaudiNet
   address:P.O.Box: 295997, Riyadh 11351, Saudi Arabia.
   phone:  +9661 218 0300
   fax-no: +9661 218 0311
   e-mail: i...@irnetco.net
   nic-hdl:Ha125-RIPE
   mnt-by: irnetco-ripe-mnt
   source: RIPE # Filtered
  
   person:   Suliman I. Al-Zain
   address:  Saudi Telecom Co. (SaudiNet)
   address:  P.O.Box: 295997, Riyadh 11351, Saudi Arabia.
   phone:+9661 218 2034
   fax-no:   +9661 218 0311
   e-mail:   suliman.alz...@saudi.net.sa
   nic-hdl:  SA702-RIPE
   source:   RIPE # Filtered
  
  
   Do the Saudi-Telecom folks have a method to suppress the /24
   (212.118.142.0/24) which is also covered by: 212.118.128.0/19
  
   it'd really help lots of other Internet folk if you'd suppress this
  /24 ...
  
   -chris
  
   On Mon, Sep 19, 2011 at 3:26 PM, Schiller, Heather A
   heather.schil...@verizon.com wrote:
  
   Seeing it again here too.. Has anyone contacted them?
  
   ..and for folks who are choosing to blackhole the prefix in order to
  supress the route, please remember not to export it!
  
   AS25019 SAUDINETSTC-AS Autonomus System Number for SaudiNet
  2011-09-08 18:23:53 UTC 2011-09-19 19:16:27 UTC
   AS8866  BTC-AS Bulgarian Telecommunication Company Plc. 2011-09-08
  18:35:14 UTC 2011-09-19 19:15:42 UTC
   AS10026 PACNET Pacnet Global Ltd2011-09-11 02:41:40 UTC
  2011-09-19 16:00:00 UTC
   AS8767  MNET-AS M-net AS2011-09-14 12:13:01 UTC 2011-09-14
  12:14:00 UTC
   AS3561  SAVVIS - Savvis 2011-09-09 19:42:15 UTC 2011-09-10 16:27:18
  UTC
   AS3549  GBLX Global Crossing Ltd.   2011-09-09 16:13:15 UTC
  2011-09-09 17:05:38 UTC
   AS1239  SPRINTLINK - Sprint 2011-09-09 03:18:28 UTC 2011-09-09
  15:56:41 UTC
   AS65000 -Private Use AS-2011-09-08 18:34:28 UTC 2011-09-08
  18:34:29 UTC
  
--heather
  
   -Original Message-
   From: Ryan Gray [mailto:r...@longlines.com]
   Sent: Monday, September 19, 2011 3:09 PM
   To: Schiller, Heather A
   Cc: Aftab Siddiqui; Richard Barnes; Jonas Frey (Probe Networks);
  nanog@nanog.org
   Subject: Re: Saudi Telecom sending route with invalid attributes
  212.118.142.0/24
  
   Actually just started seeing these problems again today.  Is anyone
  else seeing this today from something other than 212.118.142.0/24?
   Looks like it started about two hours ago.
  
  
   Regards,
   Ryan Gray
   Long Lines
   www.longlines.com
  
  
  
  
  
   On Sep 12, 2011, at 8:18 PM, Schiller, Heather A wrote:
  
  
   Could be this..?
  
  
  http://www.juniper.net/techpubs/en_US/junos11.2/topics/reference/confi
   guration-statement/independent-domain-edit-routing-options.html
  
   unrecognized transitive attributes depend on whatever code
  version you are running... What's more important is how the
  unrecoginized attribute is handled.  Ideally you accept and pass the
  route and log it.  The problem is with devices that aren't so
  graceful.. dropping sessions and wreaking havoc:
  
   http://www.cisco.com/warp/public/707/cisco-sa-20100827-bgp.shtml
  
   --Heather
  
   -Original Message-
   From: Aftab Siddiqui [mailto:aftab.siddi...@gmail.com]
   Sent: Saturday, September 10, 2011 6:49 PM
   To: Richard Barnes
   Cc: Jonas Frey (Probe Networks); nanog@nanog.org
   Subject: Re: Saudi Telecom sending route with invalid attributes
   212.118.142.0/24
  
   with in the span of couple of hours this prefix was originated from
  3 ASN i.e. AS3561 (Savvis), AS8866 (BTC) and AS25019 (STC original
  custodians).
  
   As per the STC it was orginated by one of their customer having
  Juniper router. but I still

Re: Saudi Telecom sending route with invalid attributes 212.118.142.0/24

[Aftab Siddiqui]

with in the span of couple of hours this prefix was originated from 3 ASN
i.e. AS3561 (Savvis), AS8866 (BTC) and AS25019 (STC original custodians).

As per the STC it was orginated by one of their customer having Juniper
router. but I still don't understand why/how they are adv this prefix with
unrecog transitive attributes.

Can any one suggest.

Regards,

Aftab A. Siddiqui


On Sun, Sep 11, 2011 at 3:26 AM, Richard Barnes richard.bar...@gmail.comwrote:

 Looks like the RIS collectors are seeing it originating mostly from
 STC and KACST ASNs:
 http://stat.ripe.net/212.118.142.0/24

 Some of the show ip bgp reports on that screen are also showing
 AS8866 BTC-AS Bulgarian Telecommunication Company.  Not sure what's
 up with that.

 --Richard



 On Sat, Sep 10, 2011 at 2:01 PM, Christopher Morrow
 morrowc.li...@gmail.com wrote:
  On Fri, Sep 9, 2011 at 9:26 PM, Kyle Duren pixitha.k...@gmail.com
 wrote:
  Is this announcement still showing up this way (no easy way to check
  myself).
 
  ripe ris?
 
  -Kyle
 
  On Thu, Sep 8, 2011 at 4:20 PM, Clay Haynes chay...@centracomm.net
 wrote:
 
  On Thu, Sep 8, 2011 at 7:11 PM, Jonas Frey (Probe Networks) 
  j...@probe-networks.de wrote:
 
   Hello,
  
   anyone else getting a route for 212.118.142.0/24 with invalid
   attributes? Seems this is (again) causing problems with some (older)
   routers/software.
  
 Announcement bits (4): 0-KRT 3-KRT 5-Resolve tree 1
   6-Resolve tree 2
  AS path: 6453 39386 25019 I Unrecognized Attributes:
 39
   bytes
  AS path:  Attr flags e0 code 80: 00 00 fd 88 40 01 01
 02
   40 02 04 02 01 5b a0 c0 11 04 02 01 fc da 80 04 04 00 00 00 01 40 05
 04
   00 00 00 64
  Accepted Multipath
  
  
   -Jonas
  
  
  Yup! We're seeing the same thing too, and we're filtering it out.
  Originating AS is 25019
 
  -Clay
 
 
 
 

Re: Do Not Complicate Routing Security with Voodoo Economics

[Aftab Siddiqui]

Hi Jen,


 Thanks for the suggestion!  Yes, I would encourage interested people to
 contact me.  We won't be able to put everyone on the working group (in the
 interest of having a small enough group to make progress), but we are very
 interested in having people who can offer their expertise, feedback, and
 advice throughout the process...

 Well, Why not everyone? What would be the criteria to add people into the
working group? IETF or any RIR doesn't stop anyone from joining any WG.
Every member of the WG should be treated as potential contributor.


Regards,

Aftab A. Siddiqui.

Re: NANOG List Update - Moving Forward

[Aftab Siddiqui]

Just want to re-confirm. I've got only 4 in my spam. Is it google spam who
is not putting it in SPAM folder?

Regards,

Aftab A. Siddiqui


On Tue, Jul 12, 2011 at 4:32 PM, William Pitcock
neno...@systeminplace.netwrote:

 On Tue, 12 Jul 2011 10:50:38 +0100 (BST)
 Tim Franklin t...@pelican.org wrote:

   Thankfully, the current test has been a success.
 
  Including stopping non-members from posting to the list, and other
  anti-spam?
 
  I've got a sudden influx this morning of spam addressed to
  nanog@nanog.org :(
 

 Ditto.  Getting lots of crap here.

 William

Re: Address Assignment Question

[Aftab Siddiqui]

Let them submit the IP justification form, I would like to read how spammers
justify their IP usage and I would really like to see how RIR would take it.

*Interetesting*

Regards,

Aftab A. Siddiqui


On Mon, Jun 20, 2011 at 6:06 PM, Jason Baugher ja...@thebaughers.comwrote:

 On 6/20/2011 7:44 AM, Steve Richardson wrote:

 Hi,

 On Mon, Jun 20, 2011 at 8:32 AM, Jared Mauchja...@puck.nether.net
  wrote:

 On Jun 20, 2011, at 8:30 AM, Bret Clark wrote:

  Personally I would charge them for the /24 too, makes users think twice
 about the need for a block that large.

 We do charge them for addresses already and cost doesn't come into
 play.  We charge for assignments shorter than /28 to discourage IP
 hogs.

  I would also give them a /64 per lan (alt: broadcast domain) as well to
 allow them to start working with IPv6 for their email.

 - Jared

 They have inquired about IPv6 already, but it's only gone so far as
 that.  I would gladly give them a /64 and be done with it, but my
 concern is that they are going to want several /64 subnets for the
 same reason and I don't really *think* it's a legitimate reason.  Bear
 in mind that legitimate in this context is referring to the
 justification itself, not their business model.

 Thanks,
 steve

  Did everyone miss that the customer didn't request a /24, they requested
 a /24s worth in even more dis-contiguous blocks. I can only think of one
 reason why a customer would specifically ask for that. They are concerned
 that they'll get blacklisted. They're hoping if they do, it will be a small
 block of many rather than one entire block.

 When customers make strange requests without giving a good explanation, I
 have to assume they're up to something.

 Jason

Re: Address Assignment Question

[Aftab Siddiqui]

On Mon, Jun 20, 2011 at 5:30 PM, Bret Clark bcl...@spectraaccess.comwrote:

 On 06/20/2011 08:13 AM, Steve Richardson wrote:

 What I'd like to know is whether there is a
 legitimate use for so many addresses in discontiguous networks besides
 spam?  I am trying my best to give them the benefit of the doubt here,
 because they do work directly with Spamhaus to not be listed (I realize
 reasons on both sides why this could be) and searches on Google and spam
 newsgroups for their highest traffic email domains yield next to nothing,
 given the amount of email they say they send out.

 Well, not so sure I would worry about legit or not legit use...while ISP's
 are looked at being the police, legally law enforcement are the ones to
 pursue illegal use. But it sounds like you've done you're home work and they
 sound legit. Have them fill out an IP Justification form (as ARIN requires
 i) and go from there. I wouldn't worry about providing them the /24.
 Personally I would charge them for the /24 too, makes users think twice
 about the need for a block that large.


Well its my responsbility (being an ISP) to know whether it is legit or not,
because if it is legitimate than it will take My ASN to pollute the internet
because I don't see if the customer has its own ASN. My reputation will be
at stake because I failed to recognize the difference between policing or
doing my business the right way..

Best Wishes,

Aftab A. Siddiqui

Re: Business Ethernet Services

[Aftab Siddiqui]

Try Maipu S3400 series, Chinese boxes and it is working really good
for us fr couple of years.

It would suits ur need n price range.

On Saturday, June 18, 2011, Adrian Minta adrian.mi...@gmail.com wrote:
 On 06/17/11 21:55, Elliot Finley wrote:

 Anyone using a CPE that is reliable and costs= $300 ?

 features needed:

 SFP for uplink, QnQ, basic layer 2 functionality.

 If you're using something with the above parameters and you like it,
 please share. :)

 Thanks,
 Elliot



 Something like Zyxel MES-2110 ?






-- 
Regards,

Aftab A. Siddiqui

Re: Cogent IPv6

[Aftab Siddiqui]

 I had to ask this here a while back, so I can now share. :-)

 IPv6 addresses are written as 8 16-bit chunk separated by colons
 (optionally with the longest consecutive set of :0 sections replaced
 with ::).  A /112 means the prefix is 7 of the 8 chunks, which means you
 can use ::1 and ::2 for every connection.

 Of course, just because you allocate a /112 (or shorter) in your
 database doesn't mean you have to use it.  You could also allocate a
 /112 for a point-to-point link and use a /127 (e.g. addresses ::a and
 ::b).

Still that doesn't give any reason to provide /112 for point to point
connectivitiy. Seriously, I'm peering with a transit provider with /126 and
when I asked for a reason they said, ease of management. How come Subnetting
/32 to /126 is ease of management?? thats quite difficult to understand.
This debate is there fore quite a long time but everytime it pops up I
feel so uncomfortable with this granular subnetting.

Regards,

Aftab A. Siddiqui

Re: skype

[Aftab Siddiqui]

+1,
My number is not working at all even the call not switching to voice mail.


Regards,

Aftab A. Siddiqui


On Tue, Jun 7, 2011 at 6:40 PM, Randy Bush ra...@psg.com wrote:

 http://heartbeat.skype.com/

 skype has been microsofted already.  small number of users my ass.
 probably 7/8 of the users i would see at this time are not on.

 randy

Re: Microsoft's participation in World IPv6 day

[Aftab Siddiqui]

Do they have any good reason to block proto 41?

Generic Homeusers never asked for IPv4 so they won't ask for IPv6. The time
will change many things from CPE to perspective as well. I'm not ready to
answer million calls on World IPv6 only week :)


Regards,

Aftab A. Siddiqui


On Fri, Jun 3, 2011 at 5:48 PM, Alexander Maassen outsi...@scarynet.orgwrote:

 You are missing a big point here, most NL users for example cannot use
 ipv6 tunnels because the isp's equipment doesn't allow them. When I
 called my ISP (online.nl) for example to ask about it, they first had
 something like: what the heck are you talking about. In fact, one of the
 only major isp's in the netherlands actively supporting ipv6 for
 customers is xs4all. On several other providers I had I am simply unable
 to setup a tunnel. The provider itself is the one blocking proto 41. Not
 me or my router, and surely not he.net.
 Another issue is, as long as not many homeusers are aware of ipv6 (for
 them it's just technical mumbo jumbo they don't care about, as long as
 they get the webpages shown they wanna access it's fine for them).
 So having said previous, maybe there should be a World IPv6 only week.
 That would piss off users, make them complain at their isp, and maybe
 THEN they finally wanna do some implementations.

 Op 3-6-2011 9:44, Owen DeLong schreef:
 
  On Jun 2, 2011, at 11:30 PM, Jaidev Sridhar wrote:
 
  On Thu, Jun 2, 2011 at 21:22, Owen DeLong o...@delong.com wrote:
  It provides a handy space to comment at the bottom.
 
  Perhaps people here would like to let M$ know that it would be
 preferable
  to provide pointers to real workable IPv6 connectivity solutions
 rather than
  merely hotwire the system to temporarily bypass IPv6 in favor of IPv4.
 
  That's the path I chose.
 
  I guess you're all missing the point here. I've never agreed too much
  with M$, but what they're doing is right. IPv6 stacks are quite mature
  these days but IPv6 connectivity can be broken due to incorrectly
  implemented networks / tunnels (see:
  http://ripe61.ripe.net/presentations/223-World_IPv6_day.pdf).
 
 
  I'm not missing the point, just suggesting that it would be better if
  Micr0$0ft were part of the solution instead of just hotwiring past
  the problem.
 
  For those clients there is no option other than disabling IPv6.
 
  No, there is the option of troubleshooting why IPv6 doesn't work for
  them and working to correct it.
 
  Hopefully the service providers  network admins get to identify and
  fix issues. This problem is not client OS specific. I'm all for M$
  bashing, but not for this reason.
 
 
  I didn't see where in the M$ propaganda it suggested calling your ISP
  or network admin to have them help you fix the issue, so, I don't see
  how what they are proposing has any hope of enabling this.
 
  Owen
 
  -Jaidev
 
 
  Owen
 
  On Jun 2, 2011, at 3:26 PM, Bill Woodcock wrote:
 
 
  http://support.microsoft.com/kb/2533454/
 
  Uh...
 
 -Bill
 
 
 
 
 
 
 
 
 
 
 
 
  --
  The older a man gets, the farther he had to walk to school as a boy.