Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FRR does not accept routes when peer AS same as Sub-AS within a confederation #17125

Open
2 tasks done
rsingha108 opened this issue Oct 15, 2024 · 1 comment
Open
2 tasks done
Assignees
Labels
bgp triage Needs further investigation

Comments

@rsingha108
Copy link

rsingha108 commented Oct 15, 2024

Description

I have an Exabgp and two FRR routers (frr1 & frr2) connected in series. If frr1 is in Sub-AS 3001 within confederation AS 30, and frr2 is in AS 3001 not within any confederation, then route is not advertised to frr2. i.e. if the peer AS and confederation sub AS becomes same, then route is not advertised.

Version

FRR version 10.1

How to reproduce

Topology:

exabgp (3.0.0.3) ----- (3.0.0.2) frr1 (4.0.0.2) ----- (4.0.0.3) frr2
[AS 40]                [confedAS 30, subAS 3001]              [AS 3001]  

Exabgp Configuration:

process announce-routes {
    run python exabgp/example.py;
    encoder json;
}

neighbor 3.0.0.2 {                 # Remote neighbor to peer with
    router-id 3.0.0.3;              # Our local router-id
    local-address 3.0.0.3;          # Our local update-source
    local-as 40;                    # Our local AS
    peer-as 30;                     # Peer's AS

    api {
        processes [announce-routes];
    }
}

And I am sending the following route using ExaBGP:

announce route 100.10.0.0/24 next-hop self as-path [1 2]

Configuration of router frr1:


log file /var/log/frr/bgpd.log
debug bgp updates

router bgp 3001 

  bgp confederation identifier 30  

  no bgp ebgp-requires-policy

  neighbor 3.0.0.3 remote-as 40

  neighbor 4.0.0.3 remote-as 3001

  neighbor 3.0.0.3 soft-reconfiguration inbound

  neighbor 4.0.0.3 soft-reconfiguration inbound
  
  network 3.0.0.0

  network 4.0.0.0

Configuration of router frr2:

log file /var/log/frr/bgpd.log
debug bgp updates

router bgp 3001

  no bgp ebgp-requires-policy

  neighbor 4.0.0.2 remote-as 30

  neighbor 4.0.0.2 soft-reconfiguration inbound
  
  network 4.0.0.0

Expected behavior

As only frr1 is within a confederation, and frr2 is external, frr2 should not see the subAS of frr1, but it should see AS of frr1 same as the confederation AS i.e. 30

So it is expected that frr2 will receive the route from frr1 and the as-path will be appended by 30

Actual behavior

frr2 doesn't receive the route.

Additional context

No response

Checklist

  • I have searched the open issues for this bug.
  • I have not included sensitive information in this report.
@rsingha108 rsingha108 added the triage Needs further investigation label Oct 15, 2024
@ton31337 ton31337 added the bgp label Oct 16, 2024
@ton31337 ton31337 self-assigned this Oct 16, 2024
@ton31337
Copy link
Member

I tested (master branch) with your configuration (similar):

exabgp:

router bgp 40
 no bgp ebgp-requires-policy
 no bgp network import-check
 neighbor 192.168.1.1 remote-as external
 !
 address-family ipv4 unicast
  network 172.16.255.254/32
 exit-address-family
exit
!

frr1:

router bgp 3001
 no bgp ebgp-requires-policy
 bgp confederation identifier 30
 neighbor 192.168.1.2 remote-as external
 neighbor 192.168.2.2 remote-as internal
exit
!

frr2:

router bgp 3001
 no bgp ebgp-requires-policy
 no bgp network import-check
 neighbor 192.168.2.1 remote-as internal
exit
!

The output from r2 (AS40 is added):

r3# show bgp ipv4 unicast 172.16.255.254/32
BGP routing table entry for 172.16.255.254/32, version 1
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  40
    192.168.2.1 from 192.168.2.1 (192.168.2.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best (First path received)
      Last update: Fri Oct 18 10:34:59 2024
r3# 

This seems correct, could you test at least with the newer versions?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bgp triage Needs further investigation
Projects
None yet
Development

No branches or pull requests

2 participants