- CheckMates
- :
- Products
- :
- CloudMates Products
- :
- Cloud Network Security
- :
- Discussion
- :
- BGP does not import route from second peer
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
BGP does not import route from second peer
Hi Guys,
We are currently configuring checkpoint to connect to two BGP peer using different AS. We have configure routemap to import routes coming from these two AS with specific local preference.
local AS number is 138932. we have setup two routemap rules which stated as below:
set routemap ipv4-new-import id 6 on
set routemap ipv4-new-import id 6 allow
set routemap ipv4-new-import id 6 match as 38182 on
set routemap ipv4-new-import id 6 action localpref 15
set routemap jbix-import id 5 on
set routemap jbix-import id 5 allow
set routemap jbix-import id 5 match as 2.6937 on
set routemap jbix-import id 5 action localpref 10
the issue that we have is that it seems like our checkpoint firewall manage to import route from AS 38182 but not from AS138009.
i can confirm that there are routes being distribute from peer AS 138009 as i can see these routes with state Hidden and inactive when i run show route bgp all
below are output from show bgp peers
PeerID AS Routes ActRts State InUpds OutUpds Uptime
x.x.x.x 38182 782587 782585 Established 139987 1 00:22:32
y.y.y.y 2.6937 66241 0 Established 12965 1 00:25:08
we try to simulate AS 38182 as down and still the route from AS 138009 is not being imported. i did try to change the routemap from using match as number to match nexthop, but still with no luck.
i have also try to disable routemap and use inbound route filter instead, still not able to import routes coming from AS138009.
would appreciate if anyone could help on this.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
After debugging the routed logs for sometime, i just notice that the peer is actually sending the first AS with a different AS number instead of his 138009 . Enabling ignore the first AS does help to activate and import the routes coming from the problematic AS 138009.
So it can consider solved. 😂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I also never seen a dot used inside the AS number.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The AS number that you see is valid. it is actually a production AS number that our customer is getting from APNIC. by default when you add this AS number it will change directly to dot number.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would suggest to involve TAC to resolve the issue !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We are currently doing a POC, i believe TAC will required a valid license and support to troubleshoot. am i correct?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
we have request some help from peering member. so far they had give us some sample configuration that should work. However, based on the sample configuration it is required to enabled next-hop-self configuration on each peer. i believe it is the same as nexthop-self in check point configuration.
Based on my testing, nexthop-self can only be enabled when you are using confederation configuration. i try to search on how to enable nexthop-self using normal AS configuration instead of using confederation. does anybody know how to do this? below are the sample config from peer member that should work. just looking a way how to convert this to checkpoint based configurations.
router bgp (peer asn) bgp log-neighbor-changes no bgp enforce-first-as no bgp default ipv4-unicast neighbor XXX-RS-v4 peer-group neighbor XXX-RS-v4 remote-as 138009 neighbor XXX-RS-v4 description XXX-RS-IPv4-Peering-Lan neighbor XXX-RS-v6 peer-group neighbor XXX-RS-v6 remote-as 138009 neighbor XXX-RS-v6 description XXX-RS-IPv6-Peering-Lan neighbor x.x.x.x remote-as 138009 neighbor x.x.x.x peer-group XXX-RS-v4 neighbor x.x.x.x description RS1 neighbor x.x.x.y remote-as 138009 neighbor x.x.x.y peer-group XXX-RS-v4 neighbor x.x.x.y description RS2 neighbor dddd:dddd::1 remote-as 138009 neighbor dddd:dddd::1 peer-group XXX-RS-v6 neighbor dddd:dddd::1 description RS0 neighbor dddd:dddd::2 remote-as 138009 neighbor dddd:dddd::2 peer-group XXX-RS-v6 neighbor dddd:dddd::2 description RS1 ! address-family ipv4 neighbor x.x.x.x activate neighbor x.x.x.y activate neighbor XXX-RS-v4 send-community neighbor XXX-RS-v4 next-hop-self exit-address-family ! address-family ipv6 neighbor dddd:dddd::1 activate neighbor dddd:dddd::2 activate neighbor XXX-RS-v6 send-community neighbor XXX-RS-v6 next-hop-self exit-address-family !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
After debugging the routed logs for sometime, i just notice that the peer is actually sending the first AS with a different AS number instead of his 138009 . Enabling ignore the first AS does help to activate and import the routes coming from the problematic AS 138009.
So it can consider solved. 😂