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
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
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
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
>
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
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
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
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
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
@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 ASR9
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
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
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?
Welcome to BGP.
Thank you.
A BGP speaker is only going to advertise its best external paths via
iBGP. If it has selected your other BGP speaker as its best path, it
will not (currently) advertise the externals that are not the best path.
So there is some sort of withdrawal mechanism:
Hi guys,
there is something I can't quite figure out with BGP.
Let a bi-homed AS with only two BGP speakers (each of them has one eBGP
session with a different upstream, they speak iBGP together).
Router 1 receives 238k routes from provider A; so does router 2 from
provider B.
When looking
there is something I can't quite figure out with BGP.
Let a bi-homed AS with only two BGP speakers (each of them has one
eBGP
session with a different upstream, they speak iBGP together).
Router 1 receives 238k routes from provider A; so does router 2 from
provider B.
When looking at
Welcome to BGP.
A BGP speaker is only going to advertise its best external paths via
iBGP. If it has selected your other BGP speaker as its best path, it
will not (currently) advertise the externals that are not the best path.
If you examine your BGP RIB closely, you should be able
On Jan 24, 2008, at 7:22 PM, Deepak Jain wrote:
In your opinion, is there any downside to this behavior
operationally (other than the time it takes for a unadvertised
route to present itself in the event the advertised route is
withdrawn?)?
Other than that, Mrs. Lincoln, how was the
On Thu, 24 Jan 2008, Tony Li wrote:
there is something I can't quite figure out with BGP.
Let a bi-homed AS with only two BGP speakers (each of them has one
eBGP
session with a different upstream, they speak iBGP together).
Router 1 receives 238k routes from provider A; so does router 2
19 matches
Mail list logo
