Re: [c-nsp] BGP routes disappearing

[Hank Nussbacher via cisco-nsp]

On 10/06/2024 11:20, Saku Ytti wrote:

I don't think there is enough information here to understand the
problem.


Since you asked:

Router B is exaBGP sending announcements to router A (128.139.220.90).
192.0.2.1 is a GigE interface on router A.  I want to null0 all traffic 
which is easy to do but I also want a record of every attempt someone 
tried to reach one of these null0 routes.  Think of something like:

https://www.team-cymru.com/ty/cisco-router-traditional-bogons

So I want an ACL like:
ipv4 access-list log-traffic
 10 permit ipv4 any any log

But an ACL can't be placed on a null0 interface nor on a loopback 
interface so I created a fake VLAN and route the traffic there (to 
192.0.2.1), and there I can install an ACL and log the traffic:
RP/0/RSP0/CPU0:2024 Jun 10 10:27:44 : ipv4_acl_mgr[343]: 
%ACL-IPV4_ACL-6-IPACCESSLOGP : access-list log-traffic (10) deny udp 
128.139.6.11(40652) -> 192.0.2.1(53), 1 packet


In any event, I solved it.

Thanks,
Hank




So you have

RouterA - RouterB

RouterA is 192.0.2.1/24 RouterB is 128.139.197.146

RouterB advertises bunch of /32s to routerA, with next-hop
192.0.2.1?

This seems nonsensical to me, where is routerA supposed to send the 
packets? So I must be misunderstanding what you're doing.


But you probably can look at the disappeared routers in adjRIB for 
some clue, or turn on debugging on BGP, to see why they are 
invalidated.


I'm expecting invalid next-hop, next-hop loop or BGP session itself 
has the most-specific route to the BGP session over the BGP session.





On Mon, 10 Jun 2024 at 11:09, Hank Nussbacher via cisco-nsp 
 wrote:


I have a simple iBGP peer defined as follows:

neighbor 128.139.197.146 remote-as 378 update-source Loopback0 
address-family ipv4 unicast



I have a GigE interface defined as:

interface GigabitEthernet0/0/0/43.1 ipv4 address 192.0.2.1
255.255.255.0 encapsulation dot1q 1

This iBGP peer feeds me /32s with nexthop set as 192.0.2.1/32.
Problem is all routes disappear.

NeighborSpkAS MsgRcvd MsgSent   TblVer  InQ OutQ
Up/Down St/PfxRcd 128.139.197.146   0   378   10437  627880
1006011900 00:15:41  0


If the feed sets the IP to 192.0.2.2 then the BGP routes appear in
the routing table.  If I then change the IP address on interface 
GigabitEthernet0/0/0/43.1 to 192.0.2.2 then the routes disappear as

well after having made it into the routing table.


I am obviously missing something very simple.  Clue-bat welcome.


Thanks,

Hank



___ cisco-nsp mailing
list  cisco-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/cisco-nsp archive at

http://puck.nether.net/pipermail/cisco-nsp/







___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP routes disappearing

[Brian Turnbow via cisco-nsp]

Hi Hank

If I understand correctly you are trying to send bgp routes to a router
that have a next hop local to the router?

I think this would contrast with the route selection process and not be
accepted.. as  the route would not be installable. i.e. The router would
route it to itself on the Ge interface  and then ? route it to itself in a
loop?

Maybe I am misunderstanding ...

Brian

Brian Turnbow
+39 02 6706800
[image: CDLAN SPA]
[image: CDLAN SPA]   |  [image: CDLAN SPA -
LinkedIn] 



Il giorno lun 10 giu 2024 alle ore 10:09 Hank Nussbacher via cisco-nsp <
cisco-nsp@puck.nether.net> ha scritto:

> I have a simple iBGP peer defined as follows:
>
>   neighbor 128.139.197.146
>remote-as 378
>update-source Loopback0
>address-family ipv4 unicast
>
>
> I have a GigE interface defined as:
>
> interface GigabitEthernet0/0/0/43.1
>   ipv4 address 192.0.2.1 255.255.255.0
>   encapsulation dot1q 1
>
> This iBGP peer feeds me /32s with nexthop set as 192.0.2.1/32. Problem
> is all routes disappear.
>
> NeighborSpkAS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down
> St/PfxRcd
> 128.139.197.146   0   378   10437  627880 1006011900
> 00:15:41  0
>
>
> If the feed sets the IP to 192.0.2.2 then the BGP routes appear in the
> routing table.  If I then change the IP address on interface
> GigabitEthernet0/0/0/43.1 to 192.0.2.2 then the routes disappear as well
> after having made it into the routing table.
>
>
> I am obviously missing something very simple.  Clue-bat welcome.
>
>
> Thanks,
>
> Hank
>
>
>
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP routes disappearing

[Hank Nussbacher via cisco-nsp]

On 10/06/2024 11:05, Hank Nussbacher wrote:

Ignore.  There was an ACL on GigabitEthernet0/0/0/43.1  that blocked the 
traffic.

Nothing like solving your own issues.

-Hank


I have a simple iBGP peer defined as follows:

 neighbor 128.139.197.146
  remote-as 378
  update-source Loopback0
  address-family ipv4 unicast


I have a GigE interface defined as:

interface GigabitEthernet0/0/0/43.1
 ipv4 address 192.0.2.1 255.255.255.0
 encapsulation dot1q 1

This iBGP peer feeds me /32s with nexthop set as 192.0.2.1/32. Problem 
is all routes disappear.


Neighbor    Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  
St/PfxRcd
128.139.197.146   0   378   10437  627880 10060119    0    0 
00:15:41  0



If the feed sets the IP to 192.0.2.2 then the BGP routes appear in the 
routing table.  If I then change the IP address on interface 
GigabitEthernet0/0/0/43.1 to 192.0.2.2 then the routes disappear as 
well after having made it into the routing table.



I am obviously missing something very simple.  Clue-bat welcome.


Thanks,

Hank





___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP routes disappearing

[Gert Doering via cisco-nsp]

Hi,

On Mon, Jun 10, 2024 at 11:05:18AM +0300, Hank Nussbacher via cisco-nsp wrote:
> If the feed sets the IP to 192.0.2.2 then the BGP routes appear in the
> routing table.  If I then change the IP address on interface
> GigabitEthernet0/0/0/43.1 to 192.0.2.2 then the routes disappear as well
> after having made it into the routing table.

Why would you want routes pointing to *your own* IP?

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP routes disappearing

[Saku Ytti via cisco-nsp]

I don't think there is enough information here to understand the problem.

So you have

RouterA - RouterB

RouterA is 192.0.2.1/24
RouterB is 128.139.197.146

RouterB advertises bunch of /32s to routerA, with next-hop 192.0.2.1?

This seems nonsensical to me, where is routerA supposed to send the
packets? So I must be misunderstanding what you're doing.

But you probably can look at the disappeared routers in adjRIB for
some clue, or turn on debugging on BGP, to see why they are
invalidated.

I'm expecting invalid next-hop, next-hop loop or BGP session itself
has the most-specific route to the BGP session over the BGP session.




On Mon, 10 Jun 2024 at 11:09, Hank Nussbacher via cisco-nsp
 wrote:
>
> I have a simple iBGP peer defined as follows:
>
>   neighbor 128.139.197.146
>remote-as 378
>update-source Loopback0
>address-family ipv4 unicast
>
>
> I have a GigE interface defined as:
>
> interface GigabitEthernet0/0/0/43.1
>   ipv4 address 192.0.2.1 255.255.255.0
>   encapsulation dot1q 1
>
> This iBGP peer feeds me /32s with nexthop set as 192.0.2.1/32. Problem
> is all routes disappear.
>
> NeighborSpkAS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down
> St/PfxRcd
> 128.139.197.146   0   378   10437  627880 1006011900
> 00:15:41  0
>
>
> If the feed sets the IP to 192.0.2.2 then the BGP routes appear in the
> routing table.  If I then change the IP address on interface
> GigabitEthernet0/0/0/43.1 to 192.0.2.2 then the routes disappear as well
> after having made it into the routing table.
>
>
> I am obviously missing something very simple.  Clue-bat welcome.
>
>
> Thanks,
>
> Hank
>
>
>
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/



-- 
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] BGP routes disappearing

[Hank Nussbacher via cisco-nsp]

I have a simple iBGP peer defined as follows:

 neighbor 128.139.197.146
  remote-as 378
  update-source Loopback0
  address-family ipv4 unicast


I have a GigE interface defined as:

interface GigabitEthernet0/0/0/43.1
 ipv4 address 192.0.2.1 255.255.255.0
 encapsulation dot1q 1

This iBGP peer feeds me /32s with nexthop set as 192.0.2.1/32. Problem 
is all routes disappear.


Neighbor    Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  
St/PfxRcd
128.139.197.146   0   378   10437  627880 10060119    0    0 
00:15:41  0



If the feed sets the IP to 192.0.2.2 then the BGP routes appear in the 
routing table.  If I then change the IP address on interface 
GigabitEthernet0/0/0/43.1 to 192.0.2.2 then the routes disappear as well 
after having made it into the routing table.



I am obviously missing something very simple.  Clue-bat welcome.


Thanks,

Hank



___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP Extended Communities

[Mark Tinka via cisco-nsp]

On 9/10/23 21:22, Mohammad Khalil via cisco-nsp wrote:


Greetings
Hope all is well.

I need to check if Juniper's BGP extended community settings are compatible 
with Cisco's BGP extended community settings.
Is it possible to intercommunicate Juniper's BGP extended community with Cisco 
BGP extended community ?


We use them for l3vpn VRF's between both vendors. Works standard.

Mark.

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] BGP Extended Communities

[Mohammad Khalil via cisco-nsp]

Greetings
Hope all is well.

I need to check if Juniper's BGP extended community settings are compatible 
with Cisco's BGP extended community settings.
Is it possible to intercommunicate Juniper's BGP extended community with Cisco 
BGP extended community ?
Defining BGP Extended Communities for Use in Routing Policy Match Conditions
https://www.juniper.net/documentation/us/en/software/junos/routing-policy/topics/concept/policy-defining-bgp-communities-and-extended-communities-for-use-in-routing-policy-match-conditions.html#understanding-how-to-define-bgp-communities-and-extended-communities__d53003e589

Am using C8500
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP Routes

[Mohammad Khalil via cisco-nsp]

Thanks Saku and Gert for the kind replies , well received.

From: cisco-nsp  on behalf of Gert Doering 
via cisco-nsp 
Sent: Sunday, March 12, 2023 9:58 PM
To: Saku Ytti 
Cc: cisco-nsp@puck.nether.net 
Subject: Re: [c-nsp] BGP Routes

Hi,

On Sun, Mar 12, 2023 at 08:51:36PM +0200, Saku Ytti via cisco-nsp wrote:
> You might want add-path or best-external for predictability and
> improved convergence time.

Last time we did best-external with ASR9k it only worked in a useful
way if you are using labeled-unicast.  That was many years ago, so
it might have been fixed, but "test and expect surprises".

In our case, the effect was that the local router that exported
best-external to its peers was also installing the best-external
path into its local FIB, as a load-shared path(!).

So we had packets come in from uplink, the "good" path was "send
internal over our network", but half the packets got balanced
via the "best-external" path.  Intereresting isseus ensued.

To me this never made sense but TAC claimed "this is the way it is,
we're not considering this a bug, use labeled-unicast, then it will
work fine".  As we didn't use LU, I could not verify this.

gert
--
"If was one thing all people took for granted, was conviction that if you
 feed honest figures into a computer, honest figures come out. Never doubted
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP Routes

[Gert Doering via cisco-nsp]

Hi,

On Sun, Mar 12, 2023 at 08:51:36PM +0200, Saku Ytti via cisco-nsp wrote:
> You might want add-path or best-external for predictability and
> improved convergence time.

Last time we did best-external with ASR9k it only worked in a useful
way if you are using labeled-unicast.  That was many years ago, so
it might have been fixed, but "test and expect surprises".

In our case, the effect was that the local router that exported
best-external to its peers was also installing the best-external
path into its local FIB, as a load-shared path(!).

So we had packets come in from uplink, the "good" path was "send
internal over our network", but half the packets got balanced 
via the "best-external" path.  Intereresting isseus ensued.

To me this never made sense but TAC claimed "this is the way it is,
we're not considering this a bug, use labeled-unicast, then it will
work fine".  As we didn't use LU, I could not verify this.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP Routes

[Saku Ytti via cisco-nsp]

On Sun, 12 Mar 2023 at 20:50, Mark Tinka via cisco-nsp
 wrote:

> ASR9K1 has more routes with better paths toward destinations via its
> upstream than ASR9K2 does.

Or at worst, race.

You might want add-path or best-external for predictability and
improved convergence time.

-- 
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP Routes

[Mohammad Khalil via cisco-nsp]

Thanks for the hint , actually this is what I have been thinking of but was 
wondering how can I get more details or samples about that as a matter of proof.

From: cisco-nsp  on behalf of Mark Tinka via 
cisco-nsp 
Sent: Sunday, March 12, 2023 9:49 PM
To: cisco-nsp@puck.nether.net 
Subject: Re: [c-nsp] BGP Routes



On 3/12/23 20:21, Mohammad Khalil via cisco-nsp wrote:

> Greetings
> I have two ASR9K connected to different providers (Uplinks).
> I am receiving around 90K routes from each provider , as well , I have iBGP 
> between the ASR9K.
> What am noticing is that ASR9K1 is advertising around 87K to ASR9K2 where 
> ASR9Ks is advertising around 7K routes.
> Any hints?

A case of active routes being announced to neighbors, where active
routes = best routes/paths as seen from each router's point of view.

ASR9K1 has more routes with better paths toward destinations via its
upstream than ASR9K2 does.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP Routes

[Mark Tinka via cisco-nsp]

On 3/12/23 20:21, Mohammad Khalil via cisco-nsp wrote:


Greetings
I have two ASR9K connected to different providers (Uplinks).
I am receiving around 90K routes from each provider , as well , I have iBGP 
between the ASR9K.
What am noticing is that ASR9K1 is advertising around 87K to ASR9K2 where 
ASR9Ks is advertising around 7K routes.
Any hints?


A case of active routes being announced to neighbors, where active 
routes = best routes/paths as seen from each router's point of view.


ASR9K1 has more routes with better paths toward destinations via its 
upstream than ASR9K2 does.


Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP Routes

[Matt Illingworth via cisco-nsp]

I'm assuming the ASR only advertising 7k routes knows the other ASR already
has a better route to those prefixes based on what it is recieving from it.

As a test if you pull the uplink or do some pretending on import on ASR9K1
then ASR9K2 should advertise the full 90k on the ibgp session.

Matt




On Sun, 12 Mar 2023, 18:22 Mohammad Khalil via cisco-nsp, <
cisco-nsp@puck.nether.net> wrote:

> Greetings
> I have two ASR9K connected to different providers (Uplinks).
> I am receiving around 90K routes from each provider , as well , I have
> iBGP between the ASR9K.
> What am noticing is that ASR9K1 is advertising around 87K to ASR9K2 where
> ASR9Ks is advertising around 7K routes.
> Any hints?
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] BGP Routes

[Mohammad Khalil via cisco-nsp]

Greetings
I have two ASR9K connected to different providers (Uplinks).
I am receiving around 90K routes from each provider , as well , I have iBGP 
between the ASR9K.
What am noticing is that ASR9K1 is advertising around 87K to ASR9K2 where 
ASR9Ks is advertising around 7K routes.
Any hints?
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] BGP in the lab - v4 & v6 live feeds from Europe

[Łukasz Bromirski]

Cisco NSPers,

If you’re looking for live, full BGP v4 & v6 feed for your lab or
a bit of testing before going live, I just shared a short post on
how to get it:

https://lukasz.bromirski.net/post/bgp-w-labie-3/

Happy BGPing,
-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP - advertising default route to Branch offices

[James Bensley]

On Thu, 13 Aug 2020 at 01:24, Yham  wrote:
>
> Hello Gentlemen,

There's really no need to exclude women is there?

> Can anyone please tell which is considered a best practice when it comes to
> the advertising default route? If any vendor documentation addresses this,
> please feel free to share.

I'm not sure if there is a best practice here. My problem with "best
practices" is that they tend to draw people to the conclusion that
there is a single best way (or very small number of ways) of doing
something. I don't approve of "one size fits all" approaches because
your requirements aren't my requirements. The real question here, and
the info you need to provide the community in order to get the most
optimal response/advice is: what are you selling / what is your
requirement?

> I have 100+ branch offices peering BGP with Core and I need to advertise
> the default route (only) to them. Core switches are receiving the default
> route via eBGP from upstream devices. I can think of two ways to advertise
> the default route as follows
>
> 1- advertise/pass on the default route that core switches receive from
> upstream edge devices. Along with that add a static default route pointing
> to null0 with higher administrative distance and redistribute into BGP.
> that way if for any reason upstream edge devices stop advertising the
> default route, the static default route will kick in.

If your aggregation devices learn a default route via BGP from an
upstream device, why have the static null0 route? With the static
null0 route, if you lose the upstream BGP route you may pull traffic
from your remote devices, to your aggregation device which then drops
the traffic because it has no upstream route. If each site is sending
the aggregation device it's LAN prefix(es) then upstream routing to
the Internet would be lost in this case, but inter-site traffic would
still work. So what is the requirement here, to maintain inter-site
connectivity when upstream routing is dead, and only failover to the
other agg device when the first agg device is completely dead, or
failover over to your other aggregation device as soon as the default
route is lost?

> 2 - default-originate command under every BGP neighborship. I have 100+
> neighbors so configure this command for all.

^ If you have 100 BGP neighbours to configure, you possibly have 100
interfaces to configure, and 100 CPEs/remote devices to configure,
this extra bit of config won't change the configuration complexity
from O(1). Regardless of the config overhead, in this 2nd scenario
which involves re-advertising the default route from the upstream
device to the downstream remote devices without having a local static
route, seems to me to allow for failover between aggregation devices
when the default route is lost from an agg device's upstream device.
Is this a requirement for you? If so, then I'd choose roughly this
path.

I say roughly, because as others have said, you could in fact simply
place two static routes on your remote devices, one to each agg device
and then you can remove the complexity of BGP from them. Again, what
is your requirement here? If you don't expect to advertise additional
routes between agg devices and remote devices in the future, I'd
choose the static route method. If you do, I'd then choose BGP. I see
an IGP protocol like OSPF/ISIS/EIGRP as a last resort and/or for some
special exceptions.

Hopefully that helps.

Cheers,
James.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP - advertising default route to Branch offices

[Karsten Thomann via cisco-nsp]

--- Begin Message ---
Am Donnerstag, 13. August 2020, 11:15:00 schrieb Nick Hilliard:
> Gert Doering wrote on 13/08/2020 08:40:
> > Peer-groups are an amazing invention.
> 
> + if it's 100+ neighbours, then automation would be useful.
If you can't automate peer-group with bgp listen range could also be useful.

> 
> Nick
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

--- End Message ---
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP - advertising default route to Branch offices

[Nick Hilliard]

Gert Doering wrote on 13/08/2020 08:40:

Peer-groups are an amazing invention.


+ if it's 100+ neighbours, then automation would be useful.

Nick
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP Multipath

[James Bensley]

On Thu, 13 Aug 2020 at 00:56, Yham  wrote:
>
> Hello Gentlemen,

There are women on this list too.

> Router A and B are iBGP
> neigbors in ASN100 and a prefix 10.0.0.0/8 attache to both. Router C and D
> are iBGP neighbors in ASN100. Router A has an eBGP with Router C and Router
> B has an eBGP neighborship with Router D.

How does Router A have an eBGP session with Router C if they have the same ASN?

James.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP - advertising default route to Branch offices

[Gert Doering]

Hi,

On Wed, Aug 12, 2020 at 08:20:39PM -0400, Yham wrote:
> 2 - default-originate command under every BGP neighborship. I have 100+
> neighbors so configure this command for all.

Peer-groups are an amazing invention.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP Multipath

[Robert Raszuk]

You need eiBGP multipath for this.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-s/irg-15-s-book/irg-eibgp-multipath-for-nonvrf-interfaces.html


Thx,
R.

On Thu, Aug 13, 2020 at 1:54 AM Yham  wrote:

> Hello Gentlemen,
>
> I wanted to configure whether BGP multipath feature work for/install a
> route learned from the same AS but eBGPand iBGP neighbors.
>
> for example, I have four routers A, B, C & D. Router A and B are iBGP
> neigbors in ASN100 and a prefix 10.0.0.0/8 attache to both. Router C and D
> are iBGP neighbors in ASN100. Router A has an eBGP with Router C and Router
> B has an eBGP neighborship with Router D.
> Now Router A receives prefix 10.0.0.0/8 from Router C via eBGP and from
> Router B via iBGP. In this scenario, Router A install the prefix in routing
> table that learned from Router C because it learned via eBGP. So the
> question is can I have both eBGPand iBGP paths install in the routing table
> with the help of multipath feature? I tried but it didn't work.
>
> In a nutshell, i wanted to ask if Multipath work for a prefix that being
> learned from eBGP and iBGP?
> From my understanding, all the best path criteria have to tie before
> multipath comes in picture.
>
> Regards
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP - advertising default route to Branch offices

[Saku Ytti]

On Thu, 13 Aug 2020 at 03:25, Yham  wrote:

> Can anyone please tell which is considered a best practice when it comes to
> the advertising default route? If any vendor documentation addresses this,
> please feel free to share.

In my opinion there is never a need to carry default route in dynamic
routing protocols, it's always inferior solution to static.

In this particular case, two options

1) BGP
a) Advertise some candidate route from BGP (like your PA aggregate,
which you originate from stable backbone boxes)
b) Recursive static default route in branch routers pointing to the PA
aggregate as next-hop

2) IGP
a) have loopback42 in every LSR/P box with same IP address, which you add to IGP
b) Recursive static default route in branch routers pointing to the
loop42 address as next-hop

In both cases isolated edge won't blackhole the the branch by
advertising default it doesn't have as well as you'll always choose
closest working exit.


-- 
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP - advertising default route to Branch offices

[Yham]

Thanks Mike for the input.

Its bgp end to end (branch switches <-bgp-> core switches <-bgp-> edge
devices). branch switches dual home to two core switches.

On Wed, Aug 12, 2020 at 9:31 PM Mike  wrote:

> On 8/12/20 5:20 PM, Yham wrote:
> > Hello Gentlemen,
> > I have 100+ branch offices peering BGP with Core and I need to advertise
> > the default route (only) to them. Core switches are receiving the default
> > route via eBGP from upstream devices. I can think of two ways to
> advertise
> > the default route as follows
> >
> > 1- advertise/pass on the default route that core switches receive from
> > upstream edge devices. Along with that add a static default route
> pointing
> > to null0 with higher administrative distance and redistribute into BGP.
> > that way if for any reason upstream edge devices stop advertising the
> > default route, the static default route will kick in.
> > 2 - default-originate command under every BGP neighborship. I have 100+
> > neighbors so configure this command for all.
> >
> > Can anyone please tell which is considered a best practice when it comes
> to
> > the advertising default route? If any vendor documentation addresses
> this,
> > please feel free to share.
> >
> Hello
>
> This really sounds like OSPF may have been a better choice, IMHO.
>
> Do you have more than one link back to core from each site? If not, then
> why not just stick with/use a static default? Easier to configure and
> nearly goof-proof.
>
> Otherwise, I would think that 'default-originate' would be the better
> choice under each neighborship.
>
> Mike-
>
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP - advertising default route to Branch offices

[Mike]

On 8/12/20 5:20 PM, Yham wrote:
> Hello Gentlemen,
> I have 100+ branch offices peering BGP with Core and I need to advertise
> the default route (only) to them. Core switches are receiving the default
> route via eBGP from upstream devices. I can think of two ways to advertise
> the default route as follows
>
> 1- advertise/pass on the default route that core switches receive from
> upstream edge devices. Along with that add a static default route pointing
> to null0 with higher administrative distance and redistribute into BGP.
> that way if for any reason upstream edge devices stop advertising the
> default route, the static default route will kick in.
> 2 - default-originate command under every BGP neighborship. I have 100+
> neighbors so configure this command for all.
>
> Can anyone please tell which is considered a best practice when it comes to
> the advertising default route? If any vendor documentation addresses this,
> please feel free to share.
>
Hello

This really sounds like OSPF may have been a better choice, IMHO.

Do you have more than one link back to core from each site? If not, then
why not just stick with/use a static default? Easier to configure and
nearly goof-proof.

Otherwise, I would think that 'default-originate' would be the better
choice under each neighborship.

Mike-

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] BGP - advertising default route to Branch offices

[Yham]

Hello Gentlemen,
I have 100+ branch offices peering BGP with Core and I need to advertise
the default route (only) to them. Core switches are receiving the default
route via eBGP from upstream devices. I can think of two ways to advertise
the default route as follows

1- advertise/pass on the default route that core switches receive from
upstream edge devices. Along with that add a static default route pointing
to null0 with higher administrative distance and redistribute into BGP.
that way if for any reason upstream edge devices stop advertising the
default route, the static default route will kick in.
2 - default-originate command under every BGP neighborship. I have 100+
neighbors so configure this command for all.

Can anyone please tell which is considered a best practice when it comes to
the advertising default route? If any vendor documentation addresses this,
please feel free to share.

Regards
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] BGP Multipath

[Yham]

Hello Gentlemen,

I wanted to configure whether BGP multipath feature work for/install a
route learned from the same AS but eBGPand iBGP neighbors.

for example, I have four routers A, B, C & D. Router A and B are iBGP
neigbors in ASN100 and a prefix 10.0.0.0/8 attache to both. Router C and D
are iBGP neighbors in ASN100. Router A has an eBGP with Router C and Router
B has an eBGP neighborship with Router D.
Now Router A receives prefix 10.0.0.0/8 from Router C via eBGP and from
Router B via iBGP. In this scenario, Router A install the prefix in routing
table that learned from Router C because it learned via eBGP. So the
question is can I have both eBGPand iBGP paths install in the routing table
with the help of multipath feature? I tried but it didn't work.

In a nutshell, i wanted to ask if Multipath work for a prefix that being
learned from eBGP and iBGP?
>From my understanding, all the best path criteria have to tie before
multipath comes in picture.

Regards
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP Maximum Prefix limit on Edge routers

[Aaron]

Absolutely. Make sure to add enough overhead, 25%, so you do not keep
getting warning messages in the logs.
These are the defaults for XR

To prevent a peer from flooding BGP with advertisements, a limit is
placed on the number of prefixes that are accepted from a peer for
each supported address family. The default limits can be overridden
through configuration of the maximum-prefix limit command for the peer
for the appropriate address family. The following default limits are
used if the user does not configure the maximum number of prefixes for
the address family:IPv4 Unicast: 1048576IPv4 Labeled-unicast:
131072IPv4 Tunnel: 1048576IPv6 Unicast: 524288IPv6
Labeled-unicast: 131072IPv4 Multicast: 131072IPv6 Multicast:
131072IPv4 MVPN: 2097152VPNv4 Unicast: 2097152IPv4 MDT:
131072VPNv6 Unicast: 1048576L2VPN EVPN: 2097152


On Tue, Aug 11, 2020 at 9:20 AM Curtis Piehler  wrote:

> Yes this is a common practice to follow for extra security measures.  In
> the off chance a provider starts flooding your network with more than what
> is required it will safe guard your network.  You can set a slightly higher
> warning threshold.  Usually more prevalent in MPLS environments as there
> are more memory constraints on carrying Internet routes in multiple VRFs
> could be detrimental to memory.  Unlikely it would happen but always need
> to think of better ways to safe guard your network.  For as long as humans
> are in existence there will always be room for error.
>
> On Tue, Aug 11, 2020, 9:09 AM Yham  wrote:
>
> > Hello Gentlemen,
> >
> > I wanted to ask if this is common practice to apply Maximum prefix limit
> on
> > BGP neighborship with Internet providers from where you are getting the
> > entire routing table. I know its consider a best practice but want to
> know
> > if its also common.
> > If yes, what would be the max limit of routes? Google search tells me
> that
> > the size of the routing table today is approx 800K prefixes
> >
> > Thanks
> > ___
> > cisco-nsp mailing list  cisco-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP Maximum Prefix limit on Edge routers

[Curtis Piehler]

Yes this is a common practice to follow for extra security measures.  In
the off chance a provider starts flooding your network with more than what
is required it will safe guard your network.  You can set a slightly higher
warning threshold.  Usually more prevalent in MPLS environments as there
are more memory constraints on carrying Internet routes in multiple VRFs
could be detrimental to memory.  Unlikely it would happen but always need
to think of better ways to safe guard your network.  For as long as humans
are in existence there will always be room for error.

On Tue, Aug 11, 2020, 9:09 AM Yham  wrote:

> Hello Gentlemen,
>
> I wanted to ask if this is common practice to apply Maximum prefix limit on
> BGP neighborship with Internet providers from where you are getting the
> entire routing table. I know its consider a best practice but want to know
> if its also common.
> If yes, what would be the max limit of routes? Google search tells me that
> the size of the routing table today is approx 800K prefixes
>
> Thanks
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] BGP Maximum Prefix limit on Edge routers

[Yham]

Hello Gentlemen,

I wanted to ask if this is common practice to apply Maximum prefix limit on
BGP neighborship with Internet providers from where you are getting the
entire routing table. I know its consider a best practice but want to know
if its also common.
If yes, what would be the max limit of routes? Google search tells me that
the size of the routing table today is approx 800K prefixes

Thanks
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP router process using way more memory on one system

[Drew Weaver]

I'll leave this here incase it helps anyone but I was able to get it to respond 
to a few simple validation commands by just clearing a BGP session.

Thanks,
-Drew

-Original Message-
From: Nick Hilliard  
Sent: Monday, May 25, 2020 3:51 AM
To: Drew Weaver 
Cc: 'cisco-nsp@puck.nether.net' 
Subject: Re: [c-nsp] BGP router process using way more memory on one system

Drew Weaver wrote on 24/05/2020 19:20:
> We have two routers that have a mirrored configuration. Peers, BGP 
> configuration, everything. Exactly the same [except for IP addresses]
> 
> One of the routers BGP router process is holding 617576024. The other 
> is holding 577596716.
> 
> The one that is holding more appears to be suffering from an out of 
> memory condition.

There were a couple of releases where the ipv4_rib process had a persistent 
memory leak.  Try this:

Router# admin process restart ipv4_rib

This is non service affecting - restarting the process temporarily stops FIB 
reprogramming, then does a full RIB reload from all RIB sources, then does a 
FIB check across the device. I.e. it's safer to do this than to hobble along 
with OOM errors.

Nick
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP router process using way more memory on one system

[Nick Hilliard]

Drew Weaver wrote on 24/05/2020 19:20:

We have two routers that have a mirrored configuration. Peers, BGP
configuration, everything. Exactly the same [except for IP
addresses]

One of the routers BGP router process is holding 617576024. The other
is holding 577596716.

The one that is holding more appears to be suffering from an out of
memory condition.


There were a couple of releases where the ipv4_rib process had a 
persistent memory leak.  Try this:


Router# admin process restart ipv4_rib

This is non service affecting - restarting the process temporarily stops 
FIB reprogramming, then does a full RIB reload from all RIB sources, 
then does a FIB check across the device. I.e. it's safer to do this than 
to hobble along with OOM errors.


Nick
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] BGP router process using way more memory on one system

[Drew Weaver]

Hello,

We have two routers that have a mirrored configuration. Peers, BGP 
configuration, everything. Exactly the same [except for IP addresses]

One of the routers BGP router process is holding 617576024. The other is 
holding 577596716.

The one that is holding more appears to be suffering from an out of memory 
condition.

I am planning on rebooting it but before I do is there any known way of freeing 
up enough memory to allow basic virtual exec processes to execute?

I've tried basic things like shutting down BGP peers, etc but even though the 
total memory that BGP says it's using goes down.. it still won't free up the 
memory.

Thanks in advance.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] bgp update wait-install - RIB/FIB inconsistency

[Gert Doering]

Hi,

On Fri, Feb 28, 2020 at 02:18:56PM +0100, Marcin Kurek wrote:
> If best path is advertised regardless of the FIB state by default, this 
> would always mean a potential for longer/shorter blackhole...

Unless you do stuff like labeled unicast which does not need the
prefix to be in the local FIB, as long as the label is programmed...

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] bgp update wait-install - RIB/FIB inconsistency

[adamv0025]

Hi Marcin,

Well yes you’re right, hence the path in form of a “update wait-install” 
feature,

Though the best remedy to this slow FIB programming problem is to maintain the 
FIB entries no matter what, 

Opt1 Having two sessions on a single box in case one fails the other will keep 
the FIB entries in place -just NH changes would follow -which in todays 
hierarchical FIBs is a single pointer change operation.

Opt2 “advertise best external” feature so in case you have a box with just a 
single eBGP session it learns prefixes via iBGP from some other border node 
with the “advertise best external” feature enabled. 

 

adam  

 

From: Marcin Kurek  
Sent: Friday, February 28, 2020 1:19 PM
To: adamv0...@netconsultings.com; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] bgp update wait-install - RIB/FIB inconsistency

 

Hi Adam,

Thanks for the reply. I'm still in doubt though. 

If we look here for example:

 <https://xrdocs.io/ncs5500/tutorials/ncs5500-fib-programming-speed/> 
https://xrdocs.io/ncs5500/tutorials/ncs5500-fib-programming-speed/

we see that BGP programming speed is always faster than FIB programming speed.

If best path is advertised regardless of the FIB state by default, this would 
always mean a potential for longer/shorter blackhole...

Thanks,
Marcin

W dniu 26.02.2020 o 14:13, adamv0...@netconsultings.com 
<mailto:adamv0...@netconsultings.com>  pisze:

Hi Marcin,
There was a thread on the topic of slow FIB  download/upload on this forum
some time back.
 
Yes BGP will advertise the best path regardless of the FIB state by default.
I'd recommend enabling it. (though subject to testing on your code version
as always)
 
adam

-Original Message-
From: cisco-nsp  <mailto:cisco-nsp-boun...@puck.nether.net> 
 On Behalf Of Marcin
Kurek
Sent: Friday, February 21, 2020 10:40 AM
To: cisco-nsp@puck.nether.net <mailto:cisco-nsp@puck.nether.net> 
Subject: [c-nsp] bgp update wait-install - RIB/FIB inconsistency
 
Hi all,
 
During a recent MW I ran into a fishy situation.
 
Long story short - ASR9001 running XR 6.4.2 SP4 was rebooted, after it

went

back online I noticed slow route installation in FIB. It took around 20

minutes

to install > 700k prefixes.
 
Apparently, some customers experienced problems at that time, so I'm
suspecting some RIB/FIB inconsistency here.
 
I've been researching this topic for a while and now I'm even more

confused.

 
Can someone help me answer below questions, please?
 
Assuming our router has established its e/iBGP sessions and finished
receiving updates from its neighbors, will it advertise its best paths

even

though FIB programming is still in progress?
 
Common sense answer would be "no", because if it starts advertising
prefixes that are not installed in FIB, it also starts attracting and

possibly

blackholing traffic.
 
But I discovered the command "update wait-install" as part of BGP RIB
feedback mechanism introduced in XR 4.3. When it's enabled, routes that
have not been installed in FIB are not advertised. Looks like that it's

turned

off by default though.
 
If so, the answer to my 1st question should be "yes", although to me, it
doesn't make much sense.
 
I've been trying to find best practices / recommendations for that

command,

but without luck.
 
Can anyone shed some light on that, please?
 
Thanks,
 
marcin
 
 
 
 
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net 
<mailto:cisco-nsp@puck.nether.net> 
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

 

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] bgp update wait-install - RIB/FIB inconsistency

[Marcin Kurek]

Hi Adam,

Thanks for the reply. I'm still in doubt though.

If we look here for example:

https://xrdocs.io/ncs5500/tutorials/ncs5500-fib-programming-speed/

we see that BGP programming speed is always faster than FIB programming 
speed.


If best path is advertised regardless of the FIB state by default, this 
would always mean a potential for longer/shorter blackhole...


Thanks,
Marcin

W dniu 26.02.2020 o 14:13, adamv0...@netconsultings.com pisze:

Hi Marcin,
There was a thread on the topic of slow FIB  download/upload on this forum
some time back.

Yes BGP will advertise the best path regardless of the FIB state by default.
I'd recommend enabling it. (though subject to testing on your code version
as always)

adam

-Original Message-
From: cisco-nsp  On Behalf Of Marcin
Kurek
Sent: Friday, February 21, 2020 10:40 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] bgp update wait-install - RIB/FIB inconsistency

Hi all,

During a recent MW I ran into a fishy situation.

Long story short - ASR9001 running XR 6.4.2 SP4 was rebooted, after it

went

back online I noticed slow route installation in FIB. It took around 20

minutes

to install > 700k prefixes.

Apparently, some customers experienced problems at that time, so I'm
suspecting some RIB/FIB inconsistency here.

I've been researching this topic for a while and now I'm even more

confused.

Can someone help me answer below questions, please?

Assuming our router has established its e/iBGP sessions and finished
receiving updates from its neighbors, will it advertise its best paths

even

though FIB programming is still in progress?

Common sense answer would be "no", because if it starts advertising
prefixes that are not installed in FIB, it also starts attracting and

possibly

blackholing traffic.

But I discovered the command "update wait-install" as part of BGP RIB
feedback mechanism introduced in XR 4.3. When it's enabled, routes that
have not been installed in FIB are not advertised. Looks like that it's

turned

off by default though.

If so, the answer to my 1st question should be "yes", although to me, it
doesn't make much sense.

I've been trying to find best practices / recommendations for that

command,

but without luck.

Can anyone shed some light on that, please?

Thanks,

marcin




___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] bgp update wait-install - RIB/FIB inconsistency

[Mark Tinka]

On 26/Feb/20 15:13, adamv0...@netconsultings.com wrote:

> Hi Marcin,
> There was a thread on the topic of slow FIB  download/upload on this forum
> some time back.
>
> Yes BGP will advertise the best path regardless of the FIB state by default.
> I'd recommend enabling it. (though subject to testing on your code version
> as always)

So our ASR9001's have reached their end of their usefulness.

We had 5 running peering, and 3 of them were struggling with local BGP
updates, CPU handling of the BGP process, slow convergence, e.t.c.

Swapped those out with MX204's recently, and the remaining 2 are to be
done in about a month or so.

We've sent them to same place we sent our MX80's and MX104's. They're done.

Hopefully, these will be the last non-x86 boxes we ever see these
vendors pushing out :-).

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] bgp update wait-install - RIB/FIB inconsistency

[adamv0025]

Hi Marcin,
There was a thread on the topic of slow FIB  download/upload on this forum
some time back.

Yes BGP will advertise the best path regardless of the FIB state by default.
I'd recommend enabling it. (though subject to testing on your code version
as always)

adam
> -Original Message-
> From: cisco-nsp  On Behalf Of Marcin
> Kurek
> Sent: Friday, February 21, 2020 10:40 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] bgp update wait-install - RIB/FIB inconsistency
> 
> Hi all,
> 
> During a recent MW I ran into a fishy situation.
> 
> Long story short - ASR9001 running XR 6.4.2 SP4 was rebooted, after it
went
> back online I noticed slow route installation in FIB. It took around 20
minutes
> to install > 700k prefixes.
> 
> Apparently, some customers experienced problems at that time, so I'm
> suspecting some RIB/FIB inconsistency here.
> 
> I've been researching this topic for a while and now I'm even more
confused.
> 
> Can someone help me answer below questions, please?
> 
> Assuming our router has established its e/iBGP sessions and finished
> receiving updates from its neighbors, will it advertise its best paths
even
> though FIB programming is still in progress?
> 
> Common sense answer would be "no", because if it starts advertising
> prefixes that are not installed in FIB, it also starts attracting and
possibly
> blackholing traffic.
> 
> But I discovered the command "update wait-install" as part of BGP RIB
> feedback mechanism introduced in XR 4.3. When it's enabled, routes that
> have not been installed in FIB are not advertised. Looks like that it's
turned
> off by default though.
> 
> If so, the answer to my 1st question should be "yes", although to me, it
> doesn't make much sense.
> 
> I've been trying to find best practices / recommendations for that
command,
> but without luck.
> 
> Can anyone shed some light on that, please?
> 
> Thanks,
> 
> marcin
> 
> 
> 
> 
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] bgp update wait-install - RIB/FIB inconsistency

[Marcin Kurek]

Hi all,

During a recent MW I ran into a fishy situation.

Long story short - ASR9001 running XR 6.4.2 SP4 was rebooted, after it 
went back online I noticed slow route installation in FIB. It took 
around 20 minutes to install > 700k prefixes.


Apparently, some customers experienced problems at that time, so I'm 
suspecting some RIB/FIB inconsistency here.


I've been researching this topic for a while and now I'm even more confused.

Can someone help me answer below questions, please?

Assuming our router has established its e/iBGP sessions and finished 
receiving updates from its neighbors, will it advertise its best paths 
even though FIB programming is still in progress?


Common sense answer would be "no", because if it starts advertising 
prefixes that are not installed in FIB, it also starts attracting and 
possibly blackholing traffic.


But I discovered the command "update wait-install" as part of BGP RIB 
feedback mechanism introduced in XR 4.3. When it's enabled, routes that 
have not been installed in FIB are not advertised. Looks like that it's 
turned off by default though.


If so, the answer to my 1st question should be "yes", although to me, it 
doesn't make much sense.


I've been trying to find best practices / recommendations for that 
command, but without luck.


Can anyone shed some light on that, please?

Thanks,

marcin




___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP maximum-prefix on ASR9000s

[Alexandr Gurbo]

Hello Tim,

Our routine on ASR9001-S - 3M.

ASR9001-S#show route summary
Thu Feb 13 10:20:55
Route Source Routes Backup Deleted Memory(bytes)
connected41 1  0   6720
local42 0  0   6720
static   43 0  0   6880
ospf 300 1  0  0   160
bgp xxx  30164942  0   482639360
dagr 0  0  0   0
Total30166213  0   482659840


On Wed, 12 Feb 2020 22:58:51 +
Tim Warnock  wrote:

> I had some maintenance to perform on an ASR9001 (32bit IOS-XR) - there was a 
> point in time during the maintenance where it only had installed routes from 
> our RRs.

-- 
Alexandr
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP maximum-prefix on ASR9000s

[Tim Warnock]

> Have you tested what happens with an XR BGP when a valid peer sends you
> ~2,147,483,647 prefixes please?
> 
> My guess is the BGP runs out of memory and restarts -what happens to the
> FIB on all line-cards I'm not even guessing...
> And then the RRs pushing 2bilions of prefixes to all other PEs in the AS...
> I actually haven't tested so would be interested to know.
> 
> Anyways I'd rather have the offending internet peer/peers reset at around
> 1M or so -while BGP and line-cards can still cope with the load.
> Of course VPN customers have lower thresholds.
> 
> adam
> 

I had some maintenance to perform on an ASR9001 (32bit IOS-XR) - there was a 
point in time during the maintenance where it only had installed routes from 
our RRs.

Device#sh bgp all unicast summary wide
Wed Feb 12 13:48:14.246 UTC

Address Family: IPv4 Unicast


BGP router identifier , local AS number 38195
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe000   RD version: 7020912
BGP main routing table version 7020912
BGP NSR Initial initsync version 9 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

BGP is operating in STANDALONE mode.


Process   RcvTblVer   bRIB/RIB   LabelVer  ImportVer  SendTblVer  StandbyVer
Speaker 7020912702091270209127020912 7020912   0

NeighborSpk  ASMsgRcvdMsgSent   
   TblVer   InQ   OutQUp/Down  St/PfxRcd
rr-ip 0   38195 384291158
7020912  0  0   00:23:062297554
rr-ip 0   38195 384189157
7020912  0  0   00:22:582297548
rr-ip 0   38195 384858157
7020912  0  0   00:22:582297550


Address Family: IPv6 Unicast


BGP router identifier , local AS number 38195
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe080   RD version: 841464
BGP main routing table version 841464
BGP NSR Initial initsync version 6 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

BGP is operating in STANDALONE mode.


Process   RcvTblVer   bRIB/RIB   LabelVer  ImportVer  SendTblVer  StandbyVer
Speaker  841464 841463 841464 841463  841463   0

NeighborSpk  ASMsgRcvdMsgSent   
   TblVer   InQ   OutQUp/Down  St/PfxRcd
rr-ip 0   38195 104261145 
841463  0  0   00:23:06 249910
rr-ip 0   38195 104244143 
841463  0  0   00:22:48 249910
rr-ip 0   38195 104322145 
841463  0  0   00:23:06 249910


Happy to report that it didn't explode.

Thanks
Tim.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP maximum-prefix on ASR9000s

[Mark Tinka]

On 3/Feb/20 23:15, adamv0...@netconsultings.com wrote:

> Have you tested what happens with an XR BGP when a valid peer sends
> you ~2,147,483,647 prefixes please?
> My guess is the BGP runs out of memory and restarts -what happens to the FIB 
> on all line-cards I'm not even guessing...
> And then the RRs pushing 2bilions of prefixes to all other PEs in the AS...
> I actually haven't tested so would be interested to know.

So we only set the maximum value for this on iBGP sessions for our IOS
XR boxes. Which makes sense.

On eBGP sessions with peers, we impose a pre-defined maximum value
which, generally, is a couple hundred prefixes for IPv4/IPv6, unless
specifically advised by the external peer.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP maximum-prefix on ASR9000s

[adamv0025]

> Mark Tinka
> Sent: Monday, January 27, 2020 7:14 AM
> 
> On 27/Jan/20 08:05, Hank Nussbacher wrote:
> 
> > As many of us run full routing tables on our ASR9000s, we have just
> > found popping up in our logs:
> > gp[1058]: %ROUTING-BGP-5-MAXPFX : No. of IPv4 Unicast prefixes
> > received from xxx.xxx.220.91 has reached 786433, max 1048576
> > Reference:
> >
> https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r
> > 5-3/routing/configuration/guide/b_routing_cg53xasr9k/b_routing_cg53xas
> > r9k_chapter_010.html
> >
> > The undefined default for maximum-prefix on ASR9000s (IOS-XR) is
> 1048576.
> > Recommendation: increase maximum-prefix to 150
> 
> Known issue since IOS XR launched back in the day.
> 
> For as far back as I can remember (probably 2010 or earlier), we always had
> the below line as standard configuration in all our IOS XR platforms for BGP
> sessions that did not require a prefix limit:
> 
>maximum-prefix 4294967295 75
> 
Have you tested what happens with an XR BGP when a valid peer sends you 
~2,147,483,647 prefixes please?

My guess is the BGP runs out of memory and restarts -what happens to the FIB on 
all line-cards I'm not even guessing...
And then the RRs pushing 2bilions of prefixes to all other PEs in the AS...
I actually haven't tested so would be interested to know.

Anyways I'd rather have the offending internet peer/peers reset at around 1M or 
so -while BGP and line-cards can still cope with the load.
Of course VPN customers have lower thresholds. 

adam
 


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP maximum-prefix on ASR9000s

[Lukas Tribus]

On Mon, 27 Jan 2020 at 12:21, Saku Ytti  wrote:
>
> On Mon, 27 Jan 2020 at 12:54, Lukas Tribus  wrote:
>
> > I'm confused; I'm running Internet in a MPLS VPNs with per-ce label
> > allocation on ASR9k since 2016, for both address-families.
> >
> > What is CSCvf15291 about exactly (it's not public).
>
> IPv4 unicast, everything else had it since day1(?).

Makes sense, thanks for clarifying.

I guess IPv4 labeled unicast deployments are much more common than
Internet-in-a-VRF configurations, so the 6.5.1 requirement is
important indeed.


thanks,
lukas
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP maximum-prefix on ASR9000s

[Saku Ytti]

On Mon, 27 Jan 2020 at 12:54, Lukas Tribus  wrote:

> I'm confused; I'm running Internet in a MPLS VPNs with per-ce label
> allocation on ASR9k since 2016, for both address-families.
>
> What is CSCvf15291 about exactly (it's not public).

IPv4 unicast, everything else had it since day1(?).

-- 
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP maximum-prefix on ASR9000s

[Lukas Tribus]

Hello,

On Mon, 27 Jan 2020 at 11:15, Saku Ytti  wrote:
> > For people running full tables with labels (BGP-LU or
> > Internet-in-a-VRF), it's probably a good time to start thinking about
> > their label consumption, if a label is allocated per-prefix (default
> > in Cisco land at least for MPLS VPNs).
>
> You need to go all the way to 6.5.1 (CSCvf15291) for per-ce to IPv4,
> IPv6 has had it always.

I'm confused; I'm running Internet in a MPLS VPNs with per-ce label
allocation on ASR9k since 2016, for both address-families.

What is CSCvf15291 about exactly (it's not public).


Thanks,

Lukas
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP maximum-prefix on ASR9000s

[Saku Ytti]

On Mon, 27 Jan 2020 at 11:24, Lukas Tribus  wrote:

> For people running full tables with labels (BGP-LU or
> Internet-in-a-VRF), it's probably a good time to start thinking about
> their label consumption, if a label is allocated per-prefix (default
> in Cisco land at least for MPLS VPNs).

You need to go all the way to 6.5.1 (CSCvf15291) for per-ce to IPv4,
IPv6 has had it always.

-- 
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP maximum-prefix on ASR9000s

[Lukas Tribus]

Hello,

On Mon, 27 Jan 2020 at 08:14, Mark Tinka  wrote:
> On 27/Jan/20 08:05, Hank Nussbacher wrote:
>
> > As many of us run full routing tables on our ASR9000s, we have just
> > found popping up in our logs:
> > gp[1058]: %ROUTING-BGP-5-MAXPFX : No. of IPv4 Unicast prefixes
> > received from xxx.xxx.220.91 has reached 786433, max 1048576
> > Reference:
> > https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-3/routing/configuration/guide/b_routing_cg53xasr9k/b_routing_cg53xasr9k_chapter_010.html
> >
> > The undefined default for maximum-prefix on ASR9000s (IOS-XR) is 1048576.
> > Recommendation: increase maximum-prefix to 150
>
> Known issue since IOS XR launched back in the day.
>
> For as far back as I can remember (probably 2010 or earlier), we always
> had the below line as standard configuration in all our IOS XR platforms
> for BGP sessions that did not require a prefix limit:
>
>maximum-prefix 4294967295 75
>
> Doesn't affect only the ASR9000, but all IOS XR platforms.

For people running full tables with labels (BGP-LU or
Internet-in-a-VRF), it's probably a good time to start thinking about
their label consumption, if a label is allocated per-prefix (default
in Cisco land at least for MPLS VPNs).

Running out of label space (with is limited to 1M, you can't stuff
more in a 20-bit label) is gonna be bad experience. While with the
6500/7600 TCAM issue only those particular nodes were affected, this
is not a question of obsolete HW, SW or TCAM partitioning on a
particular node and will affect all vendors in a per-prefix label
allocation configuration.

We are running Internet-in-a-VRF on both IOS-XE and IOS-XR, in per-ce
(meaning per next-hop) label allocation mode. It was buggy initially
in IOS-XE, but after a few rounds of bug-fixing a few years ago things
are running smoothly now. I like the fact that I'm only doing one L3
lookup on the ingress-PE, which is why I avoid per-VRF label
allocation mode.


cheers,
lukas
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP maximum-prefix on ASR9000s

[Mark Tinka]

On 27/Jan/20 08:05, Hank Nussbacher wrote:

> As many of us run full routing tables on our ASR9000s, we have just
> found popping up in our logs:
> gp[1058]: %ROUTING-BGP-5-MAXPFX : No. of IPv4 Unicast prefixes
> received from xxx.xxx.220.91 has reached 786433, max 1048576
> Reference:
> https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-3/routing/configuration/guide/b_routing_cg53xasr9k/b_routing_cg53xasr9k_chapter_010.html
>
> The undefined default for maximum-prefix on ASR9000s (IOS-XR) is 1048576.
> Recommendation: increase maximum-prefix to 150

Known issue since IOS XR launched back in the day.

For as far back as I can remember (probably 2010 or earlier), we always
had the below line as standard configuration in all our IOS XR platforms
for BGP sessions that did not require a prefix limit:

       maximum-prefix 4294967295 75

Doesn't affect only the ASR9000, but all IOS XR platforms.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] BGP maximum-prefix on ASR9000s

[Hank Nussbacher]

As many of us run full routing tables on our ASR9000s, we have just 
found popping up in our logs:
gp[1058]: %ROUTING-BGP-5-MAXPFX : No. of IPv4 Unicast prefixes received 
from xxx.xxx.220.91 has reached 786433, max 1048576

Reference:
https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-3/routing/configuration/guide/b_routing_cg53xasr9k/b_routing_cg53xasr9k_chapter_010.html
The undefined default for maximum-prefix on ASR9000s (IOS-XR) is 1048576.
Recommendation: increase maximum-prefix to 150

Regards,
Hank


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] (BGP) BFD on XR in vrf on sub-interface of bundle-ether interface

[adamv0025]

> David Hubbard
> Sent: Saturday, June 29, 2019 4:14 AM
> 
> What platform are you on?  I ran into numerous issues with XR + BFD on
> NCS5501-SE hardware; worked with TAC and confirmed.  It's broken for
> bundle interfaces (gives an error, won't take the config), broken for BGP
> (takes the config without error but doesn't work), and broken if VRRP is in
> use.  It will only work on a single physical link on that platform.  We 
> swapped
> out for Arista 7280's ultimately.
> 
Was it recently (recent code release) please? Would like to know if this 
problem still exists or whether it might have been solved by now.
Thank you

adam

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] (BGP) BFD on XR in vrf on sub-interface of bundle-ether interface

[Hansen, Christoffer]

On 29/06/2019 05:13, David Hubbard wrote:
> What platform are you on?

ASR9k

> ran into numerous issues with XR + BFD on NCS5501-SE hardware; worked
> with TAC and confirmed.  It's broken for bundle interfaces (gives an
> error, won't take the config), broken for BGP (takes the config
> without error but doesn't work), and broken if VRRP is in use.  It
> will only work on a single physical link on that platform.  We
> swapped out for Arista 7280's ultimately.

Got an off-list hint on what to do. Which got me going again.

BFD_MP_DOWNLOAD_NO_LC <-- Meant I forgot to turn on BFD for the
linecard.

Configured "bfd multipath include location ?/?/CPU?" did it.


Realised upon receiving hint. I had overlooked a section in the Cisco
configuration guide. Mentioning turning on BFD-per-linecard-basis
is mandatory. And BFD will not work if this step is forgotten. Yes,
I was able to configure everything. Just, it would not work and
got stuck with the previous error-code. Which I was challenged throwing
search engine magic after, finding useful information on.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] (BGP) BFD on XR in vrf on sub-interface of bundle-ether interface

[David Hubbard]

What platform are you on?  I ran into numerous issues with XR + BFD on 
NCS5501-SE hardware; worked with TAC and confirmed.  It's broken for bundle 
interfaces (gives an error, won't take the config), broken for BGP (takes the 
config without error but doesn't work), and broken if VRRP is in use.  It will 
only work on a single physical link on that platform.  We swapped out for 
Arista 7280's ultimately.



On 6/28/19, 1:19 PM, "cisco-nsp on behalf of christof...@netravnen.de" 
 wrote:

c-nsp,

Anyone having tried running (BGP) BFD on XR in vrf on sub-interface of
bundle-ether interface with success? Have tried looking through
documentation at Cisco.com with no luck so far.

Currently trying to get a session up with an non-cisco device on the
other end. No avail. Luck is close to up.
Have tried reading the Cisco Documentation from 4.2 release concerning
the restrictions to BFD mentioned. But I cannot get around to be wiser
if the restrictions applies to the below mentioned situation or not. :???:



[Cisco XR <=> Cisco SW (L2) <=> Juniper SW (L2) <=> Arista SW (L3)]
[   \/\ /\   /]
[   trunktrunktrunk  trunk accessaccess   ]
[ \/\ /\   /  ]
[ #Vlan tagged# #Vlan tagged#  #untagged# ]

BFD is tried configured between XR and Arista SW.

  * Cisco XR <=> Cisco SW (L2) : trunk interface (LAG group)
  * Cisco SW (L2) <=> Juniper SW (L2) : trunk interface
  * Juniper SW (L2) <=> Arista SW (L3) : access interface

  § same Vlan tag is carried on traffic between Cisco XR <=> Juniper SW.
Juniper SW pops vlan tag before forwarding traffic to Arista SW.

Using "monitor traffic interface(...)matching "udp && (port 49152 ||
port 3784)" looking for traversing BFD packets on Juniper SW (L2)...
Returns an empty output. No packet(s) matched.



Configuration Example Snippet from XR:

bfd
 interface Bundle-Ether500.600
  no echo
 !
!
interface Bundle-Ether500.600
 vrf RED
 ipv4 mtu 1500
 ipv4 address 10.10.10.9 255.255.255.252
 encapsulation dot1q 600
!
router bgp 65000
 vrf RED
  neighbor 10.10.10.10
   remote-as 65001
   bfd fast-detect
   bfd multiplier 3
   bfd minimum-interval 3000
  !
 !
!
interface Bundle-Ether500
 mtu 9000
 bundle minimum-active links 1
!
interface Te0/0/0/0
 bundle id 500 mode active
!
interface Te0/0/1/3
 bundle id 500 mode active
!


RP/0/RSP1/CPU0:XR#sh conf run int Bundle-Ether500.600
I/f: Bundle-Ether500.600, Location: 0/RSP1/CPU0
Dest: 10.10.10.10
Src: 10.10.10.9
 State: DOWN for 0d:1h:0m:0s, number of times UP: 0
 Session type: SW/V4/SH/BL
Received parameters:
 Version: 0, desired tx interval: 0 ms, required rx interval: 0 ms
 Required echo rx interval: 0 ms, multiplier: 0, diag: None
 My discr: 0, your discr: 0, H/D/F/P/C/A: 0/0/0/0/0/0
Transmitted parameters:
 Version: 0, desired tx interval: 0 ms, required rx interval: 0 ms
 Required echo rx interval: 0 ms, multiplier: 0, diag: None
 My discr: 0, your discr: 0, H/D/F/P/C/A: 0/0/0/0/0/0
Timer Values:
 Local negotiated async tx interval: 0 ms
 Remote negotiated async tx interval: 0 s
 Desired echo tx interval: 0 s, local negotiated echo tx interval: 0 ms
 Echo detection time: 0 ms, async detection time: 0 ms
Label:
 Internal label: 289033/0x46909
Local Stats:
 Intervals between async packets:
   Tx: Number of intervals=0, min=0 s, max=0 s, avg=0 s
   Last packet transmitted 0 s ago
   Rx: Number of intervals=0, min=0 s, max=0 s, avg=0 s
   Last packet received 0 s ago
 Intervals between echo packets:
   Tx: Number of intervals=0, min=0 s, max=0 s, avg=0 s
   Last packet transmitted 0 s ago
   Rx: Number of intervals=0, min=0 s, max=0 s, avg=0 s
   Last packet received 0 s ago
 Latency of echo packets (time between tx and rx):
   Number of packets: 0, min=0 ms, max=0 ms, avg=0 ms
MP download state: BFD_MP_DOWNLOAD_NO_LC
State change time: Jun 28 14:14:14.147
Session owner information:
Desired   Adjusted
  Client   Interval   Multiplier Interval   Multiplier
   - -
  bgp-default  3 s3  3 s3


RP/0/RSP1/CPU0:XR#sh ver | i Cisco IOS XR Software
Cisco IOS XR Software, Version 5.3.4[Default]


RP/0/RSP1/CPU0:XR#show bfd counters packet
---empty_output---
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net

[c-nsp] (BGP) BFD on XR in vrf on sub-interface of bundle-ether interface

[christoffer]

c-nsp,

Anyone having tried running (BGP) BFD on XR in vrf on sub-interface of
bundle-ether interface with success? Have tried looking through
documentation at Cisco.com with no luck so far.

Currently trying to get a session up with an non-cisco device on the
other end. No avail. Luck is close to up.
Have tried reading the Cisco Documentation from 4.2 release concerning
the restrictions to BFD mentioned. But I cannot get around to be wiser
if the restrictions applies to the below mentioned situation or not. :???:



[Cisco XR <=> Cisco SW (L2) <=> Juniper SW (L2) <=> Arista SW (L3)]
[   \/\ /\   /]
[   trunktrunktrunk  trunk accessaccess   ]
[ \/\ /\   /  ]
[ #Vlan tagged# #Vlan tagged#  #untagged# ]

BFD is tried configured between XR and Arista SW.

  * Cisco XR <=> Cisco SW (L2) : trunk interface (LAG group)
  * Cisco SW (L2) <=> Juniper SW (L2) : trunk interface
  * Juniper SW (L2) <=> Arista SW (L3) : access interface

  § same Vlan tag is carried on traffic between Cisco XR <=> Juniper SW.
Juniper SW pops vlan tag before forwarding traffic to Arista SW.

Using "monitor traffic interface(...)matching "udp && (port 49152 ||
port 3784)" looking for traversing BFD packets on Juniper SW (L2)...
Returns an empty output. No packet(s) matched.



Configuration Example Snippet from XR:

bfd
 interface Bundle-Ether500.600
  no echo
 !
!
interface Bundle-Ether500.600
 vrf RED
 ipv4 mtu 1500
 ipv4 address 10.10.10.9 255.255.255.252
 encapsulation dot1q 600
!
router bgp 65000
 vrf RED
  neighbor 10.10.10.10
   remote-as 65001
   bfd fast-detect
   bfd multiplier 3
   bfd minimum-interval 3000
  !
 !
!
interface Bundle-Ether500
 mtu 9000
 bundle minimum-active links 1
!
interface Te0/0/0/0
 bundle id 500 mode active
!
interface Te0/0/1/3
 bundle id 500 mode active
!


RP/0/RSP1/CPU0:XR#sh conf run int Bundle-Ether500.600
I/f: Bundle-Ether500.600, Location: 0/RSP1/CPU0
Dest: 10.10.10.10
Src: 10.10.10.9
 State: DOWN for 0d:1h:0m:0s, number of times UP: 0
 Session type: SW/V4/SH/BL
Received parameters:
 Version: 0, desired tx interval: 0 ms, required rx interval: 0 ms
 Required echo rx interval: 0 ms, multiplier: 0, diag: None
 My discr: 0, your discr: 0, H/D/F/P/C/A: 0/0/0/0/0/0
Transmitted parameters:
 Version: 0, desired tx interval: 0 ms, required rx interval: 0 ms
 Required echo rx interval: 0 ms, multiplier: 0, diag: None
 My discr: 0, your discr: 0, H/D/F/P/C/A: 0/0/0/0/0/0
Timer Values:
 Local negotiated async tx interval: 0 ms
 Remote negotiated async tx interval: 0 s
 Desired echo tx interval: 0 s, local negotiated echo tx interval: 0 ms
 Echo detection time: 0 ms, async detection time: 0 ms
Label:
 Internal label: 289033/0x46909
Local Stats:
 Intervals between async packets:
   Tx: Number of intervals=0, min=0 s, max=0 s, avg=0 s
   Last packet transmitted 0 s ago
   Rx: Number of intervals=0, min=0 s, max=0 s, avg=0 s
   Last packet received 0 s ago
 Intervals between echo packets:
   Tx: Number of intervals=0, min=0 s, max=0 s, avg=0 s
   Last packet transmitted 0 s ago
   Rx: Number of intervals=0, min=0 s, max=0 s, avg=0 s
   Last packet received 0 s ago
 Latency of echo packets (time between tx and rx):
   Number of packets: 0, min=0 ms, max=0 ms, avg=0 ms
MP download state: BFD_MP_DOWNLOAD_NO_LC
State change time: Jun 28 14:14:14.147
Session owner information:
Desired   Adjusted
  Client   Interval   Multiplier Interval   Multiplier
   - -
  bgp-default  3 s3  3 s3


RP/0/RSP1/CPU0:XR#sh ver | i Cisco IOS XR Software
Cisco IOS XR Software, Version 5.3.4[Default]


RP/0/RSP1/CPU0:XR#show bfd counters packet
---empty_output---
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP Route Announcement

[Saku Ytti]

On Sat, 15 Dec 2018 at 04:54, Randy via cisco-nsp
 wrote:

>b)There is Zero-Value in having *soft-reconfig-inbound* for your session with 
>your ISP(this is 2018 and I dare say, every BGP speaker supports soft-reset 
>in/out!
>
> *soft-reconfig* makes sense on Customer-Sessions; if you are an ISP(so you 
> can prove to customer "what-you-are-receiving" prior to any-modification by 
> your router; to end the "This-is-Your-Problem" issue.

Zero seems exaggeration, the more data you have access to, the better?
Are you comfortable your policies are perfect and do exactly what you
planned and you have no need to verify this? Are you confident
software interprets and implements the policies correctly? Do you want
to contact your upstream when they send you trash, even if you filter
that trash?
Do you turn off this on platforms where it's on by default (keep none
in JunOS) to have harmonised platform independent configurations?

I'd rather say, it's 2018, DRAM is cheap and premature optimisation is
source of many problems.

If I have the DRAM for it, I prefer to know what my policies rejected.
But you also need to consider can you limit pre-policy max-prefix and
if not, are you comfortable having this attack vector open. Likely you
(we) are comfortable, considering how little interest industry has on
protecting the control-plane.

I'd also like to add that I view network statements undesirable. In
static routes you can use tags to communicate what should happen to
the static route during redistribution. Unfortunately we do not have
communities or tags for connected/direct route, yet. So there is no
avoiding double entries for connected routes, but I'd still prefer to
add them to prefix-list instead of network-statement.

-- 
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP Route Announcement

[Bryan Holloway]

On 12/14/18 8:52 PM, Randy wrote:

...you mean a floating-static to Null0 with a distance of 254?; especially when 
prefix-lengths are the same(what is in IGP and what is being advertised)so the 
internet doesn't burble if your IGP does?


Yes, and yes ... and even if IGP and BGP for a given prefix don't agree. 
At 3am, it's one less thing on which to spend brain-cycles.


Sorry if that wasn't clear ...

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP Route Announcement

[Randy via cisco-nsp]

--- Begin Message ---
...you mean a floating-static to Null0 with a distance of 254?; especially when 
prefix-lengths are the same(what is in IGP and what is being advertised)so the 
internet doesn't burble if your IGP does?

Observations for OP:

1) As has been mentioned: please migrate to prefix-lists.
2)Looking at your posted-config:
a)There is *no* need to have a prefix-filter/distribute-list and a route-map in 
place for your upstream. Since you already have a route-map in place for 
inbound to your ISP; you can have your route-maps do everything for 
you.
b)There is Zero-Value in having *soft-reconfig-inbound* for your session with 
your ISP(this is 2018 and I dare say, every BGP speaker supports soft-reset 
in/out!

*soft-reconfig* makes sense on Customer-Sessions; if you are an ISP(so you can 
prove to customer "what-you-are-receiving" prior to any-modification by your 
router; to end the "This-is-Your-Problem" issue.

-Randy







From: Bryan Holloway 
To: Cisco Network Service Providers  
Sent: Friday, December 14, 2018 3:37 PM
Subject: Re: [c-nsp] BGP Route Announcement



I generally prefer to keep the Null0 even if there's a static or (IGP) 

non-static as a matter of best-practice.


If your IGP burbles, then the rest of the Internet won't, leading to 

faster recovery times.


Statics are inherently less prone to this, but having the Null0 pin-up 

doesn't hurt anything and it makes your configuration more homogeneous 

knowing that anything you're advertising should be in the routing table 

no matter what. Easier to trouble-shoot, spot errors, etc.



On 12/14/18 2:40 PM, Shawn L wrote:

> That second part has bit me in the rear before. As a matter of course

> now I always make a static route to null 0 for every prefix I announce via

> BGP.  Once I verify that an IGP or static route is covering that prefix, I

> remove the null route or not if you have several more specific routes.

> 

> On Fri, Dec 14, 2018 at 12:34 PM Mark Tinka  wrote:

> 

>>

>>

>> On 14/Dec/18 19:16, Joseph Mays wrote:

>>

>>>

>>> The distribute lists shown also just contained appropriate permit and

>> deny entries for 216.24.0.0 /18

>>

>> Firstly, please don't use distribute lists. This is very archaic and

>> prone to mistakes. Suggest you migrate to prefix lists right away!

>>

>>>

>>>

>>> That changed the broadcast cogent was receiving, but not in the expected

>> way. They only route they saw us broadcasting after that was the

>> 216.24.60.0/23 route. Not the first one in the list, not the last one,

>> not the biggest one or the smallest one, but just one route from the middle

>> of the list. I don't get this behavior at all. Cogent cleared and bounced

>> bgp to us, and still received only that one route in the broadcast from us.

>>

>> After you've fixed your filtering with prefix lists, you need to ensure

>> that any "network..." statement is backed up by the presence of the very

>> same route in your IGP (which includes static routing).

>>

>> Mark.

>> ___

>> cisco-nsp mailing list  cisco-nsp@puck.nether.net

>> https://puck.nether.net/mailman/listinfo/cisco-nsp

>> archive at http://puck.nether.net/pipermail/cisco-nsp/

>>

> ___

> cisco-nsp mailing list  cisco-nsp@puck.nether.net

> https://puck.nether.net/mailman/listinfo/cisco-nsp

> archive at http://puck.nether.net/pipermail/cisco-nsp/

> 

___

cisco-nsp mailing list  cisco-nsp@puck.nether.net

https://puck.nether.net/mailman/listinfo/cisco-nsp

archive at http://puck.nether.net/pipermail/cisco-nsp/
--- End Message ---
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP Route Announcement

[Bryan Holloway]

I generally prefer to keep the Null0 even if there's a static or (IGP) 
non-static as a matter of best-practice.


If your IGP burbles, then the rest of the Internet won't, leading to 
faster recovery times.


Statics are inherently less prone to this, but having the Null0 pin-up 
doesn't hurt anything and it makes your configuration more homogeneous 
knowing that anything you're advertising should be in the routing table 
no matter what. Easier to trouble-shoot, spot errors, etc.



On 12/14/18 2:40 PM, Shawn L wrote:

That second part has bit me in the rear before. As a matter of course
now I always make a static route to null 0 for every prefix I announce via
BGP.  Once I verify that an IGP or static route is covering that prefix, I
remove the null route or not if you have several more specific routes.

On Fri, Dec 14, 2018 at 12:34 PM Mark Tinka  wrote:




On 14/Dec/18 19:16, Joseph Mays wrote:



The distribute lists shown also just contained appropriate permit and

deny entries for 216.24.0.0 /18

Firstly, please don't use distribute lists. This is very archaic and
prone to mistakes. Suggest you migrate to prefix lists right away!




That changed the broadcast cogent was receiving, but not in the expected

way. They only route they saw us broadcasting after that was the
216.24.60.0/23 route. Not the first one in the list, not the last one,
not the biggest one or the smallest one, but just one route from the middle
of the list. I don't get this behavior at all. Cogent cleared and bounced
bgp to us, and still received only that one route in the broadcast from us.

After you've fixed your filtering with prefix lists, you need to ensure
that any "network..." statement is backed up by the presence of the very
same route in your IGP (which includes static routing).

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP Route Announcement

[Shawn L]

That second part has bit me in the rear before. As a matter of course
now I always make a static route to null 0 for every prefix I announce via
BGP.  Once I verify that an IGP or static route is covering that prefix, I
remove the null route or not if you have several more specific routes.

On Fri, Dec 14, 2018 at 12:34 PM Mark Tinka  wrote:

>
>
> On 14/Dec/18 19:16, Joseph Mays wrote:
>
> >
> > The distribute lists shown also just contained appropriate permit and
> deny entries for 216.24.0.0 /18
>
> Firstly, please don't use distribute lists. This is very archaic and
> prone to mistakes. Suggest you migrate to prefix lists right away!
>
> >
> >
> > That changed the broadcast cogent was receiving, but not in the expected
> way. They only route they saw us broadcasting after that was the
> 216.24.60.0/23 route. Not the first one in the list, not the last one,
> not the biggest one or the smallest one, but just one route from the middle
> of the list. I don't get this behavior at all. Cogent cleared and bounced
> bgp to us, and still received only that one route in the broadcast from us.
>
> After you've fixed your filtering with prefix lists, you need to ensure
> that any "network..." statement is backed up by the presence of the very
> same route in your IGP (which includes static routing).
>
> Mark.
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP Route Announcement

[Mark Tinka]

On 14/Dec/18 19:16, Joseph Mays wrote:

>
> The distribute lists shown also just contained appropriate permit and deny 
> entries for 216.24.0.0 /18

Firstly, please don't use distribute lists. This is very archaic and
prone to mistakes. Suggest you migrate to prefix lists right away!

>
>
> That changed the broadcast cogent was receiving, but not in the expected way. 
> They only route they saw us broadcasting after that was the 216.24.60.0/23 
> route. Not the first one in the list, not the last one, not the biggest one 
> or the smallest one, but just one route from the middle of the list. I don't 
> get this behavior at all. Cogent cleared and bounced bgp to us, and still 
> received only that one route in the broadcast from us.

After you've fixed your filtering with prefix lists, you need to ensure
that any "network..." statement is backed up by the presence of the very
same route in your IGP (which includes static routing).

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] BGP Route Announcement

[Joseph Mays]

Having a problem with changing a bgp route announcement to cogent. We are 
announcing 216.24.0.0/18 to cogent currently.

router bgp 
no synchronization
bgp router-id 
bgp cluster-id xxx
bgp log-neighbor-changes
bgp bestpath compare-routerid
network 216.24.0.0 mask 255.255.192.0
neighbor 38.122.142.5 remote-as 174
neighbor 38.122.142.5 description Cogent A Peer to node router
neighbor 38.122.142.5 send-community
neighbor 38.122.142.5 version 4
neighbor 38.122.142.5 soft-reconfiguration inbound
neighbor 38.122.142.5 distribute-list deny-our-nets in
neighbor 38.122.142.5 distribute-list allow-our-nets out
neighbor 38.122.142.5 route-map cogent-outbound-prefs in
neighbor 38.122.142.5 route-map cogent-out out
no auto-summary

The distribute lists shown also just contained appropriate permit and deny 
entries for 216.24.0.0 /18

Kind of against my wishes the owner of our company sold several small network 
blocks we weren't using out of the upper half of the /18. As a result I have to 
change the bgp broadcast to cogent to broadcast a 216.24.0.0/19 and several 
smaller blocks we are still using out of the upper half. I assumed if I changed 
the distribute lists it would change the routes cogent was seeing. So I changed 
those first --

ip access-list standard allow-our-nets
permit 38.103.73.193
permit 216.24.0.0 0.0.31.255
permit 216.24.35.0 0.0.0.255
permit 216.24.36.0 0.0.3.255
permit 216.24.42.0 0.0.0.255
permit 216.24.48.0 0.0.3.255
permit 216.24.53.0 0.0.0.255
permit 216.24.54.0 0.0.0.255
permit 216.24.56.0 0.0.0.255
permit 216.24.60.0 0.0.1.255
permit 216.24.62.0 0.0.0.255

ip access-list standard deny-our-nets
deny   216.24.35.0 0.0.0.255
deny   216.24.36.0 0.0.3.255
deny   216.24.42.0 0.0.0.255
deny   216.24.48.0 0.0.3.255
deny   216.24.53.0 0.0.0.255
deny   216.24.54.0 0.0.0.255
deny   216.24.56.0 0.0.0.255
deny   216.24.60.0 0.0.1.255
deny   216.24.62.0 0.0.0.255
deny   216.24.0.0 0.0.31.255
permit any

But it didn't change the broadcast cogent was receiving at all. So then I 
changed the networks statement in bgp config.

router bgp 
no synchronization
bgp router-id 
bgp cluster-id xxx
bgp log-neighbor-changes
bgp bestpath compare-routerid
network 216.24.32.0 mask 255.255.224.0
network 216.24.35.0 mask 255.255.255.0
network 216.24.36.0 mask 255.255.252.0
network 216.24.42.0 mask 255.255.255.0
network 216.24.48.0 mask 255.255.252.0
network 216.24.53.0 mask 255.255.255.0
network 216.24.54.0 mask 255.255.255.0
network 216.24.56.0 mask 255.255.255.0
network 216.24.60.0 mask 255.255.254.0
network 216.24.62.0 mask 255.255.255.0
neighbor 38.122.142.5 remote-as 174
neighbor 38.122.142.5 description Cogent A Peer to node router
neighbor 38.122.142.5 send-community
neighbor 38.122.142.5 version 4
neighbor 38.122.142.5 soft-reconfiguration inbound
neighbor 38.122.142.5 distribute-list deny-our-nets in
neighbor 38.122.142.5 distribute-list allow-our-nets out
neighbor 38.122.142.5 route-map cogent-outbound-prefs in
neighbor 38.122.142.5 route-map cogent-out out
no auto-summary

That changed the broadcast cogent was receiving, but not in the expected way. 
They only route they saw us broadcasting after that was the 216.24.60.0/23 
route. Not the first one in the list, not the last one, not the biggest one or 
the smallest one, but just one route from the middle of the list. I don't get 
this behavior at all. Cogent cleared and bounced bgp to us, and still received 
only that one route in the broadcast from us.

Can anyone tell me why I got this behavior, and what am I overlooking in 
altering our bgp config to broadcast this group of routes? Thank you for your 
patience with this message.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[adamv0025]

> 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
> control which routes are made available to the peering routers; we don't
> hold a full table there.
> 
Ha, same here, twofold actually, 

1) Started using flowspec for dealing with DDoS once inside the network -much 
better granularity, no need to throw customer over the board instantly. And the 
RTBH and Scrubbing is used to protect peering links -but that's not related to 
iBGP session ingress policies discussion.

2) Actually using ingress/egress iBGP filtering all over the place due to 
multi-planar RR infrastructure I created, -so Robert that's another use case 
for you :)

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[Mark Tinka]

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 attacked ? 
>
> Do you also do the same if this is transit traffic ? 
>
> When do you remove such black hole ? You look at the ingress counters
> to the target ? 
>
> Did you ever instead of the above considered automation to apply at
> least src-dst + ports filters with Flow Spec and just rate limit the
> malicious distributed flows  (rfc5575) ?

We provide 2 options - the poor man's one (which completes the attack)
and the paid-for one, which cleans the attack.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[Mark Tinka]

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 on peering routers.

On edge routers, it's not necessary, as the application of the RTBH
communities is a local action (which is where it would start from,
anyway, if you look at the overall network).

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[Nick Hilliard]

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 the continuity of their 
network than the uptime of a single IP address.  If a network is hit by 
a ddos which is 10x the ingress transit + peering capacity, most 
sensible people are going to blackhole the affected IP address and also 
signal to upstreams that it should be blackholed.  Unless you set out to 
design a network with enough capacity to withstand giant ddos events, 
rtbh with upstream blackholing will remain a useful tool in the box.



Is it his fault that he got attacked ?

Saturated network links don't have an opinion on blame.

But to bring things back to the topic, yes there are several 
well-established cases where policy is applied to ingress ibgp sessions.


Nick
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[Gert Doering]

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 more reach the guy. Is it
> his fault that he got attacked ?

No, but sometimes there is no other remedy.  Like, a customer has a 
larger network (say, IPv4 /23), and a single IP is attacked, filling
his pipe.  If you drop that single address, the rest of the network
can operate normally.

Would it be better to stop the attack without taking the target host
offline?  Of course!


[..]
> Did you ever instead of the above considered automation to apply at least
> src-dst + ports filters with Flow Spec and just rate limit the malicious
> distributed flows  (rfc5575) ?

Indeed, this would be superiour, but not all our hardware can do this,
and (as far as I'm aware) none of our upstream providers support this - so
if we cannot stand the volume anymore (upwards of ~50 Gbit/s), all we
can do is signal upstream "please do not deliver traffic to that target
IP"...

(What we do is rate-limit all the cheap crap, like NTP, fragments, DNS
responses to not white-listed well-known recursor addresses, to reasonable
limits - so as long as our ingress pipes are not full, we do not blackhole
destination addresses.)

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
 Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[Nick Hilliard]

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 need to apply a 
route-policy to declare "set next-hop discard", so explicit policy 
required there.


Nick
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[Robert Raszuk]

>
> 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 the same if this is transit traffic ?

When do you remove such black hole ? You look at the ingress counters to
the target ?

Did you ever instead of the above considered automation to apply at least
src-dst + ports filters with Flow Spec and just rate limit the malicious
distributed flows  (rfc5575) ?

Thx,
R.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[Tim Warnock]

> 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 those devices
> see that community (and are permitted to act on said community), traffic to
> the routes that carry the community is dropped locally on those devices.
> 

Sounds standard practice.

> 
> We don't perform any ingress iBGP policy for RTBH anywhere in the network.

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?

> 
> Mark.

-Tim.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[Mark Tinka]

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.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[Mark Tinka]

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 the route further.  

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 those devices see that community (and are permitted to act on
said community), traffic to the routes that carry the community is
dropped locally on those devices.

For manually-triggered RTBH (i.e., the NOC have to do it because the
customer does not know how to or does not want to do it themselves), we
have a dedicated router in the network that can be used as the launchpad
for RTBH signals, managed by the NOC.

We don't perform any ingress iBGP policy for RTBH anywhere in the network.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[Mark Tinka]

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 the
> iBGP perspective? After all the iBGP route would be subject to all these
> before it gets installed to RIB. 

We generally apply quite a bit of policy at the eBGP edge, i.e., with
customers, peers or upstreams. Once those policies are applied, we just
pass them as they are toward the RR's via iBGP, not touching them again.

The policy we would apply on the edge device itself that is not part of
an eBGP session would be locally-generated routes, e.g., routes that
define all point-to-point addresses used for customers attached to that
device, peers attached to that device where we are providing the
point-to-point IP addresses, e.t.c.

Then on the RR's, we can determine whether we want those routes to be
seen by the entire network, or some section of the network, based on the
BGP communities that the route arrives with at the RR. This is
influenced by the type of service the route is carrying, be it a
customer or another internal function.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[Mark Tinka]

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 comment.
>
> So for educational purposes could you describe some real valid use cases to
> apply bgp policies on routes *received* over IBGP ?

On our edge routers, it's for telling it how to handle BGP communities
that define routes whose traffic needs to be scrubbed (DoS mitigation).

On peering routers, RTBH.

But yes, that's about it.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[Mark Tinka]

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.

We actually do a lot of policy on iBGP sessions, both on the RR's and
their clients.

95% of the policies are in the outbound direction, with the rest being
inbound.

In our case, we can support both consistent and inconsistent internal
routing at the same time. It can depend on device functions, device
location or device resources.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[adamv0025]

> 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 describe some real valid use
> >cases to
> >> apply bgp policies on routes *received* over IBGP ?
> >>
> >> Thx,
> >> Robert.
> >
> >Setting local preference?
> >
> >Rewriting next hop?
> 
> Yeah, stuff like remotely triggered black hole routing is often applied as
in
> inbound iBGP policy.
> 
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 the route further.  

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[adamv0025]

> 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 *received* over
> > IBGP ?
> >
> > Thx,
> > Robert.
> 
> Setting local preference?
> 
> Rewriting next hop?
>
I  think Robert was interested in use cases not what attribute can be set in
ingress on an iBGP session.

This question got me thinking actually,

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 the
iBGP perspective? After all the iBGP route would be subject to all these
before it gets installed to RIB. 

With regards to the use cases, 
I think that one common trait of all the use cases relying on either of the
above mentioned attach points, is the need to manipulate how the route is
treated locally on the receiving BGP speaker -which ,driven by the use case,
would be in contrary with how the same route is treated on all other
speakers in the AS. (think one size does not fit all)
Thinking about it this need for ingress policy on iBGP sessions is rooted in
the fact that one (by default and no hacks) can't "process" a BGP route for
the same prefix multiple times where each copy would be intended only for a
specific receiver or a set of receivers.   
The specifics of how that is accomplished are irrelevant, but what stays is
that a policy in "ingress" direction is indeed required in these use cases. 


//yes I know I should not be using term "bgp route" in context of bgp
process and should be using term "prefix" or "path" instead.
 
adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[James Bensley]

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 *received* over IBGP ?
>> 
>> Thx,
>> Robert.
>
>Setting local preference?
>
>Rewriting next hop?

Yeah, stuff like remotely triggered black hole routing is often applied as in 
inbound iBGP policy.

Cheers,
James.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[Tim Warnock]

> -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?

Rewriting next hop?
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[Robert Raszuk]

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 some real valid use cases to
apply bgp policies on routes *received* over IBGP ?

Thx,
Robert.


On Fri, Oct 12, 2018, 00:13 heasley  wrote:

> 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 sessions, but that does meant that there are no legitimate
> applications and thus no implementation should prevent it.
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[heasley]

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 sessions, but that does meant that there are no legitimate
applications and thus no implementation should prevent it.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[Robert Raszuk]

> 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 are processed.

But if you have accept all policy for eBGP without any inbound
modifications (match/set) then iBGP vs eBGP should indeed be pretty
similar. Other processing ie. best path selection, rib insertion then fib
insertion should be quite similar timing wise regardless of the type of the
route.

Thx,
R.






On Thu, Oct 11, 2018 at 10:38 PM James Bensley  wrote:

> 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 sending route over
> eBGP must make sure that those routes are installed in data plane locally
> before being advertised.
> >
> > Of course non of this really matters if those routes are already
> installed when you trigger advertisements to UUT.
>
>
> Hi Rob, Mark,
>
> So that's not really an apples to apples comparison then. Are you
> interested in seeing the different in vRR vs. physical RR vs physical
> PE?
>
> > There are also few more little "delays" for eBGP vs iBGP depending on
> your BGP code base - regarding policy processing or origin validation :).
>
> There is nothing to stop me creating a horribly complex iBGP policy so
> I'm not sure policy length that is a factor. I was referring strictly
> to the code performance, e.g. router model A, with firmware version B,
> receives the exact same route set from an eBGP and iBGP neighbor (and
> those two neighbors are the exact same spec). Is there till scope for
> a difference in convergence time here?
>
> Cheers,
> James.
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[James Bensley]

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 sending route over eBGP 
> must make sure that those routes are installed in data plane locally before 
> being advertised.
>
> Of course non of this really matters if those routes are already installed 
> when you trigger advertisements to UUT.


Hi Rob, Mark,

So that's not really an apples to apples comparison then. Are you
interested in seeing the different in vRR vs. physical RR vs physical
PE?

> There are also few more little "delays" for eBGP vs iBGP depending on your 
> BGP code base - regarding policy processing or origin validation :).

There is nothing to stop me creating a horribly complex iBGP policy so
I'm not sure policy length that is a factor. I was referring strictly
to the code performance, e.g. router model A, with firmware version B,
receives the exact same route set from an eBGP and iBGP neighbor (and
those two neighbors are the exact same spec). Is there till scope for
a difference in convergence time here?

Cheers,
James.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[Mark Tinka]

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 before sending route over
> eBGP must make sure that those routes are installed in data plane
> locally before being advertised. 
>
> Of course non of this really matters if those routes are already
> installed when you trigger advertisements to UUT. 
>
> There are also few more little "delays" for eBGP vs iBGP depending on
> your BGP code base - regarding policy processing or origin validation :).

Yes, all the above :-).

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[Mark Tinka]

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 iBGP peer could contain the same NLRI with all of the same attributes so I 
> would expect them to pass through the same pipe line of BGP parsing and 
> processing code?

Depends on the capabilities of the other peer.

For us in iBGP, the CSR1000v is mega quick, we can load a full IPv4
table in less than a minute. I've not seen the same performance from
eBGP sessions, even when latency and bandwidth are not an issue.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[Robert Raszuk]

> 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 today are just x86 control
plane boxes with no forwarding.

On the other hand number of implementations before sending route over eBGP
must make sure that those routes are installed in data plane locally before
being advertised.

Of course non of this really matters if those routes are already installed
when you trigger advertisements to UUT.

There are also few more little "delays" for eBGP vs iBGP depending on your
BGP code base - regarding policy processing or origin validation :).

Best,
R.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[James Bensley]

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 results
>are not
>> impressive - time needed to program is aroud 2min 30sec up to 3min.
>>
>> How fast NCS 5500 is handing FIB programming ?
>
>I don't have any of these boxes (or chipsets) in my network, but out of
>curiosity, how long does it take to load the same routes in RIB,
>depending on if these are learned via iBGP (from a route reflector,
>likely) or via eBGP (from an upstream provider, for example)?
>
>Mark.

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 iBGP peer could contain the same NLRI with all of the same attributes so I 
would expect them to pass through the same pipe line of BGP parsing and 
processing code?

Cheers,
James.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[Phil Bedard]

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 30 seconds.  

Thanks, 
Phil 

On 10/5/18, 3:26 AM, "cisco-nsp on behalf of 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 results are not
> impressive - time needed to program is aroud 2min 30sec up to 3min.
>
> How fast NCS 5500 is handing FIB programming ?

I don't have any of these boxes (or chipsets) in my network, but out of
curiosity, how long does it take to load the same routes in RIB,
depending on if these are learned via iBGP (from a route reflector,
likely) or via eBGP (from an upstream provider, for example)?

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[James Bensley]

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 (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 FIB programming ?
>
> Please take a look here:
> https://xrdocs.io/cloud-scale-networking/tutorials/ncs5500-fib-programming-speed/
>  
> 
>
> --
> Łukasz Bromirski
> CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A

There is an extra video not linked in that article for a comparison of
the external TCAM to non-external:
https://www.youtube.com/watch?v=cDBMFb10ISI

Cheers,
James.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[Mark Tinka]

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 2min 30sec up to 3min.
>
> How fast NCS 5500 is handing FIB programming ?

I don't have any of these boxes (or chipsets) in my network, but out of
curiosity, how long does it take to load the same routes in RIB,
depending on if these are learned via iBGP (from a route reflector,
likely) or via eBGP (from an upstream provider, for example)?

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[Ted Pelas Johansson]

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
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 FIB programming ?

Rob
___
cisco-nsp mailing list  
cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

 IMPORTANT NOTICE 
The content of this e-mail is intended for the addressee(s) only and may 
contain information that is confidential and/or otherwise protected from 
disclosure. If you are not the intended recipient, please note that any 
copying, distribution or any other use or dissemination of the information 
contained in this e-mail (and its attachments) is strictly prohibited. If you 
have received this e-mail in error, kindly notify the sender immediately by 
replying to this e-mail and delete the e-mail and any copies thereof.

Tele2 AB (publ) and its subsidiaries (“Tele2 Group”) accepts no responsibility 
for the consequences of any viruses, corruption or other interference 
transmitted by e-mail.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP DFZ convergence time - FIB programming

[Łukasz Bromirski]

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 to program is aroud 2min 30sec up to 3min.
> 
> How fast NCS 5500 is handing FIB programming ?

Please take a look here:
https://xrdocs.io/cloud-scale-networking/tutorials/ncs5500-fib-programming-speed/
 


-- 
Łukasz Bromirski
CCIE R/SP #15929, CCDE #2012::17, PGP Key ID: 0xFD077F6A
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] BGP DFZ convergence time - FIB programming

[Robert Hass]

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 FIB programming ?

Rob
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP-ORR vRR/IOS-XRv

[adamv0025]

> Curtis Piehler
> Sent: Wednesday, March 21, 2018 10:57 PM
> 
> Thank you, with the general RR concerns out of the way I'd like to hear if
> anyone has specific BGP ORR experience in an IOS-XRv environment.
> 
I was only evaluating it as a solution for limiting advertisement of
superfluous copies of transit prefixes in Internet VRF.
The requirements:
1) one primary path and one backup path
2) complete freedom in primary path engineering (per-group/per-node)
3) complete freedom in backup path engineering (per-group/per-node)

And requirement 3 was not met with current ORR implementations, you can't
select ORR backup path, the backup path selection is governed by the
Add-Path which does not have the "2nd IGP best path" knowledge allowing it
to pick the desired backup path.

The solution was to use the good old type-1 RDs and Route-Targets to allow
for complete freedom in AS-Exit engineering.  

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP-ORR vRR/IOS-XRv

[Curtis Piehler]

Thank you, with the general RR concerns out of the way I'd like to hear if
anyone has specific BGP ORR experience in an IOS-XRv environment.

On Wed, Mar 21, 2018, 6:53 PM Mark Tinka  wrote:

>
>
> On 22/Mar/18 00:45, Curtis Piehler wrote:
>
> Sorry I should have been more clear.  I know RRs in general need to be
> fully meshed but from a BGP ORR perspective does anything change that?
> Also in a BGP ORR environment do all clients need to connected to all vRRs
> as long as the vRRs are fully meshed?
>
>
> RR-RR connectivity is a matter of course.
>
> Client-RR connectivity is a matter of redundancy. Connecting to one or 2
> RR's does not change the benefits of ORR. So one should not conflate both
> topics.
>
> Mark.
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP-ORR vRR/IOS-XRv

[Mark Tinka]

On 22/Mar/18 00:45, Curtis Piehler wrote:

> Sorry I should have been more clear.  I know RRs in general need to be
> fully meshed but from a BGP ORR perspective does anything change
> that?  Also in a BGP ORR environment do all clients need to connected
> to all vRRs as long as the vRRs are fully meshed?

RR-RR connectivity is a matter of course.

Client-RR connectivity is a matter of redundancy. Connecting to one or 2
RR's does not change the benefits of ORR. So one should not conflate
both topics.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP-ORR vRR/IOS-XRv

[Curtis Piehler]

Sorry I should have been more clear.  I know RRs in general need to be
fully meshed but from a BGP ORR perspective does anything change that?
Also in a BGP ORR environment do all clients need to connected to all vRRs
as long as the vRRs are fully meshed?

On Mar 21, 2018 6:42 PM, "Mark Tinka"  wrote:



On 18/Mar/18 22:20, Curtis Piehler wrote:


BGP-ORR looks to be an attractive technology to utilize instead of full
meshing many standard RRs.  I was hoping people could share some insight on
this topic since there is not so much real world scenarios out there
documented.  This is geared towards an IOS-XRv ASR9K deployment.


I have no ORR experience yet since it's not yet supported in CSR1000v.
However, I don't think ORR creates an opportunity not to fully mesh RR's.

The idea around ORR is to allow RR clients to enjoy a "localized" view of
the route (IGP metric, to be exact) despite where the RR they have an iBGP
session with is physically located. This does not negate the need to fully
mesh the RR's.


Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP-ORR vRR/IOS-XRv

[Mark Tinka]

On 18/Mar/18 22:20, Curtis Piehler wrote:

> BGP-ORR looks to be an attractive technology to utilize instead of full
> meshing many standard RRs.  I was hoping people could share some insight on
> this topic since there is not so much real world scenarios out there
> documented.  This is geared towards an IOS-XRv ASR9K deployment.

I have no ORR experience yet since it's not yet supported in CSR1000v.
However, I don't think ORR creates an opportunity not to fully mesh RR's.

The idea around ORR is to allow RR clients to enjoy a "localized" view
of the route (IGP metric, to be exact) despite where the RR they have an
iBGP session with is physically located. This does not negate the need
to fully mesh the RR's.

Mark.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] BGP-ORR vRR/IOS-XRv

[Saku Ytti]

One thing to be aware of is that ORR in Cisco won't reflect anything
if next-hop is not IGP next-hop.

If you, like many networks do, have BGP routes with BGP next-hop,
which recurses to IGP next-hop, these won't be reflected.

Obviously the RR cannot know for a fact where the BGP next-hop would
recurse at client's POV, but I'd settle for a best guess.

JunOS ORR implementation does this.


Clients of ORR RR will see at most as many copies of routes as there
are RR peers, in absence of AddPath.

I'm not ready to re-explain how RR in basics work, after the previous
thread is so young, regarding your question of how to mesh and such.

On 21 March 2018 at 16:33, Curtis Piehler  wrote:
>  BGP-ORR looks to be an attractive technology to utilize instead of full
> meshing many standard RRs.  I was hoping people could share some insight on
> this topic since there is not so much real world scenarios out there
> documented.  This is geared towards an IOS-XRv ASR9K deployment.
>
>
>- When running BGP-ORR a vRR computes the shortest path for a given
>BGP-ORR enabled client from the perceptive of the client utilizing the root
>node of a BGP-ORR
>- For this reason is it suggested that BGP-ORR groups are configured
>with respect to common views of the network (IE: grouped by POP/Region)
>instead of having one or two ORR Groups?
>- What is the suggested max number of BGP-ORR groups per vRR?
>- What is the suggested max number of clients per BGP-ORR group?
>- If all clients in the network peer with say 2 vRR as the center will
>those clients only see maximum two BGP paths (This is assuming add-path is
>not utilized)
>- Do all clients need to peer with all vRRs as long as the vRRs are
>fully meshed?
>- Can anyone share general experience they had with BGP-ORR deployed in
>a production backbone?
>- Are there any substantial gotchas to be concerned with?
>
>
> As per Cisco documentation when running OSPF a basic MPLS-TE configuration
> is required on all root nodes, correct?
>
> Specific to IOS-XRv does anyone know how the new "SUB" licence models
> work?  I have not been able to find Cisco documentation that explains
> this.  The perpetual/term licence model goes End of Sale Q3 of this year.
>
> https://www.cisco.com/c/en/us/td/docs/routers/virtual-routers/xrv9k-62x/general/release/notes/b-release-notes-xrv9k-623.html
>
> Thanks
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/



-- 
  ++ytti
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] BGP-ORR vRR/IOS-XRv

[Curtis Piehler]

 BGP-ORR looks to be an attractive technology to utilize instead of full
meshing many standard RRs.  I was hoping people could share some insight on
this topic since there is not so much real world scenarios out there
documented.  This is geared towards an IOS-XRv ASR9K deployment.


   - When running BGP-ORR a vRR computes the shortest path for a given
   BGP-ORR enabled client from the perceptive of the client utilizing the root
   node of a BGP-ORR
   - For this reason is it suggested that BGP-ORR groups are configured
   with respect to common views of the network (IE: grouped by POP/Region)
   instead of having one or two ORR Groups?
   - What is the suggested max number of BGP-ORR groups per vRR?
   - What is the suggested max number of clients per BGP-ORR group?
   - If all clients in the network peer with say 2 vRR as the center will
   those clients only see maximum two BGP paths (This is assuming add-path is
   not utilized)
   - Do all clients need to peer with all vRRs as long as the vRRs are
   fully meshed?
   - Can anyone share general experience they had with BGP-ORR deployed in
   a production backbone?
   - Are there any substantial gotchas to be concerned with?


As per Cisco documentation when running OSPF a basic MPLS-TE configuration
is required on all root nodes, correct?

Specific to IOS-XRv does anyone know how the new "SUB" licence models
work?  I have not been able to find Cisco documentation that explains
this.  The perpetual/term licence model goes End of Sale Q3 of this year.

https://www.cisco.com/c/en/us/td/docs/routers/virtual-routers/xrv9k-62x/general/release/notes/b-release-notes-xrv9k-623.html

Thanks
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] BGP-ORR vRR/IOS-XRv

[Curtis Piehler]

I realize my previous post about MCID across a RR backbone generated
various difference in opinions so hopefully this topic is a bit more cut
and dry.

BGP-ORR looks to be an attractive technology to utilize instead of full
meshing many standard RRs.  I was hoping people could share some insight on
this topic since there is not so much real world scenarios out there
documented.  This is geared towards an IOS-XRv ASR9K deployment.


   - When running BGP-ORR a vRR computes the shortest path for a given
   BGP-ORR enabled client from the perceptive of the client utilizing the root
   node of a BGP-ORR
   - For this reason is it suggested that BGP-ORR groups are configured
   with respect to common views of the network (IE: grouped by POP/Region)
   instead of having one or two ORR Groups?
   - What is the suggested max number of BGP-ORR groups per vRR?
   - What is the suggested max number of clients per BGP-ORR group?
   - If all clients in the network peer with say 2 vRR as the center will
   those clients only see maximum two BGP paths (This is assuming add-path is
   not utilized)
   - Do all clients need to peer with all vRRs as long as the vRRs are
   fully meshed?
   - Can anyone share general experience they had with BGP-ORR deployed in
   a production backbone?
   - Are there any substantial gotchas to be concerned with?


As per Cisco documentation when running OSPF a basic MPLS-TE configuration
is required on all root nodes, correct?

Specific to IOS-XRv does anyone know how the new "SUB" licence models
work?  I have not been able to find Cisco documentation that explains
this.  The perpetual/term licence model goes End of Sale Q3 of this year.

https://www.cisco.com/c/en/us/td/docs/routers/virtual-routers/xrv9k-62x/general/release/notes/b-release-notes-xrv9k-623.html

Thanks
Curtis
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/