Charter FYI - FW: [SANOG] Reliance Jio (AS55836) origating a /16 belonging to Charter (AS20115)

[Ca By]

On Sunday, July 3, 2016, Jay R. Ashworth > wrote:

> - Original Message -
> > From: "Suresh Ramasubramanian" 
>
> > On 03/07/16, 9:05 PM, "NANOG on behalf of Suresh Ramasubramanian"
> >  wrote:
> >
> >> Is anyone from Jio network engineering team on this list?
> >> I see AS55836 is originating  47.35.0.0/16 while the pool belongs to
> >> Charter. There's even /18 slices of the pool being announced by Charter.
> >
> > Acked / fixed in record time actually
>
> So carriers *still* aren't filtering incoming BGP announcements from
> subordinate carriers for sanity, huh?
>
>
Correct.

I am trying to chase down a hijack right now. AS12389 is passing a bad
route to Cogent, HE, GTT, and Hibernian. Email to noc@he got a quick fix,
still waiting on others.

Would have been nice for any of those folks to have used the correctly
published IRR, RPKI, or whois info instead of accepting and passing bad
routes.


Cheers,
> -- jr 'yes, yes, I know, but even still' a
> --
> Jay R. Ashworth  Baylink
> j...@baylink.com
> Designer The Things I Think   RFC
> 2100
> Ashworth & Associates   http://www.bcp38.info  2000 Land
> Rover DII
> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647
> 1274
>

Re: Charter FYI - FW: [SANOG] Reliance Jio (AS55836) origating a /16 belonging to Charter (AS20115)

[Jay R. Ashworth]

- Original Message -
> From: "Suresh Ramasubramanian" 

> On 03/07/16, 9:05 PM, "NANOG on behalf of Suresh Ramasubramanian"
>  wrote:
> 
>> Is anyone from Jio network engineering team on this list?
>> I see AS55836 is originating  47.35.0.0/16 while the pool belongs to
>> Charter. There's even /18 slices of the pool being announced by Charter.
> 
> Acked / fixed in record time actually

So carriers *still* aren't filtering incoming BGP announcements from 
subordinate carriers for sanity, huh?

Cheers,
-- jr 'yes, yes, I know, but even still' a
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: Charter FYI - FW: [SANOG] Reliance Jio (AS55836) origating a /16 belonging to Charter (AS20115)

[Suresh Ramasubramanian]

On 03/07/16, 9:05 PM, "NANOG on behalf of Suresh Ramasubramanian" 
 wrote:

> Is anyone from Jio network engineering team on this list? 
> I see AS55836 is originating  47.35.0.0/16 while the pool belongs to 
> Charter. There's even /18 slices of the pool being announced by Charter.

Acked / fixed in record time actually

Charter FYI - FW: [SANOG] Reliance Jio (AS55836) origating a /16 belonging to Charter (AS20115)

[Suresh Ramasubramanian]

 

 

From: sanog  on behalf of Anurag Bhatia 

Date: Sunday, 3 July 2016 at 8:46 PM
To: SANOG 
Subject: [SANOG] Reliance Jio (AS55836) origating a /16 belonging to Charter 
(AS20115)

 

Hello everyone! 

 

 

Is anyone from Jio network engineering team on this list? 

 

 

I see AS55836 is originating  47.35.0.0/16 while the pool belongs to Charter. 
There's even /18 slices of the pool being announced by Charter. 

 

 

 

>From Oregon route-views: 

 

 

route-views>sh ip bgp 47.35.0.0/16 long | exclude 20115

BGP table version is 18764390, local router ID is 128.223.51.103

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

  r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

  x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

 

 Network  Next HopMetric LocPrf Weight Path

 *   47.35.0.0/16 195.208.112.1610 3277 3267 174 
64049 55836 i

 *217.192.89.50  0 3303 6762 64049 
55836 i

 *212.66.96.126  0 20912 1267 64049 
55836 i

 *162.243.188.2  0 393406 6453 6762 
64049 55836 i

 *192.241.164.4  0 62567 2914 174 
64049 55836 i

 *129.250.0.11  1007 0 2914 174 64049 
55836 i

 *104.192.216.1  0 46450 174 64049 
55836 i

 *202.93.8.242   0 24441 3491 3491 
174 64049 55836 i

 *66.59.190.221  0 6539 577 6762 
64049 55836 i

 *144.228.241.130 80 0 1239 174 64049 
55836 i

 *207.172.6.20 0 0 6079 3356 174 
64049 55836 i

 

 

 

 

Does not seem good! 

 

-- 

 

 

Anurag Bhatia

anuragbhatia.com

___ sanog mailing list 
sa...@sanog.org https://lists.sanog.org/mailman/listinfo/sanog

Re: IPv6 deployment excuses

[Tore Anderson]

* Mark Tinka

> I understand your points - to your comment, my question is around
> whether it is cheaper (for you) to just run IPv6 in lieu of IPv6 and
> IPv4.

We've found that it is. IPv6-only greatly reduces complexity compared to
dual stack. This means higher reliability, lower OpEx, shorter recovery
time when something does go wrong anyway, fewer SLA violations, happier
customers, and so on - the list goes on and on. Single stack is
essentially the KISS option.

It also means that we'll essentially never have to perform IPv4
renumbering exercises in order to accomodate for growth. Those tend to
be very costly due to the man-hours required for planning and
implementation.

Besides, it means we don't need IPv4 to number customer infrastructure.
As you probably know, IPv4 numbers have a real cost these days.

My point of view is ASP/MSP/data centre stuff. I know I'm not alone in
going down the IPv6 road here, though. Facebook is another prominent
example.

Other operators in different market segments are also doing IPv6-only.
Kabel Deutschland and T-Mobile US, for example. I'm guessing they have
similar motivations.

Tore

Re: IPv6 deployment excuses

[Ruairi Carroll]

On 3 July 2016 at 12:15, Mark Tinka  wrote:

>
>
> On 3/Jul/16 12:01, Ruairi Carroll wrote:
>
>
> Core of the issue is that we _need_ to get an ICMP message back to the
> original "real server" who sent it. It's a non-issue in the SP space, but
> imagine if your ECMP groups were stateful in both directions...
>
>
> Okay.
>
>
>
>
> Think about it in layers, with each little piece adding up to the overall
> cost:
>
>
> I understand your points - to your comment, my question is around whether
> it is cheaper (for you) to just run IPv6 in lieu of IPv6 and IPv4.
>
>
Probably equal cost (ha ha) to pick one or the other. However since this
conversation was started about people using excuses to not deployand
being a stub/content provider, your main goal is reachability, to which v4
is still king.

So you have your hand forced to pick v4 for now.

/Ruairi


> Mark.
>

Re: IPv6 deployment excuses

[Mark Tinka]

On 3/Jul/16 12:01, Ruairi Carroll wrote:

>
> Core of the issue is that we _need_ to get an ICMP message back to the
> original "real server" who sent it. It's a non-issue in the SP space,
> but imagine if your ECMP groups were stateful in both directions...

Okay.


>  
>
> Think about it in layers, with each little piece adding up to the
> overall cost:

I understand your points - to your comment, my question is around
whether it is cheaper (for you) to just run IPv6 in lieu of IPv6 and IPv4.

Mark.

Re: IPv6 deployment excuses

[Ruairi Carroll]

On 3 July 2016 at 11:42, Mark Tinka  wrote:

>
>
> On 2/Jul/16 17:35, Ruairi Carroll wrote:
>
> - ECMP issues (Mostly around flow labels and vendor support for that, also
> feeds back into PMTUD issues)
>
>
> Do you rely on the ToS field in IPv4 for ECMP?
>
>
Nope. I use l4 tuple for flow hashing to make TCP happy. I was referring to
two things:

-
https://www.nanog.org/sites/default/files/wednesday.general.lotfi.mtu.6.pdf
- https://tools.ietf.org/html/rfc7098

Core of the issue is that we _need_ to get an ICMP message back to the
original "real server" who sent it. It's a non-issue in the SP space, but
imagine if your ECMP groups were stateful in both directions...


> - Maintaining 2x IP stacks is inherently expensive Vs 1
>
>
> How so?
>

Think about it in layers, with each little piece adding up to the overall
cost:

Implementation:
- Numerous bugs in control plane features with v6 handling.
- Numerous platform quirks which need time to be understood.


Operational:
- Need dev time to ensure applications are v6 ready.
- Need SysAdmin time to evaluate kernel/userspace support and functionality
- Need to maintain two sets of templates for config purposes
- Need to maintain two sets of addressing policies


Design:
- Some switches are not suitable for v6 because of their multicast handling
- Need extra time to validate designs will be v6 ready
- Need engineers who understand v6 sufficiently to think in terms of
Anycast and ECMP (Those who do it in v4 space are already thin on the
ground)
- Need engineers who understand v6 sufficiently to describe a good
ACL/Firewall filtering.
- Need engineers who understand v6 sufficiently to understand the
peering/transit landscape (Which IS different from v4).


I'll be the first one to say it sucks, but this is the reality of being a
stub. My past implementation failures were all torpedo'd by lack of dev
time/priority.

/Ruairi


>
>
> Mark.
>

Re: IPv6 deployment excuses

[Mark Tinka]

On 2/Jul/16 18:49, William Astle wrote:

>  Their specific excuse du jour changes every few months but it usually
> boils down to "we don't want to put any effort or resources into
> updating anything".

If you keep asking your girlfriend out on a date each week, and she
refuses to go out with you, each week, at some point, painful as it
might be, you have to cut your losses and move on.

Continuing to keep her as your girlfriend does not change the fact that
she does not want go out with you anymore, and only further incentivizes
her not to change her ways, as she knows you don't have the will or
strength to walk regardless of the bad treatment.

Mark.

Re: IPv6 deployment excuses

[Mark Tinka]

On 2/Jul/16 17:35, Ruairi Carroll wrote:

> - ECMP issues (Mostly around flow labels and vendor support for that, also
> feeds back into PMTUD issues)

Do you rely on the ToS field in IPv4 for ECMP?

> - Maintaining 2x IP stacks is inherently expensive Vs 1

How so?

Mark.