google ipv6 routes via cogent

Hi, I'm new to the nanog list, hope this isn't out of scope for what is
usually discussed here.

Cogent is telling me that I can't route through cogent to get to google ipv6
routes (particularly the well known dns addresses 2001:4860:4860::88xx)
because google decided not to advertise those route to one of their mutual
peers.

Anyone know anything about this ? .and why it happened and when it will be
resolved ?

-Aaron

http://bfy.tw/AOcZ

There's even a NANOG thread or two in there.

Cogent refuses to settlement-free peer on IPv6 to Google and Hurricane Electric.

The problem *in my mind* rests with Cogent trying to extract $$$ from said parties.

Regards,
Marty Strong

Google wants Cogent to peer with them. Cogent wants Google to buy transit or use another transit provider to reach Cogent. Check the archives for the dead horse.

Due to various peering disputes (notably with Hurricane Electric) Cogent just don't have all the routes in IPv6 (and should be regarded as a partial IPv6 transit only).
One should not rely only on Cogent for its transit, anyway :slight_smile:
Don't count on any improvement soon. It was already discussed here one year ago...

Just Google for it.. this is probably one of the oldest running Klan dispute in the industry..

http://www.datacenterknowledge.com/archives/2009/10/22/peering-disputes-migrate-to-ipv6/

Regards.

Faisal Imtiaz
Snappy Internet & Telecom
7266 SW 48 Street
Miami, FL 33155
Tel: 305 663 5518 x 232

Help-desk: (305)663-5518 Option 2 or Email: Support@Snappytelecom.net

Hi,

Cogent is not able to receive traffic from Google since February 2016,
the case is the same with HE since 2010.

So, as a quick workaround, you have to connect your network to another
IPv6 transit operator for these destinations.

I you don’t have this possibility, you can set up an IPv6-in-IPv4 tunnel
to HE; the IPv4 traffic flows normally.

I think maybe that wording isn't quite correct:
  "is not able to receive traffic from ...'

isn't really what's going on is it? I mean, it's not like the interfaces
aren't able to push packets, is it?

Thanks everyone, and my apologies.

After I sent that email to you all, I did google for it and found that this has been a problem since ~ February 2016. Dang, that long?!

In that case, I'm shutting down my ipv6 neighboring with cogent. I have 2 other inet v6 connections. I only learn 0/0 from all 3 isp's and I am not controlling which packets outbound where. I may change that and learn their prefixes and their peers, and then re-enable my cogent ipv6 bgp session then, but until then, I'm leaving it down.

Thanks again y'all.

RP/0/RSP0/CPU0:9k#sh bgp vrf one ipv6 unicast summary
....
Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer
Speaker 140 140 140 140 140 140

Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
abcd:1234:efab:1212:1:1
                  0 174 55615 55615 0 0 0 17:35:34 Idle (Admin)

-Aaron

Correction... ::/0 is what I learn from those 3 :slight_smile:

Shouldn't that be 2000::/3 ?

Well, I asked my (3) upstream providers to only send me a ipv6 default route and they sent me ::/0...here's one of them...

RP/0/RSP0/CPU0: 9k#sh bgp vrf one ipv6 uni neighbors abcd:1234::1 routes
Thu Mar 2 12:33:23.644 CST
...
Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.101.0.2:1 (default for vrf one)
*> ::/0 abcd:1234::1
                                                             0 1234 i

Processed 1 prefixes, 1 paths

-Aaron

Why did you don’t ask for a full view? With that, you can easily deal
with that kind of problem.

Or at least ask for a full view from Cogent - then you won't get any routes
they don't have

That will have the effect of prioritizing Cogent routes as that would be
more specific than the default routes from the other providers. Cogent are
not that good that you would want to do that.

Or at least ask for a full view from Cogent - then you won't get any routes
they don't have

Ah - you are correct

So - yeah what Alarig said - get full routes from all

Yes, thanks, I am going to do that. But, is there a middle ground between being default only and full routes ? Like is it advantageous for me to ask for partial routes (like their routes and direct peers and default route) ? This way I don't have millions of routes but I guess only a few hundred thousand or less? Let me know please.

-Aaron

* aaron1@gvtc.com (Aaron Gould) [Thu 02 Mar 2017, 20:52 CET]:

Yes, thanks, I am going to do that. But, is there a middle ground between being default only and full routes ? Like is it advantageous for me to ask for partial routes (like their routes and direct peers and default route) ? This way I don't have millions of routes but I guess only a few hundred thousand or less? Let me know please.

You should ask for full routes from all your providers + a default.

Then you write per-upstream import policies to permit or deny specific subsets of the prefixes they announce to you. For example, you could accept all prefixes from Cogent and your other upstreams tagged with a BGP community indicating they're from customers, and accept default from all except Cogent to take care of the rest of the traffic while still pretty much sending traffic to downstream customers to their respective upstream. (Or you can accept default from all but also import networks with whom Cogent has no direct relationship from your other upstreams; but that's less failsafe.)

Depending on what router hardware you have and what upstreams, you may have to filter out additional prefixes to not overflow its FIB.

  -- Niels.

Define "good" vs. "bad" transport of bits. As long as there is
adequate bandwidth and low latency, who cares?

I think the implication is that, on Cogent, there isn't. :slight_smile: