> From: Mark Tinka [mailto:mark.ti...@seacom.mu]
> Sent: Saturday, October 13, 2018 5:38 PM
>
> On 13/Oct/18 18:36, Mark Tinka wrote:
>
>
> We don't perform any ingress iBGP policy for RTBH anywhere in the network.
>
> Spoke too soon... with peering routers being the exception, as we tightly
>
On 13/Oct/18 23:01, Robert Raszuk wrote:
>
> This way of (D)DoS mitigation results with cutting the poor target
> completely out of the network ... So the attacker succeeded very well
> with your assistance as legitimate users can not any more reach the
> guy. Is it his fault that he got
On 13/Oct/18 22:41, Tim Warnock wrote:
> We match incoming routes tagged with RTBH from the RR and rewrite to the
> appropriate next-hop "/dev/null" by address family, which it sounds a lot
> like what you guys do.
>
> I would consider this to be "policy". Why would you not?
We do the above
Robert Raszuk wrote on 13/10/2018 22:01:
This way of (D)DoS mitigation results with cutting the poor target
completely out of the network ... So the attacker succeeded very well
with your assistance as legitimate users can not any more reach the
guy.
service providers usually care more about
Hi,
On Sat, Oct 13, 2018 at 11:01:28PM +0200, Robert Raszuk wrote:
> > Sounds standard practice.
>
> This way of (D)DoS mitigation results with cutting the poor target
> completely out of the network ... So the attacker succeeded very well with
> your assistance as legitimate users can not any
Tim Warnock wrote on 13/10/2018 21:41:
I would consider this to be "policy". Why would you not?
on ios, you can hack around this by setting the NHIP in the announcing
router to be an ip address which is directly routed to null0 on the RR
client, i.e. no explicit policy required. On XR, you
>
> Sounds standard practice.
>
This way of (D)DoS mitigation results with cutting the poor target
completely out of the network ... So the attacker succeeded very well with
your assistance as legitimate users can not any more reach the guy. Is it
his fault that he got attacked ?
Do you also do
> For us, customer-triggered RTBH is provided as standard for all eBGP sessions
> with customers. Once they send us the right community with their own
> routes, we just pass that community on to the RR's via iBGP. The RR will relay
> those routes to all other devices in the network, and as long as
On 13/Oct/18 18:36, Mark Tinka wrote:
>
>
> We don't perform any ingress iBGP policy for RTBH anywhere in the network.
Spoke too soon... with peering routers being the exception, as we
tightly control which routes are made available to the peering routers;
we don't hold a full table there.
On 12/Oct/18 14:15, adamv0...@netconsultings.com wrote:
> In order to avoid using ingress policy on iBGP session towards RRs I'm
> setting the dummy next-hop on export from the trigger VRF, but yes I had to
> add the dummy next-hop onto RRs for them to have a valid next-hop and could
> relay
On 12/Oct/18 14:12, adamv0...@netconsultings.com wrote:
> There are several possible attach-points that can be used to manipulate the
> iBGP route before it gets installed into RIB, (ibgp session/vrf
> import/BGP->RIB)
> Now would you say all of these are sort of in the inbound direction from
On 12/Oct/18 02:34, Robert Raszuk wrote:
> While we are a bit diverging from original topic and while indeed under
> very careful application there could be some use cases for outbound bgp
> policies even for ibgp I have never seen one to be applied inbound - which
> was the point of my
On 11/Oct/18 23:47, Robert Raszuk wrote:
>
> Decent bgp implementation should not allow iBGP learned routes to be
> subject to any bgp policy as doing so will easily result with
> inconsistent routing. So on this ground there can be bgp code path
> differences on how the routes are processed.
> James Bensley
> Sent: Friday, October 12, 2018 7:17 AM
>
>
>
> On 12 October 2018 02:14:03 BST, Tim Warnock wrote:
> >> -Original Message-
> >> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf
> >Of
> >> Robert Raszuk
> >> So for educational purposes could you
> Tim Warnock
> Sent: Friday, October 12, 2018 2:14 AM
>
> > -Original Message-
> > From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf
> > Of Robert Raszuk So for educational purposes could you describe some
> > real valid use cases to apply bgp policies on routes
On 12 October 2018 02:14:03 BST, Tim Warnock wrote:
>> -Original Message-
>> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf
>Of
>> Robert Raszuk
>> So for educational purposes could you describe some real valid use
>cases to
>> apply bgp policies on routes
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Robert Raszuk
> So for educational purposes could you describe some real valid use cases to
> apply bgp policies on routes *received* over IBGP ?
>
> Thx,
> Robert.
Setting local preference?
While we are a bit diverging from original topic and while indeed under
very careful application there could be some use cases for outbound bgp
policies even for ibgp I have never seen one to be applied inbound - which
was the point of my comment.
So for educational purposes could you describe
Thu, Oct 11, 2018 at 11:47:27PM +0200, Robert Raszuk:
> Decent bgp implementation should not allow iBGP learned routes to be
> subject to any bgp policy as doing so will easily result with inconsistent
> routing.
That is not entirely true; yes, one must be careful when applying policy
to internal
> There is nothing to stop me creating a horribly complex iBGP policy
Decent bgp implementation should not allow iBGP learned routes to be
subject to any bgp policy as doing so will easily result with inconsistent
routing. So on this ground there can be bgp code path differences on how
the routes
On Thu, 11 Oct 2018 at 15:30, Robert Raszuk wrote:
> I think the difference Mark may have in mind that iBGP routes say from RR are
> advertised from RR's control plane. Many RRs today are just x86 control plane
> boxes with no forwarding.
>
> On the other hand number of implementations before
On 11/Oct/18 16:30, Robert Raszuk wrote:
>
> James,
>
> I think the difference Mark may have in mind that iBGP routes say from
> RR are advertised from RR's control plane. Many RRs today are just x86
> control plane boxes with no forwarding.
>
> On the other hand number of implementations
On 11/Oct/18 15:56, James Bensley wrote:
> Hi Mark,
>
> What makes you think there would be a difference in time to load eBGP learned
> routes vs. iBGP learned routes? Something from personal experience?
>
> Am I being naive here, I'd expect them to be the same? An UPDATE from an eBGP
> or
> Hi Mark,
>
> What makes you think there would be a difference in time to load eBGP
> learned routes vs. iBGP learned routes? Something from personal experience?
James,
I think the difference Mark may have in mind that iBGP routes say from RR
are advertised from RR's control plane. Many RRs
On 5 October 2018 08:25:35 BST, Mark Tinka wrote:
>
>
>On 5/Oct/18 09:17, Robert Hass wrote:
>
>> Hi
>> I'm looking for share experiences regarding time needed to program
>full DFZ
>> table (710K IPv4 prefixes) on NCS 5500 boxes.
>>
>> Right now we testing competitors (Jericho based boxes) and
Nicolas covered the RIB speed in the blog as well, and had varying results, but
on average about 10s for today's full table. The bottleneck in the operation
is usually the advertising router, not the local router populating the RIB. I
don't think there was a test where the FIB took more than
On Fri, 5 Oct 2018 at 08:24, Łukasz Bromirski wrote:
>
> Robert,
>
> > On 5 Oct 2018, at 09:17, Robert Hass wrote:
> >
> > Hi
> > I'm looking for share experiences regarding time needed to program full DFZ
> > table (710K IPv4 prefixes) on NCS 5500 boxes.
> >
> > Right now we testing competitors
On 5/Oct/18 09:17, Robert Hass wrote:
> Hi
> I'm looking for share experiences regarding time needed to program full DFZ
> table (710K IPv4 prefixes) on NCS 5500 boxes.
>
> Right now we testing competitors (Jericho based boxes) and results are not
> impressive - time needed to program is aroud
Hi Rob,
Please have a look at Niclas blog post about the NCS5500, it should answer your
question:
https://xrdocs.io/cloud-scale-networking/tutorials/ncs5500-fib-programming-speed/
Best Regards
Ted
Sent while walking
On 5 Oct 2018, at 09:18, Robert Hass
mailto:robh...@gmail.com>> wrote:
Hi
Robert,
> On 5 Oct 2018, at 09:17, Robert Hass wrote:
>
> Hi
> I'm looking for share experiences regarding time needed to program full DFZ
> table (710K IPv4 prefixes) on NCS 5500 boxes.
>
> Right now we testing competitors (Jericho based boxes) and results are not
> impressive - time needed
Hi
I'm looking for share experiences regarding time needed to program full DFZ
table (710K IPv4 prefixes) on NCS 5500 boxes.
Right now we testing competitors (Jericho based boxes) and results are not
impressive - time needed to program is aroud 2min 30sec up to 3min.
How fast NCS 5500 is handing
31 matches
Mail list logo
