get bgp 10.XX.XX.20/XX , it is seen in the command output,that the prefix is advertised to both peers from which it was received from.edge-01(tier0_sr[2])> get bgp 10.XX.XX.0/XXBGP routing table entry for 10.XX.XX.0/XXPrefix advertised to: XX.XX.255.9 XX.XX.255.13 XX.XX.3.2 XX.XX.3.102 Paths available:Aspath: 4XXXXXXXX9 4XXXXXXXX9 4XXXXXXXX9 4XXXXXXXX9 4XXXXXXXX9 4XXXXXXXX1, path-type as-sequenceOrigin incomplete, Metric 0, LocalPref 100, Weight 0, best, validPeer is 1X.X.3.10 with router id 1XX.X4X.X.254
Aspath: 4XXXXXX999 4xxxxxxxx9 4XXXXXX9 4XXXXXX9 42XXXXXX9 4XXXXXX1, path-type as-sequenceOrigin incomplete, Metric 0, LocalPref 100, Weight 0, best, validPeer is 1X.X.3.2 with router id 1XX.X4X.X.254
This behaviour is due to the BGP Split Horizon rule, which prevents a BGP speaker from advertising a route back to the peer from which it was originally learned , when both of them have the same router ID.
Policy-wise, it should be possible to send these updates to both peers , hence the output of the command get bgp 10.XX.XX.20/XX , shows route being advertised to both neighbours.
At the time when the update needs to be sent, there is a split-horizon mechanism that detects that traffic is being sent to the router ID of the origin of the prefix. Hence the route is not advertised.