Solved: Re: General BGP issue and need a help with it - Page 2

blason · ‎09-02-2022

Hi Team,

I need a help with BGP and my setup is as below. There is no cisco routers involved however I need a help on BGP issue. I have a router installed at my end and I have two ISPs terminated on those. I have then configured two IPsec tunnels with Azure and I am running BGP over IPsec.

However I noticed here that 192.168.40.0/23 route is only advertised from 169.254.21.9 and if I check routes on 169.254.21.13 I am seeing 192.168.40.0/23 is learned from Azure. However the subnet belongs to me.

show ip bgp neighbors 169.254.21.1 received-routes
Default local pref 100, local AS 65506
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @nnn nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.1.0.0/16      169.254.21.1                           0 65515 i
***> 10.11.44.0/22    169.254.21.1                           0 65515 i**

While for other Peer

show ip bgp neighbors 169.254.22.1 received-routes
Default local pref 100, local AS 65506
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @nnn nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.1.0.0/16      169.254.22.1                           0 65515 i
*> 10.11.44.0/22    169.254.22.1                           0 65515 65515 65515 65515 i
*> 192.168.40.0/23  169.254.22.1             0             0 65515 65506 i

If notice here 192.168.40.0/23 which is my subnet getting advertised by Azure and is sending it to me. Even If I look at the path its been received via 65515 which is Azure and then mine. This is pretty surprising and Azure if receiving with igp.

Hence wanted to know even if I am advertising the routes in Global BGP; how can I ensure that routes are being advertised to both my neighbors?
And if not how would I advertise with specific neighbor like cisco?

Hence my issue is if 169.254.21.1 goes down my traffic stops completely and I suspect is; since 192.168.40.0/23 is being learned from azure; Azure it not sending the traffic back.

Can someone please help me on this issue?

TIA

Blason R

blason · ‎09-03-2022

Here is BGP config and added

route-map

as per Azure direction for AS-path prepend

show configuration commands | match bgp
set protocols bgp 65506 address-family ipv4-unicast network 192.168.40.0/23
set protocols bgp 65506 neighbor 169.254.21.1 address-family ipv4-unicast route-map import 'accept-only-s4'
set protocols bgp 65506 neighbor 169.254.21.1 address-family ipv4-unicast soft-reconfiguration inbound
set protocols bgp 65506 neighbor 169.254.21.1 disable-connected-check
set protocols bgp 65506 neighbor 169.254.21.1 remote-as '65515'
set protocols bgp 65506 neighbor 169.254.21.1 timers holdtime '30'
set protocols bgp 65506 neighbor 169.254.21.1 timers keepalive '15'
set protocols bgp 65506 neighbor 169.254.21.1 update-source '169.254.21.13'
set protocols bgp 65506 neighbor 169.254.22.1 address-family ipv4-unicast route-map export 'low-pref-vodafone'
set protocols bgp 65506 neighbor 169.254.22.1 address-family ipv4-unicast route-map import 'low-pref-vodafone'
set protocols bgp 65506 neighbor 169.254.22.1 address-family ipv4-unicast soft-reconfiguration inbound
set protocols bgp 65506 neighbor 169.254.22.1 disable-connected-check
set protocols bgp 65506 neighbor 169.254.22.1 remote-as '65515'
set protocols bgp 65506 neighbor 169.254.22.1 timers holdtime '30'
set protocols bgp 65506 neighbor 169.254.22.1 timers keepalive '15'
set protocols bgp 65506 neighbor 169.254.22.1 update-source '169.254.21.9'

Here are route-maps

set policy route-map accept-only-s4 rule 2 action 'deny'
set policy route-map accept-only-s4 rule 2 description 'Accept only S4 route and deny GBL subnets'
set policy route-map accept-only-s4 rule 2 match ip address prefix-list 'accept-only-s4'
set policy route-map accept-only-s4 rule 4 action 'permit'
set policy route-map low-pref-vodafone rule 2 action 'permit'
set policy route-map low-pref-vodafone rule 2 match ip address prefix-list 'low-pref-vodafone'
set policy route-map low-pref-vodafone rule 2 set as-path-prepend '65515 65515 65515'
set protocols bgp 65506 neighbor 169.254.21.1 address-family ipv4-unicast route-map import 'accept-only-s4'
set protocols bgp 65506 neighbor 169.254.22.1 address-family ipv4-unicast route-map export 'low-pref-vodafone'
set protocols bgp 65506 neighbor 169.254.22.1 address-family ipv4-unicast route-map import 'low-pref-vodafone'

Harold Ritter · ‎09-03-2022

Hi @blason ,

Two things I notice.

1- it looks like the import

route-map

for 169.254.22.1 is wrong. Shouldn't it be the same as for the other peer (accept-only-s4)?

2- Do you have a prefix-list named "low-pref-vodafone"? If so, does it match 192.168.40.0/23?

Regards,

Regards,
Harold Ritter, CCIE #4168 (EI, SP)

MHM Cisco World · ‎09-03-2022

return to identify issue
VYOS router and run to IPSec (VTI tunnel) to AZURE.
run BGP over VTI tunnel
point to check
1- both VTI must be UP/UP and IPsec is establish
note the VTI need static or dynamic routing to reach the destination of VTI tunnel
2-BGP VYOS must see two neighbor not only ONE
3- check the AS you enter for remote-as with both AZURE neighbor

share the

show ip bgp

for VYOS (all)
share the

show ip route

blason · ‎09-03-2022

Your understanding correct

And my both neighbors are up; however in case my primary link goes down traffic does not pass through

show ip bgp
BGP table version is 7128, local router ID is 111.125.226.237, vrf id 0
Default local pref 100, local AS 65506
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @nnn nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.1.0.0/16      169.254.21.1                           0 65515 i
*  10.11.44.0/22    169.254.22.1                           0 65515 65515 65515 65515 i
*>                  169.254.21.1                           0 65515 i
*> 192.168.40.0/23  0.0.0.0                  0         32768 i

Displayed  3 routes and 4 total paths

show ip bgp summary

IPv4 Unicast Summary:
BGP router identifier 111.125.226.237, local AS number 65506 vrf-id 0
BGP table version 7128
RIB entries 9, using 1656 bytes of memory
Peers 2, using 41 KiB of memory

Neighbor        V         AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd
169.254.21.1    4      65515 1451014 1276375        0    0    0 03:43:06            2
169.254.22.1    4      65515 1407367 1238094        0    0    0 00:08:09            1

Total number of neighbors 2

However as I said if 169.254.21.1 goes down traffic does not switch over

 show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued route, r - rejected route

S>* 0.0.0.0/0 [1/0] via 111.125.226.225, eth1, 1d07h20m
B>  10.1.0.0/16 [20/0] via 169.254.21.1 (recursive), 03:43:59
  *                      via 169.254.21.1, vti4 onlink, 03:43:59
B>  10.11.44.0/22 [20/0] via 169.254.21.1 (recursive), 03:43:59
  *                        via 169.254.21.1, vti4 onlink, 03:43:59
C>* 10.144.144.16/28 is directly connected, eth7, 03w2d04h
S>* 20.219.153.181/32 [1/0] via 42.104.97.105, eth0, 02w0d02h
C>* 42.104.97.104/29 is directly connected, eth0, 02w0d02h
C>* 111.125.226.224/28 is directly connected, eth1, 1d07h20m
S>* 169.254.21.1/32 [1/0] is directly connected, vti4, 03:43:59
C>* 169.254.21.8/30 is directly connected, vti2, 03:50:36
C>* 169.254.21.12/30 is directly connected, vti4, 03:43:59
S>* 169.254.22.1/32 [1/0] is directly connected, vti2, 03:50:36
S>* 172.105.43.36/32 [1/0] via 42.104.97.105, eth0, 02w0d02h
S>* 192.168.10.0/24 [1/0] via 10.144.144.18, eth7, 03w2d04h
S>* 192.168.11.0/24 [1/0] via 10.144.144.18, eth7, 03w2d04h
S>* 192.168.40.0/23 [1/0] via 10.144.144.18, eth7, 03w2d04h

MHM Cisco World · ‎09-03-2022

One thing here to test this,
you mention the 169.254.21.1 egress interface down, but BGP is TCP base
So can you ping the 169.254.21.1 when the egress interface to it is down?

blason · ‎09-03-2022

Nope for sure - This is tested so many times.

MHM Cisco World · ‎09-03-2022

what is in my mind the BGP dont detect the neighbor down because you have other path to neighbor than the egress interface down.
this make BGP dont detect the down of neighbor and never withdraw the prefix.

blason · ‎09-03-2022

Let me try shutting down the primary interface and observe the VTI status. Any thing else you can suggest me to check when I take downtime?

MHM Cisco World · ‎09-03-2022

Vti tunnel destination is use which path when primary is down ?

blason · ‎09-03-2022

I am doing it now

blason · ‎09-03-2022

ping 169.254.21.1
PING 169.254.21.1 (169.254.21.1) 56(84) bytes of data.
From 169.254.21.13 icmp_seq=1 Destination Host Unreachable
From 169.254.21.13 icmp_seq=2 Destination Host Unreachable
^C
--- 169.254.21.1 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1008ms

ping 169.254.22.1
PING 169.254.22.1 (169.254.22.1) 56(84) bytes of data.
64 bytes from 169.254.22.1: icmp_seq=1 ttl=128 time=14.3 ms
64 bytes from 169.254.22.1: icmp_seq=2 ttl=128 time=13.7 ms
64 bytes from 169.254.22.1: icmp_seq=3 ttl=128 time=13.4 ms
^C
--- 169.254.22.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 13.402/13.825/14.346/0.414 ms


show ip bgp
BGP table version is 7130, local router ID is 111.125.226.237, vrf id 0
Default local pref 100, local AS 65506
Status codes:  s suppressed, d damped, h history, * valid, > best, = multipath,
               i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @nnn nexthop's vrf id, < announce-nh-self
Origin codes:  i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.11.44.0/22    169.254.22.1                           0 65515 65515 65515 65515 i
*> 192.168.40.0/23  0.0.0.0                  0         32768 i

show interfaces
eth0             42.104.xx.xx/29                  u/u
eth1             111.125.xx.xx/28                A/D
eth2             -                                 u/D
eth3             -                                 u/D
eth4             -                                 u/D
eth5             -                                 u/D
eth6             -                                 u/D
eth7             10.144.144.17/28                  u/u
lo               127.0.0.1/8                       u/u
                 ::1/128
vti2             169.254.21.9/30                   u/u  Azure WAI Vodfone Tunnel
vti4             169.254.21.13/30                  u/u  Azure WAI Inspire Tunnel

show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued route, r - rejected route

B>  10.11.44.0/22 [20/0] via 169.254.22.1 (recursive), 00:02:27
  *                        via 169.254.22.1, vti2 onlink, 00:02:27
C>* 10.144.144.16/28 is directly connected, eth7, 03w2d05h
S>* 20.219.153.181/32 [1/0] via 42.104.97.105, eth0, 02w0d03h
C>* 42.104.97.104/29 is directly connected, eth0, 02w0d03h
C>* 169.254.21.8/30 is directly connected, vti2, 05:07:15
S>* 169.254.22.1/32 [1/0] is directly connected, vti2, 05:07:15
S>* 172.105.43.36/32 [1/0] via 42.104.97.105, eth0, 02w0d03h
S>* 192.168.10.0/24 [1/0] via 10.144.144.18, eth7, 03w2d05h
S>* 192.168.11.0/24 [1/0] via 10.144.144.18, eth7, 03w2d05h
S>* 192.168.40.0/23 [1/0] via 10.144.144.18, eth7, 03w2d05h

MHM Cisco World · ‎09-03-2022

*> 10.11.44.0/22    169.254.22.1                           0 65515 65515 65515 65515 i
*> 192.168.40.0/23  0.0.0.0                  0         32768 i

Now when the VTI is down the BGP work prefect as you see in

show ip bgp

you must make someting to VTI to be follow the tunnel destination.
waiting your reply

blason · ‎09-03-2022

Yes the BGP works perfectly fine but traffic does not reach to destination
and one of the reason I saw is may be 40.0/23 is being received by other
peer.

And this is what I am not able to figure it out.

blason · ‎09-03-2022

VTI Interface went down

Interface        IP Address                        S/L  Description
---------        ----------                        ---  -----------
eth0             42.104.xx.xx/29                  u/u
eth1             111.125.xx.xx/28                A/D
eth2             -                                 u/D
eth3             -                                 u/D
eth4             -                                 u/D
eth5             -                                 u/D
eth6             -                                 u/D
eth7             10.144.144.17/28                  u/u
lo               127.0.0.1/8                       u/u
                 ::1/128
vti2             169.254.21.9/30                   u/u  Azure WAI Vodfone Tunnel
vti4             169.254.21.13/30                  A/D  Azure WAI Inspire Tunnel

MHM Cisco World · ‎09-03-2022

I run small lab for the your case, I run GRE (instead of VTI) between R1 and R4
and run GRE between R1 and R5

I shut Down the in S3/0 in R2

but the R1 still use path to R4 for 45.45.45.45/32 !! and here what you see for first issue, the connection failed.

the other issue is R5 prefer for 1.1.1.1/32 the path via R4 instead of direct path via R1 ?
I dont full get this issue but the play with AS-Path prepend may do that HOW?
the we want to make 1.1.1.1/32 inbound via R4, and hence we make AS-PATH prepend for path toward R5,
BUT there are two path for R5 now
one via R4 and other Via R1
and because we use as-path prepend the R5 select path via R4.
this health if both R4 and R5 server same subnet.