Duplicate peer definition may be non-fatal

[vincentbernat]

ISSUE TYPE

• Feature Idea

OS

Debian Linux

VERSION

ExaBGP : 4.0.2-1c737d99
Python : 3.6.4 (default, Dec 19 2017, 14:09:48)  [GCC 7.2.0]
Uname  : Linux zoro 4.14.0-1-amd64 #1 SMP Debian 4.14.2-1 (2017-11-30) x86_64
Root   :

CONFIGURATION

neighbor 80.81.195.174 {
 ...
}
neighbor 80.81.195.174 {
 ...
}

SUMMARY

Currently, when a neighbor is defined twice, we get a "duplicate peer definition" error. However, when ExaBGP is not using listen, there should be no problem in connecting to a peer twice. This could be done with a different local-address for each connection.

Here is a proposition to fix that:

• accept a non-IP name for neighbor
• peer-address defaults to name if this is an IP
• ensure peer-address is present (either through name or directly)
• modify unicity check to use name and not peer-address

Am I missing something?

[vincentbernat]

So far, my only difficulty is using the neighbor name as peer-address if not present.

[thomas-mangin]

Good idea but if the same IP are setup for both side we should use multi-protocol RFC 4760 (which is already implemented).

[SivaKesava1]

@vincentbernat and @thomas-mangin Is the feature added or is still in progress? We are using Exabgp extensively to test our system which might require the above scenario.

Is the following config possible:

neighbor 11.10.2.1{                        
    local-address 1.1.1.1;          
    local-as 800;                   
    peer-as 200;         
}
neighbor 11.10.2.1{                     
    local-address 2.2.2.2;          
    local-as 700;                   
    peer-as 200;            
}

or is there a way to specify neighbor-name instead of IP address in the first line?

[cjeker]

I really would like this feature. I was able to use this in 3.4 but now this no longer works. My goal is to simulate many peers without having to run individual processes for each since that just does not scale. I would like this so that testing large IXP setups is possible without running 1000 of python processes.

Ideally using one API endpoint to fill all neighbors at once (using 'neighbor 11.10.2.1 local-as 700 announce ...' to select the right session).

[thomas-mangin]

@cjeker please let me know if it does the trick :-)

[cjeker]

@thomas-mangin: yes, this seems to do indeed what I hoped for. I can now run a single exabgp doing roughly 80 connections to the same route server but each connection is using a different local-as and local-address. It seems to work nicely. Thanks a lot.

[thomas-mangin]

@vincentbernat do you mean that when using the API controlling what peers get what command was causing issue .. if you can remember :-p

[vincentbernat]

I didn't even remember this issue was mine until you mentioned me! ;-)

[thomas-mangin]

@vincentbernat thank you for the reply .. something for me to check then ! ;-)