Mailing List Archive: PE-CE BGP announcements

PE-CE BGP announcements

Mar 7, 2019, 11:04 AM

Post #1 of 5 (860 views)

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 juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: PE-CE BGP announcements [ In reply to ]

stillwaxin at gmail

Mar 7, 2019, 11:44 AM

Post #2 of 5 (860 views)

Permalink

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 <jason-jnsp@lixfeld.ca> 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 juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>

--
[stillwaxin@gmail.com ~]$ cat .signature
cat: .signature: No such file or directory
[stillwaxin@gmail.com ~]$
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: PE-CE BGP announcements [ In reply to ]

jason-jnsp at lixfeld

Mar 7, 2019, 11:49 AM

Post #3 of 5 (860 views)

Permalink

Hi,

No, 10.108.35.254 is in a different AS, not AS12345.

> On Mar 7, 2019, at 2:44 PM, Michael Still <stillwaxin@gmail.com> 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 <jason-jnsp@lixfeld.ca> 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 juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
> --
> [stillwaxin@gmail.com ~]$ cat .signature
> cat: .signature: No such file or directory
> [stillwaxin@gmail.com ~]$
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: PE-CE BGP announcements [ In reply to ]

olivier.benghozi at wifirst

Mar 7, 2019, 12:46 PM

Post #4 of 5 (859 views)

Permalink

Really sure of your export policy when removed from the neighbour (that is, any policy under the protocol or the group) ?

show bgp neighbor exact-instance foo 10.108.35.254 | match export

Any NO-EXPORT community attached on the route?

> Le 7 mars 2019 à 20:04, Jason Lixfeld <jason-jnsp@lixfeld.ca> a écrit :
>
> 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.

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: PE-CE BGP announcements [ In reply to ]

jason-jnsp at lixfeld

Mar 7, 2019, 1:12 PM

Post #5 of 5 (859 views)

Permalink

Thanks! There was in fact a catch-all reject policy higher up in the config hierarchy that I didn’t clue into.

So now I see it with all policies removed, so I should be able to work backwards from here.

Thanks again for the clue!

> On Mar 7, 2019, at 3:46 PM, Olivier Benghozi <olivier.benghozi@wifirst.fr> wrote:
>
> Really sure of your export policy when removed from the neighbour (that is, any policy under the protocol or the group) ?
>
> show bgp neighbor exact-instance foo 10.108.35.254 | match export
>
>
> Any NO-EXPORT community attached on the route?
>
>> Le 7 mars 2019 à 20:04, Jason Lixfeld <jason-jnsp@lixfeld.ca> a écrit :
>>
>> 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.
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp