rare-freertr / validated-design

RARE/freeRTr Validated Design
Apache License 2.0
6 stars 0 forks source link

BGP sessions do not go up for eBGP #1

Closed tducatelle-criann closed 1 year ago

tducatelle-criann commented 1 year ago

Hi everyone,

I have a problem with BGP sessions. Actually when the neighbors are with the same AS number there is no problem, however as soon as the remote AS is different the session does not go up at all.

I'm working on a Debian stable where I've bound my VM's interface to the port being used by the freertr to access outside, and it works I manage to ping the remote device:

leh100001#ping 172.17.255.5 vrf CORE                                                                    
pinging 172.17.255.5, src=null, vrf=CORE, cnt=5, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=-1, sweep=false, multi=false
!!!!!
result=100.0%, recv/sent/lost/err=5/5/0/0, took 17, min/avg/max/dev rtt=0/0.0/0/0.0, ttl 255/255/255/0.0, tos 0/0.0/0/0.0

But the BGP session does not go up:

leh100001#show ipv4 bgp 1 summary                                                                       
neighbor         as     ready  learn  sent  uptime
172.17.255.6     1234   false  0      0     never

Here is the freertr ethernet interface configuration and BGP configuration:

interface ethernet4
 description freertr@ens256
 vrf forwarding CORE
 ipv4 address 172.17.255.5 255.255.255.252
 no shutdown
 no log-link-change
 exit
router bgp4 1
 vrf CORE
 local-as 64919
 router-id 194.199.218.216
 address-family unicast multicast vpnuni ovpnuni vpls evpn
 !
 neighbor 172.17.255.6 remote-as 1234
 neighbor 172.17.255.6 local-as 64919
 neighbor 172.17.255.6 address-family unicast multicast vpnuni ovpnuni vpls evpn
 neighbor 172.17.255.6 distance 20

I also disabled the tcp offload on the VM interface

~# ethtool --show-offload ens256 | grep tcp
tcp-segmentation-offload: off
    tx-tcp-segmentation: off
    tx-tcp-ecn-segmentation: off [fixed]
    tx-tcp-mangleid-segmentation: off
    tx-tcp6-segmentation: off

And here is the configuration of the equipment in front (IOS-XR):

interface GigabitEthernet0/0/0/32
 vrf management
 ipv4 address 172.17.255.6 255.255.255.252
router bgp 1234
   address-family ipv4 unicast
   redistribute connected
  !
  neighbor 172.17.255.5
   remote-as 64919
   address-family ipv4 unicast
    route-policy 0011338SIT_management_v4_in in
    route-policy PASS-ALL out
    soft-reconfiguration inbound always

Thanks in advance for your help.

frederic-loui commented 1 year ago

Actually when the neighbors are with the same AS number there is no problem,

mmhh. this is ringing some bells ... IIRC ios-xr with eBGP require rpl to pass in and pass out.

Is it possible to try with pass in/out all with eBGP ? Please follow this eBGP interop test case with Cisco IOS-XR:

As you also have access to both routers you can:

On freeRtr:

AMS0001#debug proto bgp ?
  computation - computation events
  dampening   - dampening events
  error       - error events
  event       - table events
  full        - full events
  incremental - incremental events
  traffic     - interface packets

and enable current terminal to receive event from freeRtr:

AMS0001#terminal monitor
AMS0001#info ipIfc4.sendMpls:ipIfc4.java:247 protocol not enabled on sdn2
AMS0001#
AMS0001#
AMS0001#info ipIfc6.sendMpls:ipIfc6.java:375 protocol not enabled on sdn2
AMS0001#no tinfo ipIfc4.sendMpls:ipIfc4.java:247 protocol not enabled on sdn2
...

In order to disable current terminal outpu:

AMS0001#term no mon
tducatelle-criann commented 1 year ago

Indeed the pass in/out makes it work perfectly !

Thank you

frederic-loui commented 1 year ago

Indeed the pass in/out makes it work perfectly !

Thank you

Glad that it worked for you. But keep in mind that it is not a coincidence if Cisco by default prevent eBGP peering to be established. In your operational procedure you'd need to tune rpl in/out to pass legitimate traffic. Please consider then to adjust the rpl and avoid the pass in/out all :grinning: