Hi, No, 10.108.35.254 is in a different AS, not AS12345.
> On Mar 7, 2019, at 2:44 PM, Michael Still <[email protected]> wrote: > > Is this just a case of BGP loop prevention working as expected? If I > understand correctly you are learning it from AS12345 but also wish to > announce it to a diff neighbor in AS12345? If so then try 'as-override' > option. > > >> On Thu, Mar 7, 2019 at 2:06 PM Jason Lixfeld <[email protected]> wrote: >> Hello, >> >> I’m trying to work through solving why a BGP prefix 126.126.126.0/24 >> announced to pe2 in vrf foo isn’t announced to EBGP neighbour 10.108.35.254 >> on pe1 that is also in vrf foo. >> >> jlixfeld@pe1# run show route protocol bgp table foo.inet.0 126.126.126.0/24 >> >> foo.inet.0: 41 destinations, 51 routes (35 active, 0 holddown, 9 hidden) >> + = Active Route, - = Last Active, * = Both >> >> 126.126.126.0/24 *[BGP/170] 03:18:28, MED 0, localpref 990, from >> 10.15.48.253 >> AS path: 12345 I, validation-state: unverified >> > to 10.15.51.248 via xe-0/1/5.0, Push 91 >> to 10.15.49.83 via xe-0/1/0.0, Push 91, Push 18(top) >> [BGP/170] 03:18:28, MED 0, localpref 990, from >> 10.15.48.254 >> AS path: 12345 I, validation-state: unverified >> > to 10.15.51.248 via xe-0/1/5.0, Push 91 >> to 10.15.49.83 via xe-0/1/0.0, Push 91, Push 18(top) >> >> [edit] >> jlixfeld@pe1# >> >> 126.126.126.0/24 is received from as12345 on pe2. pe2 announces the prefix >> to RRs 10.15.48.253 and 10.15.48.254, and the RRs announce the prefix to >> pe1. From here, I’m trying to announce it to EBGP neighbour 10.108.35.254, >> which I can’t seem to make work: >> >> jlixfeld@pe1# run show route advertising-protocol bgp 10.108.35.254 >> >> foo.inet.0: 41 destinations, 51 routes (35 active, 0 holddown, 9 hidden) >> Prefix Nexthop MED Lclpref AS path >> * 10.137.128.0/21 Self I >> * 10.137.136.0/21 Self I >> * 10.137.144.0/21 Self I >> * 10.137.152.0/21 Self I >> * 10.207.192.0/19 Self I >> * 10.15.48.0/22 Self I >> * 10.15.52.0/22 Self I >> * 10.15.56.0/22 Self I >> * 10.15.60.0/22 Self I >> * 10.98.192.0/20 Self I >> * 10.9.192.0/19 Self I >> * 10.45.192.0/20 Self I >> * 10.192.44.0/22 Self I >> * 10.59.160.0/20 Self I >> * 10.249.160.0/22 Self I >> * 10.68.120.0/21 Self I >> * 10.167.152.0/21 Self I >> * 10.175.212.0/22 Self I >> * 10.223.160.0/19 Self I >> * 10.253.136.0/21 Self I >> >> [edit] >> jlixfeld@pe1# >> >> (FWIW, the prefixes that are being announced are anchored on pe1 as static >> routes) >> >> My understanding is that since this is a BGP prefix, it’s default export >> policy is to advertise all active BGP routes to all BGP speakers. But, to >> try and work through whether it was an export policy issue anyway, I >> deactivated the export policy on the session to 10.108.35.254, which was >> ineffective. >> >> Maybe there are additional default behaviours that are different than what >> I’m more familiar with in IOS/XR? >> >> Maybe it is actually a policy issue, and I’m just not aware of what’s >> necessary for the prefix get announced. I was hoping that there was an >> equivalent to show route receive-protocol bgp <neighbor> hidden table <..> >> detail that would show why a prefix may not be getting announced to an EBGP >> neighbor. IE: this command would show the reasons why a received route is >> hidden, ie: "Hidden reason: rejected by import policy”. >> >> Would someone be able to point me in the direction of where I might need to >> look to clear up what I’m missing? >> >> Thanks! >> >> >> _______________________________________________ >> juniper-nsp mailing list [email protected] >> https://puck.nether.net/mailman/listinfo/juniper-nsp > > > -- > [[email protected] ~]$ cat .signature > cat: .signature: No such file or directory > [[email protected] ~]$ _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
