Re: OT - BGP Problem

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<mailto: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> [mailto: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<mailto: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<mailto:bdennis_at_ine.com>
INE, Inc.
http://www.INE.com
On 6/27/13 9:05 AM, "gaston brait" <gbrait_at_hotmail.com<mailto: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