Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Cisco: NSP

Filtering OSPF routes from MPBGP to BGP speaker in the same VRF

 

 

Cisco nsp RSS feed   Index | Next | Previous | View Threaded


jason at lixfeld

Feb 25, 2012, 7:35 PM

Post #1 of 9 (1926 views)
Permalink
Filtering OSPF routes from MPBGP to BGP speaker in the same VRF

Hi folks,

I'm wondering if anyone has some ideas they an share on this.

Assume the following:

- CE1 is speaking *iBGP and OSPF to PE1 inside vrf foo
- PE1 is mutually redistributing CE1's OSPF table with MPBGP
- PE1 exchanges MPBGP routes with PE2.
- PE2 is mutually redistributing CE2's OSPF table with MPBGP
- CE2 is speaking *iBGP and OSPF to PE2 inside vrf foo

So the problem is that the OSPF routes redistributed into MPBGP from via one CE are being announced to the other CE via the PE-CE BGP process. Because those routes are already being received by the CE via the PE-CE OSPF process, they are showing up in the CE's BGP table as RIB failures.

Is there any way to filter those out? I've tried setting and matching tags and communities from within various redistribution points on the PE, but I can't seem to keep them out of the CE's BGP table.

* I'm not sure how common it is to speak iBGP between a CE and a PE, so I figure I'd mention it. It's not a typo, it's a requirement in this particular instance.

Thanks in advance for any clues..
_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


jstuxuhu0816 at gmail

Feb 25, 2012, 10:22 PM

Post #2 of 9 (1845 views)
Permalink
Re: Filtering OSPF routes from MPBGP to BGP speaker in the same VRF [In reply to]

Don't understand why the protocol between CE and PE why need two, iBGP and OSPF? Two vrfs?

Thanks and regards,
Xu Hu

On 26 Feb, 2012, at 11:35, Jason Lixfeld <jason [at] lixfeld> wrote:

> Hi folks,
>
> I'm wondering if anyone has some ideas they an share on this.
>
> Assume the following:
>
> - CE1 is speaking *iBGP and OSPF to PE1 inside vrf foo
> - PE1 is mutually redistributing CE1's OSPF table with MPBGP
> - PE1 exchanges MPBGP routes with PE2.
> - PE2 is mutually redistributing CE2's OSPF table with MPBGP
> - CE2 is speaking *iBGP and OSPF to PE2 inside vrf foo
>
> So the problem is that the OSPF routes redistributed into MPBGP from via one CE are being announced to the other CE via the PE-CE BGP process. Because those routes are already being received by the CE via the PE-CE OSPF process, they are showing up in the CE's BGP table as RIB failures.
>
> Is there any way to filter those out? I've tried setting and matching tags and communities from within various redistribution points on the PE, but I can't seem to keep them out of the CE's BGP table.
>
> * I'm not sure how common it is to speak iBGP between a CE and a PE, so I figure I'd mention it. It's not a typo, it's a requirement in this particular instance.
>
> Thanks in advance for any clues..
> _______________________________________________
> cisco-nsp mailing list cisco-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


tim.wall07 at gmail

Feb 25, 2012, 10:42 PM

Post #3 of 9 (1851 views)
Permalink
Re: Filtering OSPF routes from MPBGP to BGP speaker in the same VRF [In reply to]

Yes I agree there is no need to have two routing protocols running between ce and pe you only need one and usually that routing protocol would be BGP


On 26 Feb 2012, at 06:22, Xu Hu <jstuxuhu0816 [at] gmail> wrote:

> Don't understand why the protocol between CE and PE why need two, iBGP and OSPF? Two vrfs?
>
> Thanks and regards,
> Xu Hu
>
> On 26 Feb, 2012, at 11:35, Jason Lixfeld <jason [at] lixfeld> wrote:
>
>> Hi folks,
>>
>> I'm wondering if anyone has some ideas they an share on this.
>>
>> Assume the following:
>>
>> - CE1 is speaking *iBGP and OSPF to PE1 inside vrf foo
>> - PE1 is mutually redistributing CE1's OSPF table with MPBGP
>> - PE1 exchanges MPBGP routes with PE2.
>> - PE2 is mutually redistributing CE2's OSPF table with MPBGP
>> - CE2 is speaking *iBGP and OSPF to PE2 inside vrf foo
>>
>> So the problem is that the OSPF routes redistributed into MPBGP from via one CE are being announced to the other CE via the PE-CE BGP process. Because those routes are already being received by the CE via the PE-CE OSPF process, they are showing up in the CE's BGP table as RIB failures.
>>
>> Is there any way to filter those out? I've tried setting and matching tags and communities from within various redistribution points on the PE, but I can't seem to keep them out of the CE's BGP table.
>>
>> * I'm not sure how common it is to speak iBGP between a CE and a PE, so I figure I'd mention it. It's not a typo, it's a requirement in this particular instance.
>>
>> Thanks in advance for any clues..
>> _______________________________________________
>> cisco-nsp mailing list cisco-nsp [at] puck
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


jason at lixfeld

Feb 25, 2012, 10:57 PM

Post #4 of 9 (1849 views)
Permalink
Re: Filtering OSPF routes from MPBGP to BGP speaker in the same VRF [In reply to]

Yes, you only need one, except when you need more than one :)

OSPF is used so the CE routers can make use of the PE superbackbone.

iBGP is used to feed the CEs a full BGP table because IP transit customers hang off the same CE router and they expect a full BGP feed from us.

This is all iBGP because it's just a single step in a larger list of steps required to migrate a non-MPLS network into an MPLS network (without having to redesign the entire thing before I can bolt the old onto the new).

The RIB failures aren't causing any issues because the OSPF routes are taking precedence over their BGP duplicate counterparts, but it'd still be nice to tune the PE to not announce them towards the CE, if possible.

On 2012-02-26, at 1:42 AM, Tim.wall07 [at] gmail wrote:

>
> Yes I agree there is no need to have two routing protocols running between ce and pe you only need one and usually that routing protocol would be BGP
>
>
> On 26 Feb 2012, at 06:22, Xu Hu <jstuxuhu0816 [at] gmail> wrote:
>
>> Don't understand why the protocol between CE and PE why need two, iBGP and OSPF? Two vrfs?
>>
>> Thanks and regards,
>> Xu Hu
>>
>> On 26 Feb, 2012, at 11:35, Jason Lixfeld <jason [at] lixfeld> wrote:
>>
>>> Hi folks,
>>>
>>> I'm wondering if anyone has some ideas they an share on this.
>>>
>>> Assume the following:
>>>
>>> - CE1 is speaking *iBGP and OSPF to PE1 inside vrf foo
>>> - PE1 is mutually redistributing CE1's OSPF table with MPBGP
>>> - PE1 exchanges MPBGP routes with PE2.
>>> - PE2 is mutually redistributing CE2's OSPF table with MPBGP
>>> - CE2 is speaking *iBGP and OSPF to PE2 inside vrf foo
>>>
>>> So the problem is that the OSPF routes redistributed into MPBGP from via one CE are being announced to the other CE via the PE-CE BGP process. Because those routes are already being received by the CE via the PE-CE OSPF process, they are showing up in the CE's BGP table as RIB failures.
>>>
>>> Is there any way to filter those out? I've tried setting and matching tags and communities from within various redistribution points on the PE, but I can't seem to keep them out of the CE's BGP table.
>>>
>>> * I'm not sure how common it is to speak iBGP between a CE and a PE, so I figure I'd mention it. It's not a typo, it's a requirement in this particular instance.
>>>
>>> Thanks in advance for any clues..
>>> _______________________________________________
>>> cisco-nsp mailing list cisco-nsp [at] puck
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>> _______________________________________________
>> cisco-nsp mailing list cisco-nsp [at] puck
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/


_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


tim.wall07 at gmail

Feb 26, 2012, 12:22 AM

Post #5 of 9 (1859 views)
Permalink
Re: Filtering OSPF routes from MPBGP to BGP speaker in the same VRF [In reply to]

Filter bgp routes at both ce's. This will mean that only ospf knows the routes and bgp will no longer see the rib failures



On 26 Feb 2012, at 06:57, Jason Lixfeld <jason [at] lixfeld> wrote:

> Yes, you only need one, except when you need more than one :)
>
> OSPF is used so the CE routers can make use of the PE superbackbone.
>
> iBGP is used to feed the CEs a full BGP table because IP transit customers hang off the same CE router and they expect a full BGP feed from us.
>
> This is all iBGP because it's just a single step in a larger list of steps required to migrate a non-MPLS network into an MPLS network (without having to redesign the entire thing before I can bolt the old onto the new).
>
> The RIB failures aren't causing any issues because the OSPF routes are taking precedence over their BGP duplicate counterparts, but it'd still be nice to tune the PE to not announce them towards the CE, if possible.
>
> On 2012-02-26, at 1:42 AM, Tim.wall07 [at] gmail wrote:
>
>>
>> Yes I agree there is no need to have two routing protocols running between ce and pe you only need one and usually that routing protocol would be BGP
>>
>>
>> On 26 Feb 2012, at 06:22, Xu Hu <jstuxuhu0816 [at] gmail> wrote:
>>
>>> Don't understand why the protocol between CE and PE why need two, iBGP and OSPF? Two vrfs?
>>>
>>> Thanks and regards,
>>> Xu Hu
>>>
>>> On 26 Feb, 2012, at 11:35, Jason Lixfeld <jason [at] lixfeld> wrote:
>>>
>>>> Hi folks,
>>>>
>>>> I'm wondering if anyone has some ideas they an share on this.
>>>>
>>>> Assume the following:
>>>>
>>>> - CE1 is speaking *iBGP and OSPF to PE1 inside vrf foo
>>>> - PE1 is mutually redistributing CE1's OSPF table with MPBGP
>>>> - PE1 exchanges MPBGP routes with PE2.
>>>> - PE2 is mutually redistributing CE2's OSPF table with MPBGP
>>>> - CE2 is speaking *iBGP and OSPF to PE2 inside vrf foo
>>>>
>>>> So the problem is that the OSPF routes redistributed into MPBGP from via one CE are being announced to the other CE via the PE-CE BGP process. Because those routes are already being received by the CE via the PE-CE OSPF process, they are showing up in the CE's BGP table as RIB failures.
>>>>
>>>> Is there any way to filter those out? I've tried setting and matching tags and communities from within various redistribution points on the PE, but I can't seem to keep them out of the CE's BGP table.
>>>>
>>>> * I'm not sure how common it is to speak iBGP between a CE and a PE, so I figure I'd mention it. It's not a typo, it's a requirement in this particular instance.
>>>>
>>>> Thanks in advance for any clues..
>>>> _______________________________________________
>>>> cisco-nsp mailing list cisco-nsp [at] puck
>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>
>>> _______________________________________________
>>> cisco-nsp mailing list cisco-nsp [at] puck
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


oboehmer at cisco

Feb 26, 2012, 1:14 AM

Post #6 of 9 (1846 views)
Permalink
Re: Filtering OSPF routes from MPBGP to BGP speaker in thesame VRF [In reply to]

Jason,

> Yes, you only need one, except when you need more than one :)
>
> OSPF is used so the CE routers can make use of the PE superbackbone.
>
> iBGP is used to feed the CEs a full BGP table because IP transit
customers
> hang off the same CE router and they expect a full BGP feed from us.

iBGP as PE-CE routing protocol is not officially supported in IOS (i.e.
between a real L3VPN PE and a CE as described in
draft-marques-l3vpn-ibgp. running it in vrf-lite is supported for most
scenarios, IIRC), and you might already have noticed this as you might
have needed to tweak the next-hop manually? Having said this, I'm not
sure what prevented you from filtering out the prefixes based on some
regular communities you have set when redistributing the OSPF prefixes
to MP-BGP on the ingress PE1? Can you share some config examples?

> The RIB failures aren't causing any issues because the OSPF routes are
> taking precedence over their BGP duplicate counterparts, but it'd
still be
> nice to tune the PE to not announce them towards the CE, if possible.

can you share some configs/show-cmds you tried without success?

oli

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


jason at lixfeld

Feb 26, 2012, 5:41 AM

Post #7 of 9 (1863 views)
Permalink
Re: Filtering OSPF routes from MPBGP to BGP speaker in thesame VRF [In reply to]

On 2012-02-26, at 4:14 AM, Oliver Boehmer (oboehmer) wrote:

> iBGP as PE-CE routing protocol is not officially supported in IOS (i.e.
> between a real L3VPN PE and a CE as described in
> draft-marques-l3vpn-ibgp. running it in vrf-lite is supported for most
> scenarios, IIRC), and you might already have noticed this as you might
> have needed to tweak the next-hop manually?

I had't actually gotten that far in the lab quite yet. I'm still only at the point of having a BGP table on the PEs that included more than just OSPF routes within that VRF and not being able to filter those OSPF routes them from appearing in the CE BGP table.

> Having said this, I'm not
> sure what prevented you from filtering out the prefixes based on some
> regular communities you have set when redistributing the OSPF prefixes
> to MP-BGP on the ingress PE1? Can you share some config examples?

Adding the community to the OSPF routes isn't the problem. Filtering out that community from being announced to a PE-CE iBGP session is where the problems arise.

Here's an OSPF route redistributed into MPBGP with the community 1 filtering hook added:

ASR.2#sh ip bgp vpnv4 vrf Inetv4 11.11.11.1
BGP routing table entry for 21949:4:11.11.11.1/32, version 24
Paths: (2 available, best #2, table Inetv4)
Flag: 0x820
Advertised to update-groups:
1 2
Local
10.0.0.5 (metric 20) from 10.0.0.5 (10.0.0.5)
Origin incomplete, metric 31, localpref 100, valid, internal
Community: 1
Extended Community: RT:21949:4 OSPF DOMAIN ID:0x0005:0x000000640200
OSPF RT:0.0.0.0:5:0 OSPF ROUTER ID:10.0.0.7:0
mpls labels in/out 41/48
Local
9.20.255.4 from 0.0.0.0 (10.0.0.6)
Origin incomplete, metric 31, localpref 100, weight 32768, valid, sourced, best
Community: 1
Extended Community: RT:21949:4 OSPF DOMAIN ID:0x0005:0x000000640200
OSPF RT:0.0.0.0:5:0 OSPF ROUTER ID:10.0.0.8:0
mpls labels in/out 41/nolabel
ASR.2#

The intention is to prevent that route from being advertised to neighbor 9.20.255.4 inside vrf Inetv4:

ASR.2#sh run | s router bgp
router bgp 21949
bgp log-neighbor-changes
neighbor 10.0.0.5 remote-as 21949
neighbor 10.0.0.5 update-source Loopback0
!
address-family ipv4
neighbor 10.0.0.5 activate
neighbor 10.0.0.5 send-community both
neighbor 10.0.0.5 next-hop-self
no auto-summary
no synchronization
exit-address-family
!
address-family vpnv4
neighbor 10.0.0.5 activate
neighbor 10.0.0.5 send-community both
exit-address-family
!
address-family ipv4 vrf Inetv4
redistribute connected
redistribute static
redistribute ospf 100 vrf Inetv4 match internal external 1 external 2 nssa-external 1 nssa-external 2 route-map OSPFtoBGP
neighbor 9.20.255.4 remote-as 21949
neighbor 9.20.255.4 activate
neighbor 9.20.255.4 send-community both
neighbor 9.20.255.4 route-reflector-client
neighbor 9.20.255.4 next-hop-self
neighbor 9.20.255.4 route-map NOOSPF out
no synchronization
network 9.20.255.0 mask 255.255.255.0
network 10.0.0.0 mask 255.255.255.0
exit-address-family
!
ASR.2#sh run | b route-map NOOSPF
route-map NOOSPF deny 10
match community 1
route-map NOOSPF permit 20
ASR.2#

But on 7600.2/9.20.255.4/CE I still see the route tagged with community 1 even though it should be filtered on ASR.2 via route-map NOOSPF:

7600.2#sh ip bgp 11.11.11.1
BGP routing table entry for 11.11.11.1/32, version 253
Paths: (2 available, best #1, table Default-IP-Routing-Table, RIB-failure(17))
Flag: 0xBC0
Advertised to update-groups:
1
Local, (Received from a RR-client)
9.20.255.5 from 9.20.255.5 (10.0.0.6)
Origin incomplete, metric 31, localpref 100, valid, internal, best
Community: 1
Extended Community: RT:21949:4 OSPF DOMAIN ID:0x0005:0x000000640200
OSPF RT:0.0.0.0:5:0 OSPF ROUTER ID:10.0.0.8:0
Local
9.20.255.3 (metric 11) from 10.0.0.3 (10.0.0.3)
Origin incomplete, metric 31, localpref 100, valid, internal
Community: 1
Extended Community: RT:21949:4 OSPF DOMAIN ID:0x0005:0x000000640200
OSPF RT:0.0.0.0:5:0 OSPF ROUTER ID:10.0.0.7:0
Originator: 10.0.0.5, Cluster list: 10.0.0.3
7600.2#


_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


andriy.bilous at gmail

Feb 26, 2012, 11:04 AM

Post #8 of 9 (1866 views)
Permalink
Re: Filtering OSPF routes from MPBGP to BGP speaker in thesame VRF [In reply to]

match community requires _ip-community_number_ not the numerical value
of the community intself.

On Sun, Feb 26, 2012 at 2:41 PM, Jason Lixfeld <jason [at] lixfeld> wrote:
> On 2012-02-26, at 4:14 AM, Oliver Boehmer (oboehmer) wrote:
>
>> iBGP as PE-CE routing protocol is not officially supported in IOS (i.e.
>> between a real L3VPN PE and a CE as described in
>> draft-marques-l3vpn-ibgp. running it in vrf-lite is supported for most
>> scenarios, IIRC), and you might already have noticed this as you might
>> have needed to tweak the next-hop manually?
>
> I had't actually gotten that far in the lab quite yet.  I'm still only at the point of having a BGP table on the PEs that included more than just OSPF routes within that VRF and not being able to filter those OSPF routes them from appearing in the CE BGP table.
>
>> Having said this, I'm not
>> sure what prevented you from filtering out the prefixes based on some
>> regular communities you have set when redistributing the OSPF prefixes
>> to MP-BGP on the ingress PE1? Can you share some config examples?
>
> Adding the community to the OSPF routes isn't the problem.  Filtering out that community from being announced to a PE-CE iBGP session is where the problems arise.
>
> Here's an OSPF route redistributed into MPBGP with the community 1 filtering hook added:
>
> ASR.2#sh ip bgp vpnv4 vrf Inetv4 11.11.11.1
> BGP routing table entry for 21949:4:11.11.11.1/32, version 24
> Paths: (2 available, best #2, table Inetv4)
> Flag: 0x820
>  Advertised to update-groups:
>        1    2
>  Local
>    10.0.0.5 (metric 20) from 10.0.0.5 (10.0.0.5)
>      Origin incomplete, metric 31, localpref 100, valid, internal
>      Community: 1
>      Extended Community: RT:21949:4 OSPF DOMAIN ID:0x0005:0x000000640200
>        OSPF RT:0.0.0.0:5:0 OSPF ROUTER ID:10.0.0.7:0
>      mpls labels in/out 41/48
>  Local
>    9.20.255.4 from 0.0.0.0 (10.0.0.6)
>      Origin incomplete, metric 31, localpref 100, weight 32768, valid, sourced, best
>      Community: 1
>      Extended Community: RT:21949:4 OSPF DOMAIN ID:0x0005:0x000000640200
>        OSPF RT:0.0.0.0:5:0 OSPF ROUTER ID:10.0.0.8:0
>      mpls labels in/out 41/nolabel
> ASR.2#
>
> The intention is to prevent that route from being advertised to neighbor 9.20.255.4 inside vrf Inetv4:
>
> ASR.2#sh run | s router bgp
> router bgp 21949
>  bgp log-neighbor-changes
>  neighbor 10.0.0.5 remote-as 21949
>  neighbor 10.0.0.5 update-source Loopback0
>  !
>  address-family ipv4
>  neighbor 10.0.0.5 activate
>  neighbor 10.0.0.5 send-community both
>  neighbor 10.0.0.5 next-hop-self
>  no auto-summary
>  no synchronization
>  exit-address-family
>  !
>  address-family vpnv4
>  neighbor 10.0.0.5 activate
>  neighbor 10.0.0.5 send-community both
>  exit-address-family
>  !
>  address-family ipv4 vrf Inetv4
>  redistribute connected
>  redistribute static
>  redistribute ospf 100 vrf Inetv4 match internal external 1 external 2 nssa-external 1 nssa-external 2 route-map OSPFtoBGP
>  neighbor 9.20.255.4 remote-as 21949
>  neighbor 9.20.255.4 activate
>  neighbor 9.20.255.4 send-community both
>  neighbor 9.20.255.4 route-reflector-client
>  neighbor 9.20.255.4 next-hop-self
>  neighbor 9.20.255.4 route-map NOOSPF out
>  no synchronization
>  network 9.20.255.0 mask 255.255.255.0
>  network 10.0.0.0 mask 255.255.255.0
>  exit-address-family
> !
> ASR.2#sh run | b route-map NOOSPF
> route-map NOOSPF deny 10
>  match community 1
> route-map NOOSPF permit 20
> ASR.2#
>
> But on 7600.2/9.20.255.4/CE I still see the route tagged with community 1 even though it should be filtered on ASR.2 via route-map NOOSPF:
>
> 7600.2#sh ip bgp 11.11.11.1
> BGP routing table entry for 11.11.11.1/32, version 253
> Paths: (2 available, best #1, table Default-IP-Routing-Table, RIB-failure(17))
> Flag: 0xBC0
>  Advertised to update-groups:
>        1
>  Local, (Received from a RR-client)
>    9.20.255.5 from 9.20.255.5 (10.0.0.6)
>      Origin incomplete, metric 31, localpref 100, valid, internal, best
>      Community: 1
>      Extended Community: RT:21949:4 OSPF DOMAIN ID:0x0005:0x000000640200
>        OSPF RT:0.0.0.0:5:0 OSPF ROUTER ID:10.0.0.8:0
>  Local
>    9.20.255.3 (metric 11) from 10.0.0.3 (10.0.0.3)
>      Origin incomplete, metric 31, localpref 100, valid, internal
>      Community: 1
>      Extended Community: RT:21949:4 OSPF DOMAIN ID:0x0005:0x000000640200
>        OSPF RT:0.0.0.0:5:0 OSPF ROUTER ID:10.0.0.7:0
>      Originator: 10.0.0.5, Cluster list: 10.0.0.3
> 7600.2#
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


jason at lixfeld

Feb 26, 2012, 11:26 AM

Post #9 of 9 (1859 views)
Permalink
Re: Filtering OSPF routes from MPBGP to BGP speaker in thesame VRF [In reply to]

Yup. The failings of working on a problem until your eyes bleed :)

On 2012-02-26, at 2:04 PM, Andriy Bilous wrote:

> match community requires _ip-community_number_ not the numerical value
> of the community intself.
>
> On Sun, Feb 26, 2012 at 2:41 PM, Jason Lixfeld <jason [at] lixfeld> wrote:
>> On 2012-02-26, at 4:14 AM, Oliver Boehmer (oboehmer) wrote:
>>
>>> iBGP as PE-CE routing protocol is not officially supported in IOS (i.e.
>>> between a real L3VPN PE and a CE as described in
>>> draft-marques-l3vpn-ibgp. running it in vrf-lite is supported for most
>>> scenarios, IIRC), and you might already have noticed this as you might
>>> have needed to tweak the next-hop manually?
>>
>> I had't actually gotten that far in the lab quite yet. I'm still only at the point of having a BGP table on the PEs that included more than just OSPF routes within that VRF and not being able to filter those OSPF routes them from appearing in the CE BGP table.
>>
>>> Having said this, I'm not
>>> sure what prevented you from filtering out the prefixes based on some
>>> regular communities you have set when redistributing the OSPF prefixes
>>> to MP-BGP on the ingress PE1? Can you share some config examples?
>>
>> Adding the community to the OSPF routes isn't the problem. Filtering out that community from being announced to a PE-CE iBGP session is where the problems arise.
>>
>> Here's an OSPF route redistributed into MPBGP with the community 1 filtering hook added:
>>
>> ASR.2#sh ip bgp vpnv4 vrf Inetv4 11.11.11.1
>> BGP routing table entry for 21949:4:11.11.11.1/32, version 24
>> Paths: (2 available, best #2, table Inetv4)
>> Flag: 0x820
>> Advertised to update-groups:
>> 1 2
>> Local
>> 10.0.0.5 (metric 20) from 10.0.0.5 (10.0.0.5)
>> Origin incomplete, metric 31, localpref 100, valid, internal
>> Community: 1
>> Extended Community: RT:21949:4 OSPF DOMAIN ID:0x0005:0x000000640200
>> OSPF RT:0.0.0.0:5:0 OSPF ROUTER ID:10.0.0.7:0
>> mpls labels in/out 41/48
>> Local
>> 9.20.255.4 from 0.0.0.0 (10.0.0.6)
>> Origin incomplete, metric 31, localpref 100, weight 32768, valid, sourced, best
>> Community: 1
>> Extended Community: RT:21949:4 OSPF DOMAIN ID:0x0005:0x000000640200
>> OSPF RT:0.0.0.0:5:0 OSPF ROUTER ID:10.0.0.8:0
>> mpls labels in/out 41/nolabel
>> ASR.2#
>>
>> The intention is to prevent that route from being advertised to neighbor 9.20.255.4 inside vrf Inetv4:
>>
>> ASR.2#sh run | s router bgp
>> router bgp 21949
>> bgp log-neighbor-changes
>> neighbor 10.0.0.5 remote-as 21949
>> neighbor 10.0.0.5 update-source Loopback0
>> !
>> address-family ipv4
>> neighbor 10.0.0.5 activate
>> neighbor 10.0.0.5 send-community both
>> neighbor 10.0.0.5 next-hop-self
>> no auto-summary
>> no synchronization
>> exit-address-family
>> !
>> address-family vpnv4
>> neighbor 10.0.0.5 activate
>> neighbor 10.0.0.5 send-community both
>> exit-address-family
>> !
>> address-family ipv4 vrf Inetv4
>> redistribute connected
>> redistribute static
>> redistribute ospf 100 vrf Inetv4 match internal external 1 external 2 nssa-external 1 nssa-external 2 route-map OSPFtoBGP
>> neighbor 9.20.255.4 remote-as 21949
>> neighbor 9.20.255.4 activate
>> neighbor 9.20.255.4 send-community both
>> neighbor 9.20.255.4 route-reflector-client
>> neighbor 9.20.255.4 next-hop-self
>> neighbor 9.20.255.4 route-map NOOSPF out
>> no synchronization
>> network 9.20.255.0 mask 255.255.255.0
>> network 10.0.0.0 mask 255.255.255.0
>> exit-address-family
>> !
>> ASR.2#sh run | b route-map NOOSPF
>> route-map NOOSPF deny 10
>> match community 1
>> route-map NOOSPF permit 20
>> ASR.2#
>>
>> But on 7600.2/9.20.255.4/CE I still see the route tagged with community 1 even though it should be filtered on ASR.2 via route-map NOOSPF:
>>
>> 7600.2#sh ip bgp 11.11.11.1
>> BGP routing table entry for 11.11.11.1/32, version 253
>> Paths: (2 available, best #1, table Default-IP-Routing-Table, RIB-failure(17))
>> Flag: 0xBC0
>> Advertised to update-groups:
>> 1
>> Local, (Received from a RR-client)
>> 9.20.255.5 from 9.20.255.5 (10.0.0.6)
>> Origin incomplete, metric 31, localpref 100, valid, internal, best
>> Community: 1
>> Extended Community: RT:21949:4 OSPF DOMAIN ID:0x0005:0x000000640200
>> OSPF RT:0.0.0.0:5:0 OSPF ROUTER ID:10.0.0.8:0
>> Local
>> 9.20.255.3 (metric 11) from 10.0.0.3 (10.0.0.3)
>> Origin incomplete, metric 31, localpref 100, valid, internal
>> Community: 1
>> Extended Community: RT:21949:4 OSPF DOMAIN ID:0x0005:0x000000640200
>> OSPF RT:0.0.0.0:5:0 OSPF ROUTER ID:10.0.0.7:0
>> Originator: 10.0.0.5, Cluster list: 10.0.0.3
>> 7600.2#
>>
>>
>> _______________________________________________
>> cisco-nsp mailing list cisco-nsp [at] puck
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/


_______________________________________________
cisco-nsp mailing list cisco-nsp [at] puck
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Cisco nsp RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.