Re: best practice for advertising peering fabric routes

[Michael Hallgren]

Le 15/01/2014 07:59, Eric A Louie a écrit :
> Ok, so the right way to do it is in iBGP.  That pretty much answers the 
> question - don't redistribute those ixp-participant prefixes into my IGP.

Yes, using next-hop self (rather than importing IXP routes) as pointed
out earlier in this thread.

>
> I have a lot of iBGP homework to do, to make it work with the 5 POPs that are 
> all taking full route feeds.  I tried once and couldn't get the BGP tables 
> working correctly with a full mesh of the 5 routers, so it looks like time to 
> try it again, this time with a route reflector.  
>

I don't think you need route-reflection in a 5 node iBGP. What do you
mean by "couldn't get the BGP
tables working correctly"?

Cheers,

mh

>
>
>
>> 
>> From: Christopher Morrow 
>> To: Eric A Louie  
>> Cc: Patrick W. Gilmore ; NANOG list  
>> Sent: Tuesday, January 14, 2014 10:37 PM
>> Subject: Re: best practice for advertising peering fabric routes
>>
>>
>> On Wed, Jan 15, 2014 at 1:22 AM, Eric A Louie  wrote:
>>> Thank you - I will heed the warning.  I want to be a good community member 
>>> and make sure we're maintaining the agreed-upon practices (I'll 
>>> re-read/review my agreement with the IXP)
>>>
>>>
>>> So if that is the case, I have to rely on the peering fabric to just return 
>>> traffic, since the rest of my network (save the directly connected router) 
>>> will not know about those routes outbound?  And what about my customers who 
>>> are counting on me routing their office traffic through my network into the 
>>> peering fabric to their properties?  (I have one specifically who is 
>>> eventually looking for that capability)  Do I have to provide them some 
>>> sort of VPN to make that happen across my network to the peering fabric 
>>> router?
>>>
>> perhaps I'm confused, but you have sort of this situation:
>>   ixp-participants -> ixp -> your-router -> your-network -> your-customer
>>
>> you get routes for ixp-participants from 'ixp'
>> you send to the 'ixp' (and on to 'ixp-participants') routes for
>> 'your-customer' and 'your-network'
>>
>> right?
>>
>> then so long as you send 'your-customer' the routes you learn from
>> 'ixp' (which you set 'next-hop-self' on in ibgp from 'your-router' to
>> 'your-network' (in the ibgp-mesh that you will setup) ... everything
>> just works.
>>
>> All routers behind 'your-router' in 'your-netowrk' see
>> 'ixp-participants' with a next-hop of 'your-router' who still knows
>> 'send to ixp!' for the route(s) in question.
>>
>>>
>>>
 
 From: Patrick W. Gilmore 
 To: NANOG list 
 Sent: Tuesday, January 14, 2014 7:11 PM
 Subject: Re: best practice for advertising peering fabric routes


 Pardon the top post, but I really don't have anything to comment below 
 other than to agree with Chris and say rfc5963 is broken.

 NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An 
 IXP LAN should not be reachable from any device not directly attached to 
 that LAN. Period.

 Doing so endangers your peers & the IX itself. It is on the order of not 
 implementing BCP38, except no one has the (lame, ridiculous, idiotic, and 
 pure cost-shifting BS) excuse that they "can't" do this.

 --
 TTFN,
 patrick


 On Jan 14, 2014, at 21:22 , Christopher Morrow  
 wrote:

> On Tue, Jan 14, 2014 at 9:09 PM, Cb B  wrote:
>> On Jan 14, 2014 6:01 PM, "Eric A Louie"  wrote:
>>> I have a connection to a peering fabric and I'm not distributing the
>> peering fabric routes into my network.
> good plan.
>
>>> I see three options
>>> 1. redistribute into my igp (OSPF)
>>>
>>> 2. configure ibgp and route them within that infrastructure.  All the
>> default routes go out through the POPs so iBGP would see packets destined
>> for the peering fabric and route it that-a-way
>>> 3. leave it "as is", and let the outbound traffic go out my upstreams 
>>> and
>> the inbound traffic come back through the peering fabric
>>>
> 4. all peering-fabric routes get next-hop-self on your peering router
> before going into ibgp...
> all the rest of your network sees your local loopback as nexthop and
> things just work.
>
>>> Advantages and disadvantages, pros and cons?  Recommendations?
>> Experiences, good and bad?
>>>
>>> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the
>> POPs yet.  That's another issue completely from a planning perspective.
>>> thanks
>>> Eric
>>>
>> http://tools.ietf.org/html/rfc5963
>>
>> I like no-export




>>
>>

Re: gmail.com - 550 error for ipv6/PTR ?

[Laurent GUERBY]

On Tue, 2014-01-14 at 19:06 -0500, Brandon Applegate wrote:
> Just saw this in a message tonight.  No idea if this is a transient error 
> or not.

Got one too for AS197422 at "Tue, 14 Jan 2014 23:59:01 +0100", resent
the mail at "Wed, 15 Jan 2014 00:03:12 +0100" and it worked so probably
transient.

Laurent

host
gmail-smtp-in.l.google.com[2a00:1450:400c:c05::1a] said: 550-5.7.1
[2a01:6600:80xxx] Our system has detected that this message
550-5.7.1 does not meet IPv6 sending guidelines regarding PTR
records and
550-5.7.1 authentication. Please review 550-5.7.1
https://support.google.com/mail/?p=ipv6_authentication_error for
more 550
5.7.1 information. hg12si1854476wib.39 - gsmtp (in reply to end of
DATA
command)

Arrival-Date: Tue, 14 Jan 2014 22:59:01 + (UTC)
Date: Tue, 14 Jan 2014 23:59:01 +0100

> ---
> host gmail-smtp-in.l.google.com 
> [gmail-smtp-in.l.google.com][2607:f8b0:4002:c01::1a]
>said: 550-5.7.1 [2607:ff70:11::11] Our system has detected that this
>message does not 550-5.7.1 meet IPv6 sending guidelines regarding PTR
>records and authentication 550-5.7.1 . Please review 550-5.7.1
>https://support.google.com/mail/?p=ipv6_authentication_error 
> [support.google.com] for more 550
>5.7.1 information. t26si2290895yhl.255 - gsmtp (in reply to end of DATA
>command) 
> ---
> That URL's relevant section says:
> 
> Additional guidelines for IPv6
> 
> The sending IP must have a PTR record (i.e., a reverse DNS of the sending 
> IP) and it should match the IP obtained via the forward DNS resolution of 
> the hostname specified in the PTR record. Otherwise, mail will be marked 
> as spam or possibly rejected.
> 
> The sending domain should pass either SPF check or DKIM check. Otherwise, 
> mail might be marked as spam.
> ---
> 
> I have both of these (PTR's RR has matching , and I have SPF (but not 
> DKIM)).
> 
> I'm guessing that something on google's side is misinterpreting some data 
> or other busted logic.  I meet all the requirements laid out, and have 
> been sending mail to gmail addresses (via ipv6) since $forever.
> 
> Off-list replies are fine to minimize noise, and if there is an answer or 
> any meaningful correlation I will reply on-list.  Thanks in advance for 
> any info/feedback.
> 
> --
> Brandon Applegate - CCIE 10273
> PGP Key fingerprint:
> 830B 4802 1DD4 F4F9 63FE  B966 C0A7 189E 9EC0 3A74
> "SH1-0151.  This is the serial number, of our orbital gun."

Re: best practice for advertising peering fabric routes

[Eric A Louie]

Ok, so the right way to do it is in iBGP.  That pretty much answers the 
question - don't redistribute those ixp-participant prefixes into my IGP.

I have a lot of iBGP homework to do, to make it work with the 5 POPs that are 
all taking full route feeds.  I tried once and couldn't get the BGP tables 
working correctly with a full mesh of the 5 routers, so it looks like time to 
try it again, this time with a route reflector.  





>
> From: Christopher Morrow 
>To: Eric A Louie  
>Cc: Patrick W. Gilmore ; NANOG list  
>Sent: Tuesday, January 14, 2014 10:37 PM
>Subject: Re: best practice for advertising peering fabric routes
> 
>
>On Wed, Jan 15, 2014 at 1:22 AM, Eric A Louie  wrote:
>> Thank you - I will heed the warning.  I want to be a good community member 
>> and make sure we're maintaining the agreed-upon practices (I'll 
>> re-read/review my agreement with the IXP)
>>
>>
>> So if that is the case, I have to rely on the peering fabric to just return 
>> traffic, since the rest of my network (save the directly connected router) 
>> will not know about those routes outbound?  And what about my customers who 
>> are counting on me routing their office traffic through my network into the 
>> peering fabric to their properties?  (I have one specifically who is 
>> eventually looking for that capability)  Do I have to provide them some sort 
>> of VPN to make that happen across my network to the peering fabric router?
>>
>
>perhaps I'm confused, but you have sort of this situation:
>  ixp-participants -> ixp -> your-router -> your-network -> your-customer
>
>you get routes for ixp-participants from 'ixp'
>you send to the 'ixp' (and on to 'ixp-participants') routes for
>'your-customer' and 'your-network'
>
>right?
>
>then so long as you send 'your-customer' the routes you learn from
>'ixp' (which you set 'next-hop-self' on in ibgp from 'your-router' to
>'your-network' (in the ibgp-mesh that you will setup) ... everything
>just works.
>
>All routers behind 'your-router' in 'your-netowrk' see
>'ixp-participants' with a next-hop of 'your-router' who still knows
>'send to ixp!' for the route(s) in question.
>
>>
>>
>>
>>>
>>> From: Patrick W. Gilmore 
>>>To: NANOG list 
>>>Sent: Tuesday, January 14, 2014 7:11 PM
>>>Subject: Re: best practice for advertising peering fabric routes
>>>
>>>
>>>Pardon the top post, but I really don't have anything to comment below other 
>>>than to agree with Chris and say rfc5963 is broken.
>>>
>>>NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP 
>>>LAN should not be reachable from any device not directly attached to that 
>>>LAN. Period.
>>>
>>>Doing so endangers your peers & the IX itself. It is on the order of not 
>>>implementing BCP38, except no one has the (lame, ridiculous, idiotic, and 
>>>pure cost-shifting BS) excuse that they "can't" do this.
>>>
>>>--
>>>TTFN,
>>>patrick
>>>
>>>
>>>On Jan 14, 2014, at 21:22 , Christopher Morrow  
>>>wrote:
>>>
 On Tue, Jan 14, 2014 at 9:09 PM, Cb B  wrote:
> On Jan 14, 2014 6:01 PM, "Eric A Louie"  wrote:
>>
>> I have a connection to a peering fabric and I'm not distributing the
> peering fabric routes into my network.
>>

 good plan.

>> I see three options
>> 1. redistribute into my igp (OSPF)
>>
>> 2. configure ibgp and route them within that infrastructure.  All the
> default routes go out through the POPs so iBGP would see packets destined
> for the peering fabric and route it that-a-way
>>
>> 3. leave it "as is", and let the outbound traffic go out my upstreams and
> the inbound traffic come back through the peering fabric
>>
>>

 4. all peering-fabric routes get next-hop-self on your peering router
 before going into ibgp...
 all the rest of your network sees your local loopback as nexthop and
 things just work.

>> Advantages and disadvantages, pros and cons?  Recommendations?
> Experiences, good and bad?
>>
>>
>> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the
> POPs yet.  That's another issue completely from a planning perspective.
>>
>> thanks
>> Eric
>>
>
> http://tools.ietf.org/html/rfc5963
>
> I like no-export

>>>
>>>
>>>
>>>
>>>
>
>
>

Re: best practice for advertising peering fabric routes

[Christopher Morrow]

On Wed, Jan 15, 2014 at 1:36 AM, Eric A Louie  wrote:
> Never mind, I just carefully re-read the point.  Right, I'll filter the 
> prefix(es) of the IXP LAN(s) that I'm connected to and not let THAT get out, 
> no reason to advertise it since no traffic ever goes to it.  That still has 
> me asking to how best to advertise the rest of the public prefixes coming 
> from the other fabric members.
>

on  your ibgp peers on 'your-router' you'd have something like:
  match community 
  set next-hop-self



for one vendors view of the situation... and there is a link to:
  


that's worth a read.
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml
>
>
>
>
>>
>> From: Eric A Louie 
>>To: Patrick W. Gilmore ; NANOG list 
>>Sent: Tuesday, January 14, 2014 10:22 PM
>>Subject: Re: best practice for advertising peering fabric routes
>>
>>
>>Thank you - I will heed the warning.  I want to be a good community member 
>>and make sure we're maintaining the agreed-upon practices (I'll 
>>re-read/review my agreement with the IXP)
>>
>>
>>So if that is the case, I have to rely on the peering fabric to just return 
>>traffic, since the rest of my network (save the directly connected router) 
>>will not know about those routes outbound?  And what about my customers who 
>>are counting on me routing their office traffic through my network into the 
>>peering fabric to their properties?  (I have one specifically who is 
>>eventually looking for that capability)  Do I have to provide them some sort 
>>of VPN to make that happen across my network to the peering fabric router?
>>
>>
>>
>>
>>>
>>> From: Patrick W. Gilmore 
>>>To: NANOG list 
>>>Sent: Tuesday, January 14, 2014 7:11 PM
>>>Subject: Re: best practice for advertising peering fabric routes
>>>
>>>
>>>Pardon the top post, but I really don't have anything to comment below other 
>>>than to agree with Chris and say rfc5963 is broken.
>>>
>>>NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP 
>>>LAN should not be reachable from any device not directly attached to that 
>>>LAN. Period.
>>>
>>>Doing so endangers your peers & the IX itself. It is on the order of not 
>>>implementing BCP38, except no one has the (lame, ridiculous, idiotic, and 
>>>pure cost-shifting BS) excuse that they "can't" do this.
>>>
>>>--
>>>TTFN,
>>>patrick
>>>
>>>
>>>On Jan 14, 2014, at 21:22 , Christopher Morrow  
>>>wrote:
>>>
 On Tue, Jan 14, 2014 at 9:09 PM, Cb B  wrote:
> On Jan 14, 2014 6:01 PM, "Eric A Louie"  wrote:
>>
>> I have a connection to a peering fabric and I'm not distributing the
> peering fabric routes into my network.
>>

 good plan.

>> I see three options
>> 1. redistribute into my igp (OSPF)
>>
>> 2. configure ibgp and route them within that infrastructure.  All the
> default routes go out through the POPs so iBGP would see packets destined
> for the peering fabric and route it that-a-way
>>
>> 3. leave it "as is", and let the outbound traffic go out my upstreams and
> the inbound traffic come back through the peering fabric
>>
>>

 4. all peering-fabric routes get next-hop-self on your peering router
 before going into ibgp...
 all the rest of your network sees your local loopback as nexthop and
 things just work.

>> Advantages and disadvantages, pros and cons?  Recommendations?
> Experiences, good and bad?
>>
>>
>> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the
> POPs yet.  That's another issue completely from a planning perspective.
>>
>> thanks
>> Eric
>>
>
> http://tools.ietf.org/html/rfc5963
>
> I like no-export

>>>
>>>
>>>
>>>
>>>
>>
>>
>>

Re: best practice for advertising peering fabric routes

[Christopher Morrow]

On Wed, Jan 15, 2014 at 1:22 AM, Eric A Louie  wrote:
> Thank you - I will heed the warning.  I want to be a good community member 
> and make sure we're maintaining the agreed-upon practices (I'll 
> re-read/review my agreement with the IXP)
>
>
> So if that is the case, I have to rely on the peering fabric to just return 
> traffic, since the rest of my network (save the directly connected router) 
> will not know about those routes outbound?  And what about my customers who 
> are counting on me routing their office traffic through my network into the 
> peering fabric to their properties?  (I have one specifically who is 
> eventually looking for that capability)  Do I have to provide them some sort 
> of VPN to make that happen across my network to the peering fabric router?
>

perhaps I'm confused, but you have sort of this situation:
  ixp-participants -> ixp -> your-router -> your-network -> your-customer

you get routes for ixp-participants from 'ixp'
you send to the 'ixp' (and on to 'ixp-participants') routes for
'your-customer' and 'your-network'

right?

then so long as you send 'your-customer' the routes you learn from
'ixp' (which you set 'next-hop-self' on in ibgp from 'your-router' to
'your-network' (in the ibgp-mesh that you will setup) ... everything
just works.

All routers behind 'your-router' in 'your-netowrk' see
'ixp-participants' with a next-hop of 'your-router' who still knows
'send to ixp!' for the route(s) in question.

>
>
>
>>
>> From: Patrick W. Gilmore 
>>To: NANOG list 
>>Sent: Tuesday, January 14, 2014 7:11 PM
>>Subject: Re: best practice for advertising peering fabric routes
>>
>>
>>Pardon the top post, but I really don't have anything to comment below other 
>>than to agree with Chris and say rfc5963 is broken.
>>
>>NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP 
>>LAN should not be reachable from any device not directly attached to that 
>>LAN. Period.
>>
>>Doing so endangers your peers & the IX itself. It is on the order of not 
>>implementing BCP38, except no one has the (lame, ridiculous, idiotic, and 
>>pure cost-shifting BS) excuse that they "can't" do this.
>>
>>--
>>TTFN,
>>patrick
>>
>>
>>On Jan 14, 2014, at 21:22 , Christopher Morrow  
>>wrote:
>>
>>> On Tue, Jan 14, 2014 at 9:09 PM, Cb B  wrote:
 On Jan 14, 2014 6:01 PM, "Eric A Louie"  wrote:
>
> I have a connection to a peering fabric and I'm not distributing the
 peering fabric routes into my network.
>
>>>
>>> good plan.
>>>
> I see three options
> 1. redistribute into my igp (OSPF)
>
> 2. configure ibgp and route them within that infrastructure.  All the
 default routes go out through the POPs so iBGP would see packets destined
 for the peering fabric and route it that-a-way
>
> 3. leave it "as is", and let the outbound traffic go out my upstreams and
 the inbound traffic come back through the peering fabric
>
>
>>>
>>> 4. all peering-fabric routes get next-hop-self on your peering router
>>> before going into ibgp...
>>> all the rest of your network sees your local loopback as nexthop and
>>> things just work.
>>>
> Advantages and disadvantages, pros and cons?  Recommendations?
 Experiences, good and bad?
>
>
> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the
 POPs yet.  That's another issue completely from a planning perspective.
>
> thanks
> Eric
>

 http://tools.ietf.org/html/rfc5963

 I like no-export
>>>
>>
>>
>>
>>
>>

Re: best practice for advertising peering fabric routes

[Eric A Louie]

Never mind, I just carefully re-read the point.  Right, I'll filter the 
prefix(es) of the IXP LAN(s) that I'm connected to and not let THAT get out, no 
reason to advertise it since no traffic ever goes to it.  That still has me 
asking to how best to advertise the rest of the public prefixes coming from the 
other fabric members.





>
> From: Eric A Louie 
>To: Patrick W. Gilmore ; NANOG list  
>Sent: Tuesday, January 14, 2014 10:22 PM
>Subject: Re: best practice for advertising peering fabric routes
> 
>
>Thank you - I will heed the warning.  I want to be a good community member and 
>make sure we're maintaining the agreed-upon practices (I'll re-read/review my 
>agreement with the IXP) 
>
>
>So if that is the case, I have to rely on the peering fabric to just return 
>traffic, since the rest of my network (save the directly connected router) 
>will not know about those routes outbound?  And what about my customers who 
>are counting on me routing their office traffic through my network into the 
>peering fabric to their properties?  (I have one specifically who is 
>eventually looking for that capability)  Do I have to provide them some sort 
>of VPN to make that happen across my network to the peering fabric router?
>
>
>
>
>>
>> From: Patrick W. Gilmore 
>>To: NANOG list  
>>Sent: Tuesday, January 14, 2014 7:11 PM
>>Subject: Re: best practice for advertising peering fabric routes
>> 
>>
>>Pardon the top post, but I really don't have anything to comment below other 
>>than to agree with Chris and say rfc5963 is broken.
>>
>>NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP 
>>LAN should not be reachable from any device not directly attached to that 
>>LAN. Period.
>>
>>Doing so endangers your peers & the IX itself. It is on the order of not 
>>implementing BCP38, except no one has the (lame, ridiculous, idiotic, and 
>>pure cost-shifting BS) excuse that they "can't" do this.
>>
>>-- 
>>TTFN,
>>patrick
>>
>>
>>On Jan 14, 2014, at 21:22 , Christopher Morrow  
>>wrote:
>>
>>> On Tue, Jan 14, 2014 at 9:09 PM, Cb B  wrote:
 On Jan 14, 2014 6:01 PM, "Eric A Louie"  wrote:
> 
> I have a connection to a peering fabric and I'm not distributing the
 peering fabric routes into my network.
> 
>>> 
>>> good plan.
>>> 
> I see three options
> 1. redistribute into my igp (OSPF)
> 
> 2. configure ibgp and route them within that infrastructure.  All the
 default routes go out through the POPs so iBGP would see packets destined
 for the peering fabric and route it that-a-way
> 
> 3. leave it "as is", and let the outbound traffic go out my upstreams and
 the inbound traffic come back through the peering fabric
> 
> 
>>> 
>>> 4. all peering-fabric routes get next-hop-self on your peering router
>>> before going into ibgp...
>>> all the rest of your network sees your local loopback as nexthop and
>>> things just work.
>>> 
> Advantages and disadvantages, pros and cons?  Recommendations?
 Experiences, good and bad?
> 
> 
> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the
 POPs yet.  That's another issue completely from a planning perspective.
> 
> thanks
> Eric
> 
 
 http://tools.ietf.org/html/rfc5963
 
 I like no-export
>>> 
>>
>>
>>
>>
>>
>
>
>

Re: best practice for advertising peering fabric routes

[Eric A Louie]

Thank you - I will heed the warning.  I want to be a good community member and 
make sure we're maintaining the agreed-upon practices (I'll re-read/review my 
agreement with the IXP) 


So if that is the case, I have to rely on the peering fabric to just return 
traffic, since the rest of my network (save the directly connected router) will 
not know about those routes outbound?  And what about my customers who are 
counting on me routing their office traffic through my network into the peering 
fabric to their properties?  (I have one specifically who is eventually looking 
for that capability)  Do I have to provide them some sort of VPN to make that 
happen across my network to the peering fabric router?




>
> From: Patrick W. Gilmore 
>To: NANOG list  
>Sent: Tuesday, January 14, 2014 7:11 PM
>Subject: Re: best practice for advertising peering fabric routes
> 
>
>Pardon the top post, but I really don't have anything to comment below other 
>than to agree with Chris and say rfc5963 is broken.
>
>NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP 
>LAN should not be reachable from any device not directly attached to that LAN. 
>Period.
>
>Doing so endangers your peers & the IX itself. It is on the order of not 
>implementing BCP38, except no one has the (lame, ridiculous, idiotic, and pure 
>cost-shifting BS) excuse that they "can't" do this.
>
>-- 
>TTFN,
>patrick
>
>
>On Jan 14, 2014, at 21:22 , Christopher Morrow  wrote:
>
>> On Tue, Jan 14, 2014 at 9:09 PM, Cb B  wrote:
>>> On Jan 14, 2014 6:01 PM, "Eric A Louie"  wrote:
 
 I have a connection to a peering fabric and I'm not distributing the
>>> peering fabric routes into my network.
 
>> 
>> good plan.
>> 
 I see three options
 1. redistribute into my igp (OSPF)
 
 2. configure ibgp and route them within that infrastructure.  All the
>>> default routes go out through the POPs so iBGP would see packets destined
>>> for the peering fabric and route it that-a-way
 
 3. leave it "as is", and let the outbound traffic go out my upstreams and
>>> the inbound traffic come back through the peering fabric
 
 
>> 
>> 4. all peering-fabric routes get next-hop-self on your peering router
>> before going into ibgp...
>> all the rest of your network sees your local loopback as nexthop and
>> things just work.
>> 
 Advantages and disadvantages, pros and cons?  Recommendations?
>>> Experiences, good and bad?
 
 
 I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the
>>> POPs yet.  That's another issue completely from a planning perspective.
 
 thanks
 Eric
 
>>> 
>>> http://tools.ietf.org/html/rfc5963
>>> 
>>> I like no-export
>> 
>
>
>
>
>

Re: best practice for advertising peering fabric routes

[Dobbins, Roland]

On Jan 15, 2014, at 11:41 AM, Patrick W. Gilmore  wrote:

> I repeat: NEVER EVER EVER put an IX prefix into BGP, IGP, or even static 
> route. An IXP LAN should not be reachable from any device except those 
> directly attached to that LAN. Period.

+1

Again, folks, this isn't theoretical.  When the particular attacks cited in 
this thread were taking place, I was astonished that the IXP infrastructure 
routes were even being advertised outside of the IXP network, because of these 
very issues.

IXPs are not the problem when it comes to breaking PMTU-D.  The problem is 
largely with enterprise networks, and with 'security' vendors who've propagated 
the myth that simply blocking all ICMP somehow increases 'security'.

---
Roland Dobbins  // 

  Luck is the residue of opportunity and design.

   -- John Milton



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: best practice for advertising peering fabric routes

[Patrick W. Gilmore]

On Jan 14, 2014, at 23:03 , Leo Bicknell  wrote:
> On Jan 14, 2014, at 9:35 PM, Patrick W. Gilmore  wrote:
> 
>> So Just Don't Do It. Setting next-hop-self is not just for "big guys", the 
>> crappiest, tiniest router that can do peering at an IXP has the same 
>> ability. Use it. Stop putting me and every one of your peers in danger 
>> because you are lazy.
> 
> I'm going to have to disagree here with Patrick, because this is security 
> through obscurity, and that doesn't work well.

Leo, each of your points below is incorrect. I'm happy to discuss off-list if 
you'd like.


> For some history about why people like Patrick take the position he did, 
> read: http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet
> 
> Exchange points got attacked, so people yanked them from the routing table 
> hoping to prevent attacks.  If you're on this list it should take you all of 
> about 3 seconds to realize the attackers could do a traceroute, and attack 
> the IP one hop on the far side of the exchange for a few dozen providers and 
> still cause all sorts of havoc, or do any of another half dozen things I 
> won't mention to cause problems.  The effect would be nearly, if not 
> perfectly identical, since that traffic still has to cross the exchange.

Let's take just the incident mentioned in the blog post above (which is pretty 
broken itself, but hey, who said the CEO of CDN had to know anything about 
networking... ? :).

To where would the attacker traceroute -to-? Somewhere inside Cloudflare? Other 
LINX members? Remember, most of the attack was sourced from networks which were 
not attached to the LINX. If the source network or the source network's 
upstreams are not LINX members, there is probably _no_ path that goes through 
LINX. Even if they are members, lots of networks have alternative paths (other 
IXPs, private interconnections, etc.). For instance, sources in Germany may 
well flow over DE-CIX even if there is a peering session at LINX. Etc. There is 
no single or set of IP addresses that will guarantee even a majority of packets 
traverse a specific IXP except the IXP LAN.

Also, the attack was reflected DNS, so the attacker couldn't actually perform 
the traceroutes you suggest from each source as he did not control the sources. 
He _might_ be able to find _some_ of the paths with a lot of sleuthing through 
route & traceroute servers, but that would make things massively more 
difficult, as well as massively cut the number of servers he can abuse to the 
same effect. Both of which are huge wins for the good guys.

Pulling the IXP prefix has a enormous benefits and essentially no downside. I 
know literally hundreds of ISPs large & small who do not carry the IXP prefix, 
and none have seen any significant issues (most have seen zero, a few get asked 
about 3 stars, but as I said before, puh-lze).

I'm a bit surprised you even tried to bring this up. I know you well enough to 
know you would have realized all of the above if you had though about it for a 
while (or just asked).


> I'll point out the MTU step-down issue is real, and it's part of why we can't 
> have 9K MTU exchanges be the default on the Internet, which would really make 
> things better for a significant number of users.  I think Patrick is a bit 
> quick to dismiss some of the potential issues.

MTU step-down is a real issue, and it's real enough whether IXP LANs are in the 
DFZ or not. Let's solve the overarching problem before doing something which 
has real, proven harm and leaves the root cause in place.

Besides, the two VLAN method already exists in multiple places and it hasn't 
helped adoption of 9K packets. Unless you are talking about letting some people 
attach with 1500 MTU and others with 9000 MTU? 'Cause if that's what you meant, 
then I'm just going to call you loony and ask what you're smoking.


> Every link on every router is subject to attack.  Exchange point LAN's really 
> aren't special in that regard.  If anything the only thing that makes them 
> slightly special is that they may in fact be more oversubscribed than most 
> links.  Where a backbone might have a router with 20x10GE, so attackers could 
> try and drive 190GE out a 10GE in theory; an exchange point may have 100 
> people with 20x10GE coming in.  An alternate view that mega-exchange points 
> are massively oversubscribed potential single points of failure, and perhaps 
> network operators should consider that.  While a DDOS taking an exchange down 
> for half a day is bad, imagine if there was a more sinister attack, taking 
> out the physical infrastructure of an exchange.  That can't be "fixed" with a 
> routing advertisement.

IXPs are more special because they are shared. Other links are between you & 
one other network not hundreds of other networks, some of whom have no 
relationship with you.

If you don't like the rules of IXPs, don't join one. But hooking up to one and 
deciding "I'm going to carry this prefix" even 

Re: best practice for advertising peering fabric routes

[Leo Bicknell]

On Jan 14, 2014, at 9:35 PM, Patrick W. Gilmore  wrote:

> So Just Don't Do It. Setting next-hop-self is not just for "big guys", the 
> crappiest, tiniest router that can do peering at an IXP has the same ability. 
> Use it. Stop putting me and every one of your peers in danger because you are 
> lazy.

I'm going to have to disagree here with Patrick, because this is security 
through obscurity, and that doesn't work well.

For some history about why people like Patrick take the position he did, read: 
http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet

Exchange points got attacked, so people yanked them from the routing table 
hoping to prevent attacks.  If you're on this list it should take you all of 
about 3 seconds to realize the attackers could do a traceroute, and attack the 
IP one hop on the far side of the exchange for a few dozen providers and still 
cause all sorts of havoc, or do any of another half dozen things I won't 
mention to cause problems.  The effect would be nearly, if not perfectly 
identical, since that traffic still has to cross the exchange.

I'll point out the MTU step-down issue is real, and it's part of why we can't 
have 9K MTU exchanges be the default on the Internet, which would really make 
things better for a significant number of users.  I think Patrick is a bit 
quick to dismiss some of the potential issues.

Every link on every router is subject to attack.  Exchange point LAN's really 
aren't special in that regard.  If anything the only thing that makes them 
slightly special is that they may in fact be more oversubscribed than most 
links.  Where a backbone might have a router with 20x10GE, so attackers could 
try and drive 190GE out a 10GE in theory; an exchange point may have 100 people 
with 20x10GE coming in.  An alternate view that mega-exchange points are 
massively oversubscribed potential single points of failure, and perhaps 
network operators should consider that.  While a DDOS taking an exchange down 
for half a day is bad, imagine if there was a more sinister attack, taking out 
the physical infrastructure of an exchange.  That can't be "fixed" with a 
routing advertisement.

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/







signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: gmail.com - 550 error for ipv6/PTR ?

[Blair Trosper]

Possibly related, a lot of 503 errors are starting to show up in the
javascript served by Google inside Gmail...reminds me of the issue in the
early morning hours (US time)...very similar to what I'm starting to see on
the front end.  I've not had any IPv6 emails bounce, but I do have some
that are MIA from Google Apps.  They were sent from one GApps domain to
another, but they haven't materialized on the other end...but they also
haven't bounced back to me.

As a matter of curiosity, I also sent my personal Gmail account email over
v6, and it's doing the same thing...either it's delayed or it's going to
bounce.

The front-end of Gmail is starting to behave weirdly, as well, spitting out
bizarre errors like "technical code:  undefined", and saying it wasn't able
to send a message, but the message going through.  There's a fair amount of
chatter about this on Twitter, so I know it's not just me.

It also thinks it's offline in one tab, when an account in another is
perfectly fine.  Maybe a DC somewhere is having trouble again?


On Tue, Jan 14, 2014 at 8:10 PM, Christopher Morrow  wrote:

> On Tue, Jan 14, 2014 at 8:51 PM, Ted Cooper
>  wrote:
> > On 15/01/14 10:06, Brandon Applegate wrote:
> >> Off-list replies are fine to minimize noise, and if there is an answer
> >> or any meaningful correlation I will reply on-list.  Thanks in advance
> >> for any info/feedback.
> >
>
> brandon, I didn't get your original... but could you ping me off-list
> and maybe I can get some data about what it is you're seeing? :)
>
> > I have been running into these a lot also and have so far concluded that
> > it is an error within Google. The PTR/, SPF and DKIM are all matched
> > up and tested as working. It also occurring on domains using google apps
> > to handle their email so it is platform wide. All of the emails are
> > personal emails, but coming from multiple domains/senders.
> >
> > The exact same email will be rejected when sent to any google IPv6
> > server for minutes/hours, but 3-4 hours later it will be accepted
> > without error.
> >
> > The fact that it is being hard rejected is really quite annoying and
> > generating a lot more support work.
> >
> > Unfortunately, my only fix at present is to turn off IPv6 delivery for
> > all google hosted domains as I encounter them. It would be really nice
> > if it was fixed.
> >
> > My theory is that they are failing PTR lookups.
> >
> >
> >
>
>

Re: gmail.com - 550 error for ipv6/PTR ?

[Blair Trosper]

FWIW I do know there was a MASSIVE failure last night around 0800 UTC with
Google's DNS system, and it caused their routing to not only go bat shit
insane, but also for the edge nodes that serve their content to return
largely 503 errors (service unavailable) for several hours.

It wasn't until a few hours ago that the BGP table stabilized.  It was a
horrific mess last night...not sure if perhaps there's still problems
unresolved from that same incident.


On Tue, Jan 14, 2014 at 7:51 PM, Ted Cooper
wrote:

> On 15/01/14 10:06, Brandon Applegate wrote:
> > Off-list replies are fine to minimize noise, and if there is an answer
> > or any meaningful correlation I will reply on-list.  Thanks in advance
> > for any info/feedback.
>
> I have been running into these a lot also and have so far concluded that
> it is an error within Google. The PTR/, SPF and DKIM are all matched
> up and tested as working. It also occurring on domains using google apps
> to handle their email so it is platform wide. All of the emails are
> personal emails, but coming from multiple domains/senders.
>
> The exact same email will be rejected when sent to any google IPv6
> server for minutes/hours, but 3-4 hours later it will be accepted
> without error.
>
> The fact that it is being hard rejected is really quite annoying and
> generating a lot more support work.
>
> Unfortunately, my only fix at present is to turn off IPv6 delivery for
> all google hosted domains as I encounter them. It would be really nice
> if it was fixed.
>
> My theory is that they are failing PTR lookups.
>
>
>
>

Re: best practice for advertising peering fabric routes

[Patrick W. Gilmore]

On Jan 14, 2014, at 22:20 , Leo Bicknell  wrote:
> On Jan 14, 2014, at 7:55 PM, Eric A Louie  wrote:
> 
>> I have a connection to a peering fabric and I'm not distributing the peering 
>> fabric routes into my network.
> 
> There's a two part problem lurking.
> 
> Problem #1 is how you handle your internal routing.  Most of the "big boys" 
> will next-hop-self in iBGP all external routes.  However depending on the 
> size and configuration of your network there may be advantages to not using 
> next-hop-self, or just putting it in your IGP.  Basically, you should be 
> doing the same thing you do for a /30 from a peer or transit provider in your 
> network.  There is one thing special about an exchange point though, for 
> security reasons you probably want to add it to your "never accept" routing 
> filter from peers/customers/transit providers.  You don't need someone 
> injecting a couple of more specifics to mess with your routing.
> 
> Problem #2 is your customers.  If you have customers that may operate default 
> free, and they use one of the traceroute tools that not only finds the route, 
> but then continues to probe it (like MTR, or Visual Traceroute) there can be 
> an issue.  The initial traceroute probe may return an IP on the exchange of 
> your peer's router, but then when they subsequently source ICMP Ping to that 
> IP there will be no route in their network, and it will simply never respond. 
>  Some call this a feature, some call this a problem.  There is also an 
> extremely rare problem where the far end of the peering exchange steps down 
> MTU, and thus PMTU discovery is invoked, but your customers use Unicast RPF.  
> Since the exchange LAN isn't in their table, Unicast RPF may drop the PMTU 
> packet-too-big message, causing a timeout.
> 
> If your customers have a default to you, all is well.  However if they have a 
> default to someone else, and take a table from you to selectively override 
> the same problem can occur for any routes they select through you that also 
> traverse the exchange.
> 
> IMHO the best fix for #2 is that the exchange have an ASN, and announce the 
> exchange LAN from that ASN, typically via the route server.  You should then 
> peer with the route server to pick up that network.  That makes the 
> announcement consistent, and makes it clear who operates that network, and 
> your customers can then access it.  Many exchanges do not do this, and then 
> the next best solution might be to originate it from your ASN and announce it 
> to your customers only, with no-export set on the way out.
> 
> Various people will no doubt chime in and tell you the last two suggestions 
> are either excellent wonderful and the worst idea ever.  Safe to say I know 
> of networks doing both and the world has not ended.  YMMV, some assembly 
> required, batteries not included, actual conditions may affect product 
> performance, do not taunt the happy fun ball, and consult a doctor if your 
> network is up for more than four hours.

I've known Leo for .. well, let's just say a long time. And I have great 
respect for his networking abilities. But I fall into the second camp. As 
someone who owns & operates an IXP, and is on the board of a couple more, and 
helped start even more, I'm going to stick to my guns here.

As for knowing networks that do both, blah, blah, blah. I know lots of networks 
that allow spam, don't configure BCP38, have abusable name or NTP servers, etc. 
and the world has not come to an end. Doesn't mean you should. Lame excuse, 
Leo, and beneath you to even go there.

NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP 
LAN should not be reachable from any device not directly attached to that LAN. 
Period.

If for no better reason, how about because it is not your prefix, and chances 
are the IXP does not want you to use the prefix. In fact, I challenge you to 
find a major IXP route server which is announcing the IXP block.

But because this is a teaching list, let's go through the problems Leo 
mentions. Anyone who steps down MTU on an IXP is far too broken to worry about 
your customer having RFP and not getting PMTU. Again, I challenge you to find 
someone doing this today, their network would be close to unusable. As for 
traceroute  Seriously? You want to increase breakage on the Internet 
because it might cause 3 stars in a traceroute? Puh-LEEEZE. Sorry, neither of 
those pass the sniff test, IMHO.

So Just Don't Do It. Setting next-hop-self is not just for "big guys", the 
crappiest, tiniest router that can do peering at an IXP has the same ability. 
Use it. Stop putting me and every one of your peers in danger because you are 
lazy.

-- 
TTFN,
patrick



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: best practice for advertising peering fabric routes

[Leo Bicknell]

On Jan 14, 2014, at 7:55 PM, Eric A Louie  wrote:

> I have a connection to a peering fabric and I'm not distributing the peering 
> fabric routes into my network.

There's a two part problem lurking.

Problem #1 is how you handle your internal routing.  Most of the "big boys" 
will next-hop-self in iBGP all external routes.  However depending on the size 
and configuration of your network there may be advantages to not using 
next-hop-self, or just putting it in your IGP.  Basically, you should be doing 
the same thing you do for a /30 from a peer or transit provider in your 
network.  There is one thing special about an exchange point though, for 
security reasons you probably want to add it to your "never accept" routing 
filter from peers/customers/transit providers.  You don't need someone 
injecting a couple of more specifics to mess with your routing.

Problem #2 is your customers.  If you have customers that may operate default 
free, and they use one of the traceroute tools that not only finds the route, 
but then continues to probe it (like MTR, or Visual Traceroute) there can be an 
issue.  The initial traceroute probe may return an IP on the exchange of your 
peer's router, but then when they subsequently source ICMP Ping to that IP 
there will be no route in their network, and it will simply never respond.  
Some call this a feature, some call this a problem.  There is also an extremely 
rare problem where the far end of the peering exchange steps down MTU, and thus 
PMTU discovery is invoked, but your customers use Unicast RPF.  Since the 
exchange LAN isn't in their table, Unicast RPF may drop the PMTU packet-too-big 
message, causing a timeout.

If your customers have a default to you, all is well.  However if they have a 
default to someone else, and take a table from you to selectively override the 
same problem can occur for any routes they select through you that also 
traverse the exchange.

IMHO the best fix for #2 is that the exchange have an ASN, and announce the 
exchange LAN from that ASN, typically via the route server.  You should then 
peer with the route server to pick up that network.  That makes the 
announcement consistent, and makes it clear who operates that network, and your 
customers can then access it.  Many exchanges do not do this, and then the next 
best solution might be to originate it from your ASN and announce it to your 
customers only, with no-export set on the way out.

Various people will no doubt chime in and tell you the last two suggestions are 
either excellent wonderful and the worst idea ever.  Safe to say I know of 
networks doing both and the world has not ended.  YMMV, some assembly required, 
batteries not included, actual conditions may affect product performance, do 
not taunt the happy fun ball, and consult a doctor if your network is up for 
more than four hours.

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/







signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: best practice for advertising peering fabric routes

[Cb B]

On Jan 14, 2014 7:13 PM, "Patrick W. Gilmore"  wrote:
>
> Pardon the top post, but I really don't have anything to comment below
other than to agree with Chris and say rfc5963 is broken.
>
> NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An
IXP LAN should not be reachable from any device not directly attached to
that LAN. Period.
>
> Doing so endangers your peers & the IX itself. It is on the order of not
implementing BCP38, except no one has the (lame, ridiculous, idiotic, and
pure cost-shifting BS) excuse that they "can't" do this.
>

+1.  Rfc5963 needs to update that guidance. Set next hop self loopback0 and
done

CB
> --
> TTFN,
> patrick
>
>
> On Jan 14, 2014, at 21:22 , Christopher Morrow 
wrote:
>
> > On Tue, Jan 14, 2014 at 9:09 PM, Cb B  wrote:
> >> On Jan 14, 2014 6:01 PM, "Eric A Louie"  wrote:
> >>>
> >>> I have a connection to a peering fabric and I'm not distributing the
> >> peering fabric routes into my network.
> >>>
> >
> > good plan.
> >
> >>> I see three options
> >>> 1. redistribute into my igp (OSPF)
> >>>
> >>> 2. configure ibgp and route them within that infrastructure.  All the
> >> default routes go out through the POPs so iBGP would see packets
destined
> >> for the peering fabric and route it that-a-way
> >>>
> >>> 3. leave it "as is", and let the outbound traffic go out my upstreams
and
> >> the inbound traffic come back through the peering fabric
> >>>
> >>>
> >
> > 4. all peering-fabric routes get next-hop-self on your peering router
> > before going into ibgp...
> > all the rest of your network sees your local loopback as nexthop and
> > things just work.
> >
> >>> Advantages and disadvantages, pros and cons?  Recommendations?
> >> Experiences, good and bad?
> >>>
> >>>
> >>> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the
> >> POPs yet.  That's another issue completely from a planning perspective.
> >>>
> >>> thanks
> >>> Eric
> >>>
> >>
> >> http://tools.ietf.org/html/rfc5963
> >>
> >> I like no-export
> >
>
>

Re: best practice for advertising peering fabric routes

[Patrick W. Gilmore]

Pardon the top post, but I really don't have anything to comment below other 
than to agree with Chris and say rfc5963 is broken.

NEVER EVER EVER put an IX prefix into BGP, IGP, or even static route. An IXP 
LAN should not be reachable from any device not directly attached to that LAN. 
Period.

Doing so endangers your peers & the IX itself. It is on the order of not 
implementing BCP38, except no one has the (lame, ridiculous, idiotic, and pure 
cost-shifting BS) excuse that they "can't" do this.

-- 
TTFN,
patrick


On Jan 14, 2014, at 21:22 , Christopher Morrow  wrote:

> On Tue, Jan 14, 2014 at 9:09 PM, Cb B  wrote:
>> On Jan 14, 2014 6:01 PM, "Eric A Louie"  wrote:
>>> 
>>> I have a connection to a peering fabric and I'm not distributing the
>> peering fabric routes into my network.
>>> 
> 
> good plan.
> 
>>> I see three options
>>> 1. redistribute into my igp (OSPF)
>>> 
>>> 2. configure ibgp and route them within that infrastructure.  All the
>> default routes go out through the POPs so iBGP would see packets destined
>> for the peering fabric and route it that-a-way
>>> 
>>> 3. leave it "as is", and let the outbound traffic go out my upstreams and
>> the inbound traffic come back through the peering fabric
>>> 
>>> 
> 
> 4. all peering-fabric routes get next-hop-self on your peering router
> before going into ibgp...
> all the rest of your network sees your local loopback as nexthop and
> things just work.
> 
>>> Advantages and disadvantages, pros and cons?  Recommendations?
>> Experiences, good and bad?
>>> 
>>> 
>>> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the
>> POPs yet.  That's another issue completely from a planning perspective.
>>> 
>>> thanks
>>> Eric
>>> 
>> 
>> http://tools.ietf.org/html/rfc5963
>> 
>> I like no-export
> 

Re: best practice for advertising peering fabric routes

[Christopher Morrow]

On Tue, Jan 14, 2014 at 9:09 PM, Cb B  wrote:
> On Jan 14, 2014 6:01 PM, "Eric A Louie"  wrote:
>>
>> I have a connection to a peering fabric and I'm not distributing the
> peering fabric routes into my network.
>>

good plan.

>> I see three options
>> 1. redistribute into my igp (OSPF)
>>
>> 2. configure ibgp and route them within that infrastructure.  All the
> default routes go out through the POPs so iBGP would see packets destined
> for the peering fabric and route it that-a-way
>>
>> 3. leave it "as is", and let the outbound traffic go out my upstreams and
> the inbound traffic come back through the peering fabric
>>
>>

4. all peering-fabric routes get next-hop-self on your peering router
before going into ibgp...
all the rest of your network sees your local loopback as nexthop and
things just work.

>> Advantages and disadvantages, pros and cons?  Recommendations?
> Experiences, good and bad?
>>
>>
>> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the
> POPs yet.  That's another issue completely from a planning perspective.
>>
>> thanks
>> Eric
>>
>
> http://tools.ietf.org/html/rfc5963
>
> I like no-export

Re: gmail.com - 550 error for ipv6/PTR ?

[Christopher Morrow]

On Tue, Jan 14, 2014 at 8:51 PM, Ted Cooper
 wrote:
> On 15/01/14 10:06, Brandon Applegate wrote:
>> Off-list replies are fine to minimize noise, and if there is an answer
>> or any meaningful correlation I will reply on-list.  Thanks in advance
>> for any info/feedback.
>

brandon, I didn't get your original... but could you ping me off-list
and maybe I can get some data about what it is you're seeing? :)

> I have been running into these a lot also and have so far concluded that
> it is an error within Google. The PTR/, SPF and DKIM are all matched
> up and tested as working. It also occurring on domains using google apps
> to handle their email so it is platform wide. All of the emails are
> personal emails, but coming from multiple domains/senders.
>
> The exact same email will be rejected when sent to any google IPv6
> server for minutes/hours, but 3-4 hours later it will be accepted
> without error.
>
> The fact that it is being hard rejected is really quite annoying and
> generating a lot more support work.
>
> Unfortunately, my only fix at present is to turn off IPv6 delivery for
> all google hosted domains as I encounter them. It would be really nice
> if it was fixed.
>
> My theory is that they are failing PTR lookups.
>
>
>

Re: best practice for advertising peering fabric routes

[Cb B]

On Jan 14, 2014 6:01 PM, "Eric A Louie"  wrote:
>
> I have a connection to a peering fabric and I'm not distributing the
peering fabric routes into my network.
>
> I see three options
> 1. redistribute into my igp (OSPF)
>
> 2. configure ibgp and route them within that infrastructure.  All the
default routes go out through the POPs so iBGP would see packets destined
for the peering fabric and route it that-a-way
>
> 3. leave it "as is", and let the outbound traffic go out my upstreams and
the inbound traffic come back through the peering fabric
>
>
> Advantages and disadvantages, pros and cons?  Recommendations?
Experiences, good and bad?
>
>
> I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the
POPs yet.  That's another issue completely from a planning perspective.
>
> thanks
> Eric
>

http://tools.ietf.org/html/rfc5963

I like no-export

best practice for advertising peering fabric routes

[Eric A Louie]

I have a connection to a peering fabric and I'm not distributing the peering 
fabric routes into my network.

I see three options
1. redistribute into my igp (OSPF)

2. configure ibgp and route them within that infrastructure.  All the default 
routes go out through the POPs so iBGP would see packets destined for the 
peering fabric and route it that-a-way

3. leave it "as is", and let the outbound traffic go out my upstreams and the 
inbound traffic come back through the peering fabric


Advantages and disadvantages, pros and cons?  Recommendations?  Experiences, 
good and bad?


I have 5 POPs, 2 OSPF areas, and have not brought iBGP up between the POPs yet. 
 That's another issue completely from a planning perspective.

thanks
Eric

Re: gmail.com - 550 error for ipv6/PTR ?

[Ted Cooper]

On 15/01/14 10:06, Brandon Applegate wrote:
> Off-list replies are fine to minimize noise, and if there is an answer
> or any meaningful correlation I will reply on-list.  Thanks in advance
> for any info/feedback.

I have been running into these a lot also and have so far concluded that
it is an error within Google. The PTR/, SPF and DKIM are all matched
up and tested as working. It also occurring on domains using google apps
to handle their email so it is platform wide. All of the emails are
personal emails, but coming from multiple domains/senders.

The exact same email will be rejected when sent to any google IPv6
server for minutes/hours, but 3-4 hours later it will be accepted
without error.

The fact that it is being hard rejected is really quite annoying and
generating a lot more support work.

Unfortunately, my only fix at present is to turn off IPv6 delivery for
all google hosted domains as I encounter them. It would be really nice
if it was fixed.

My theory is that they are failing PTR lookups.

Re: gmail.com - 550 error for ipv6/PTR ?

[John Levine]

In article  you write:
>Just saw this in a message tonight.  No idea if this is a transient error 
>or not.

I saw the same thing, on an IP that has forward and reverse DNS and
mail that passes SPF.  Burp, I guess.

gmail.com - 550 error for ipv6/PTR ?

[Brandon Applegate]

Just saw this in a message tonight.  No idea if this is a transient error 
or not.


---
host gmail-smtp-in.l.google.com 
[gmail-smtp-in.l.google.com][2607:f8b0:4002:c01::1a]

   said: 550-5.7.1 [2607:ff70:11::11] Our system has detected that this
   message does not 550-5.7.1 meet IPv6 sending guidelines regarding PTR
   records and authentication 550-5.7.1 . Please review 550-5.7.1
   https://support.google.com/mail/?p=ipv6_authentication_error 
[support.google.com] for more 550

   5.7.1 information. t26si2290895yhl.255 - gsmtp (in reply to end of DATA
   command) 
---

That URL's relevant section says:

Additional guidelines for IPv6

The sending IP must have a PTR record (i.e., a reverse DNS of the sending 
IP) and it should match the IP obtained via the forward DNS resolution of 
the hostname specified in the PTR record. Otherwise, mail will be marked 
as spam or possibly rejected.


The sending domain should pass either SPF check or DKIM check. Otherwise, 
mail might be marked as spam.

---

I have both of these (PTR's RR has matching , and I have SPF (but not 
DKIM)).


I'm guessing that something on google's side is misinterpreting some data 
or other busted logic.  I meet all the requirements laid out, and have 
been sending mail to gmail addresses (via ipv6) since $forever.


Off-list replies are fine to minimize noise, and if there is an answer or 
any meaningful correlation I will reply on-list.  Thanks in advance for 
any info/feedback.


--
Brandon Applegate - CCIE 10273
PGP Key fingerprint:
830B 4802 1DD4 F4F9 63FE  B966 C0A7 189E 9EC0 3A74
"SH1-0151.  This is the serial number, of our orbital gun."

Re: OpenNTPProject.org

[Saku Ytti]

On (2014-01-14 08:35 -0800), Damian Menscher wrote:

> I see this as a form of BCP38, but imposed on networks by their transit
> providers, rather than done voluntarily.  It would be great if it could
> work, but I have doubts due to asymmetric routing announcements intended
> for traffic shaping.

Yes, I should have specified 'BCP38 in access networks' as being completely
unrealistic.
(We do BCP38 on all ports and verify programmatically, but I know it's not at
all practical solution globally for access).

ACL in transit port is completely harmless, no announcements are needed for
traffic to be accepted. There are very modest amount of transit ports globally
and each port will create segmentation to the spoofing domains having
immediate, significant effect on benefits of spoofed attacks.
RPF obviously is non-starter for reasons you stated.

> I'd expect that to take 20 years or more.  Even if new standards are
> defined, the old servers will only be removed when they physically fail.

It would have to be carried over UDP initially and that support probably would
have to live for 20 years. But new-l4-over-udp version could be deployable
rapidly.

I'm very optimistic that if we'd have useful L4 for DNS, significant portion
of relevant DNS servers could be upgraded rapidly to support it. We may be
able to use existing data for this, how many servers went from DNS source port
to random source port to add entropy to reduce poisoning attack chance?

Good portion of end users are running w7, w8, osx  updating itself
automatically, so end-user support could come automatically and not require
action from users. phones, tablets etc have short upgrade cycles anyhow.

Native-udp port could then be policed heavily, making reflected attacks
pay-off poor and motivates rest of the users to take actions needed for new
l4.

> My crazy proposal: get international agreement that sending spoofed packets

Agreed, crazy.

-- 
  ++ytti

Re: OpenNTPProject.org

[Paul Ferguson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 1/13/2014 11:18 PM, Saku Ytti wrote:

> On (2014-01-13 21:33 +), Bjoern A. Zeeb wrote:
> 
>>> BCP38!  I am always surprised when people need crypto if they
>>> fail the simple things.
> Saying that BCP38 is solution to the reflection attacks is not
> unlike 5 year old wishing nothing but world peace for christmas,
> endearing, but it's not going to change anything. BCP38 is
> completely unrealistic, many access networks are on autopilot,
> many don't have HW support for BCP38, one port configured has
> low-benefit, only that machine can stop attacking (but whole
> world).

That does *not* make it an unworthy goal, nor should it stop people
from encouraging it's implementation.

- - ferg (co-author of BCP38)


- -- 
Paul Ferguson
PGP Public Key ID: 0x54DC85B2

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlLVWXoACgkQKJasdVTchbIrtAD/T2bNNAgZOnnlniBPd6sEquxJ
v01mmrhJxFTIDFq7EIkA/3vQbiwtEwBeVyCtc3coEkz50zSDh3j9QQjT+TQWCNVs
=Al3Y
-END PGP SIGNATURE-

Re: [VoiceOps] (cross post) VoIP heat charts...

[Derek Andrew]

http://www.nanpa.com/nanp1/allutlzd.zip lists NPANXX and Ratecentre.

derek



On Mon, Jan 13, 2014 at 7:33 PM, Paul Timmins  wrote:

>
> On Jan 9, 2014, at 2:38 PM, Jay Ashworth  wrote:
>
> > - Original Message -
> >>
> >>
> >> Looking to "heat chart" where fraudelent calls are going.
> >
> > So you want to be able to feed "NPANXX Count" to something that will map
> > the call counts on a US map.
> >
> > You have anything that does NPANXX to H&V, or directly to Lat Lon,
> already?
> >
> > Cause that's the hard part.
>
> Telcodata has this available.
>
> city-county-zip-byratecenterTelcoData - Advanced Membership Area code,
> exchange, State, City, County, Zip - By Ratecenter (Requires Advanced
> Subscription)
>
>


-- 
Copyright 2014 Derek Andrew (excluding quotations)

+1 306 966 4808
Information and Communications Technology
University of Saskatchewan
Peterson 120; 54 Innovation Boulevard
Saskatoon,Saskatchewan,Canada. S7N 2V3
Timezone GMT-6

Typed but not read.

Re: OpenNTPProject.org

[Tony Finch]

Jared Mauch  wrote:
>
> 3) You want to upgrade NTP, or adjust your ntp.conf to include ‘limited’
> or ‘restrict’ lines or both.  (I defer to someone else to be an expert
> in this area, but am willing to learn :) )

There is useful guidance for Cisco, Juniper, and Unix here:

https://www.team-cymru.org/ReadingRoom/Templates/secure-ntp-template.html

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.