Re: OT - BGP Problem

Unless your ISPs are managing your edge routers you should be able to run
PfR with any ISP..even ATT :) . All it does is it controls the path using
BGP attributes or statics redistributed into IGP. Most service providers
like to manage the MPLS CE, but not the multihomed gateway's BGP connection
to the Internet.

On Sat, Jun 29, 2013 at 1:52 AM, Joseph L. Brunner
<joe_at_affirmedsystems.com>wrote:

> Wow. You guys must have some great ISP's - do share!!!
>
> I have Level3 and ATT - the world's largest - and they are not technically
> competant enough to do PfR with jeez - one remembered my mac address for 4
> hours when I upgraded edge routers... I had to TELL THEM what the problem
> was, and wait for them to figure out how to fix it...
>
> PfR you Say? Me no think so!!!
>
> Or do you have INE as your ISP!
>
> Lol
>
>
> *From*: Tom Kacprzynski [mailto:tom.kac_at_gmail.com]
> *Sent*: Friday, June 28, 2013 10:43 PM
> *To*: Joseph L. Brunner
> *Cc*: Brian Dennis <bdennis_at_ine.com>; gaston brait <gbrait_at_hotmail.com>;
> ccielab_at_groupstudy.com <ccielab_at_groupstudy.com>
> *Subject*: Re: OT - BGP Problem
>
> I agree with Brian on this one. IP SLA will not cover all destinations.
> The issue here is on the data plane and not on the control plane. Routing
> adj and route advertisements are not changing. The cause could be because
> of summarization by the carrier or blackholing on their network. Since it's
> an ISP dual homed configuration I doubt there is any summarization or
> default routes going on. The carrier could be using MPLS to transport
> Internet traffic. If that's the case then any issue synchronizing IGP with
> LDP will cause a potential blackholing problem. BGP will not see it and
> maintain adj and same routes.
>
> Using PfR, border routers are looking at all traffic with netflow. If TCP
> traffic for some destinations are coming up with timeouts they will try to
> move those aggregated networks over to another path. That is the best
> scalable solution.
>
> Regards,
>
> Tom Kacprzynski
> CCIE#36159
>
>
> On Fri, Jun 28, 2013 at 12:15 PM, Joseph L. Brunner <
> joe_at_affirmedsystems.com> wrote:
>
>> Brian -
>>
>> I believe (correct me if I'm wrong)
>>
>> He is trying to solve the problem of dirtbag ISP's with their own
>> blackhole issues not being able to route him anywhere, but of course, since
>> they are running 15 year old routers they cant quickly withdrawl the routes
>> they sent him in a time that's good for his failover policy.
>>
>> We use sla, track obj and tie the route to the BGP neighbor (we are ebgp
>> multihoping to) to that track obj. for instance, if my edge routers cant
>> ping 8.8.8.8 or 8.8.4.4 I would rather kill my advertisement to them and
>> any routes known via that neighbor...
>>
>> thanks
>>
>> -----Original Message-----
>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
>> Brian Dennis
>> Sent: Thursday, June 27, 2013 4:49 PM
>> To: gaston brait; ccielab_at_groupstudy.com
>> Subject: Re: OT - BGP Problem
>>
>> You may want to look into using PfR as it has features that can deal
>> with your exact problem. In particular with PfR you are looking to monitor
>> passive reachability* which is done in PfR by looking for repeated SYNs
>> without a SYN/ACK for TCP sessions. Of course this will only work if TCP
>> traffic is flowing through the border routers which shouldn't be a problem.
>>
>> The reason this solution is better than manually configuring IP SLA is
>> that it will reroute traffic even when Carrier A just has a partial outage
>> by rerouting the traffic Carrier A can't reach to Carrier B and not just a
>> full outage with Carrier A. Manually configuring IP SLA needs a predefined
>> destination where PfR using passive reachability will detect the
>> destinations automatically that are unreachable. You can even mix passive
>> reachability with active reachability (predefined destinations using IP
>> SLA) if you like.
>>
>>
>> * There is a short and long term passive reachability stat that is
>> collected if you want to reroute when the 5 minute average (short term)
>> breaks above a predefined percentage of the 60 minute average (long term).
>>
>>
>> --
>> Brian Dennis, CCIEx5 #2210 (R&S/ISP-Dial/Security/SP/Voice)
>> bdennis_at_ine.com
>>
>> INE, Inc.
>> http://www.INE.com
>>
>>
>>
>>
>> On 6/27/13 9:05 AM, "gaston brait" <gbrait_at_hotmail.com> wrote:
>>
>> >I work for a company with 2 datacenter connected via a dark fiber and
>> >they have an IBGP peership between them.Both datacenter have EBGP peers
>> >to 2 different carriers. Carrier A is the preferred one.The problem is
>> >that we have had several incidents where carrier A has problems on
>> >their cloud, but the BGP peer with us never goes down and we continue
>> >to recieve prefix from them.When this happens we lose all internet
>> >connectivity and we need to manually switch to carrier B.Is there any
>> >way to automate this process? Maybe track an internet route and if it
>> >is unreachable bring the peer down?
>> >Thanks,
>> >Regards,
>> >Gaston
>> >
>> >
>> >Blogs and organic groups at http://www.ccie.net
>> >
>> >_______________________________________________________________________
>> >Subscription information may be found at:
>> >http://www.groupstudy.com/list/CCIELab.html
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Sat Jun 29 2013 - 09:06:13 ART