I have personally helped roll PfR out in production Internet w/3945's on
15. code. 1 master and 2 border serving ISP links from XO/ATT. We sent
community values to ISP's that manipulated AS Path for inbound handling.
Even this is somewhat limiting based on number of /24 subnets we could use
to perform ingress load balancing and came down to many cycles of
engineering and test time. If PfR solution is viewed holistically and
encompasses campus/DC in an enterprise, it has huge value and worth the
investment. It opens up a whole new level of nerd nobs to control specific
traffic flows. Brian has some great videos that take a step by step
approach and helped both myself and colleague start elementary and add in
necessary leves of complexity.
Again have to throw in disclaimer UNLESS the IP architecture has been
thought to provide some sort of LB both outbound and
(more importantly inbound) w/ISP, it has minimal effect and in a sense has
diminishing returns on the effort when compared to just adding 5 lines (or
so) of code to track and take action to shut neighbor/interface.
How about OnePK ;)
Marc Edwards
CCIE #38259
On Sat, Jun 29, 2013 at 7:06 AM, Tom Kacprzynski <tom.kac_at_gmail.com> wrote:
> 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
>
> _______________________________________________________________________
> 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 - 07:51:40 ART
This archive was generated by hypermail 2.2.0 : Mon Jul 01 2013 - 06:58:42 ART