DENIED due to: extended community not supported;

subhashe · ‎07-19-2006

Hi,

I have configured MBGP between a 7606 running 12.2(18)SXF4 and a Cisco 7206VXR running Version 12.2(4)T1 when updates are received on 7206 from 7606 I get the following error message

.Jul 19 16:53:53: BGP(2): xx.xx.xx.xx rcvd UPDATE w/ attr: nexthop xx.xx.xx.xx, origin ?, localpref 100, metric 0, extended community RT:65000:1213

.Jul 19 16:53:53: BGP(2): xx.xx.xx.xx rcvd 65000:1213:10.100.100.0/24 -- DENIED due to: extended community not supported;

The BGP updates does not come up on 7206. But updates from 7206 come up on 7606 wthout any issue.

I would like to know the reason for this and whether anyone has come across this error message. The configurations are as follows

ip vrf Test

rd 65000:1213

route-target export 65000:1213

route-target import 65000:1213

interface vlan1213

ip vrf forwarding Test

ip address 10.100.100.1 255.255.255.0

router bgp 65001

bgp router-id xx.xx.xx.xx

no bgp default ipv4-unicast

no bgp default route-target filter

bgp cluster-id 1000

bgp log-neighbor-changes

bgp confederation identifier 65000

bgp confederation peers 65002 65003 65004

bgp graceful-restart restart-time 120

bgp graceful-restart stalepath-time 360

bgp graceful-restart

neighbor yy.yy.yy.yy remote-as 65001

neighbor yy.yy.yy.yy description Cisco 7206

neighbor yy.yy.yy.yy password 7 AAAAAAAAAAAAAAAAAAAAAAAA

neighbor yy.yy.yy.yy update-source Loopback0

address-family vpnv4

neighbor yy.yy.yy.yy activate

neighbor yy.yy.yy.yy send-community both

!

address-family ipv4 vrf Test

redistribute connected

redistribute static

no auto-summary

no synchronization

exit-address-family

7206

=====

router bgp 65001

no synchronization

bgp router-id yy.yy.yy.yy

no bgp default ipv4-unicast

bgp log-neighbor-changes

bgp confederation identifier 65000

bgp confederation peers 65002 65003 65004

neighbor xx.xx.xx.xx remote-as 65001

neighbor xx.xx.xx.xx description Cisco 7606

neighbor xx.xx.xx.xx password 7 BBBBBBBBBBBBBBBBBBBBBBBBBB

neighbor xx.xx.xx.xx update-source Loopback0

no auto-summary

address-family vpnv4

neighbor xx.xx.xx.xx activate

neighbor xx.xx.xx.xx send-community both

exit-address-family

!

Harold Ritter · ‎07-19-2006

The reason the 7206 rejects the update is because no VRF imports RT 65000:1213 on this box. If you wanted these updates to be kept in spite of that fact, which is sometimes useful when the local router is being used as an ASBR, you need to configure "no bgp default route-target filter" under the BGP process.

Hope this helps,

subhashe · ‎07-20-2006

Hi,

Thanks for the quick reply. the no bgp default route-target filter command did the trick.

Thank you very much

But my question is that the 7206 is a production router which has been peering with another two 7206s (Route Reflectors) and has been receiving VRFs without any issue.The problem is with the new 7606 only.

Please see the attached outputs and number of prefixes received before and after the change

================================================

before no bgp default route-target filter

sh ip bgp vpnv4 all summary

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

7606 4 65001 1626 2064 363 0 0 00:04:06 0

old 7206-1 4 65001 22116 21957 363 0 0 2w1d 71

old 7206-1 4 65001 22122 21924 363 0 0 2w1d 71

=====================================================

after no bgp default route-target filter

sh ip bgp vpnv4 all summary

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

7606 4 65001 1626 2064 363 0 0 00:02:21 1

old 7206-1 4 65001 22116 21957 363 0 0 2w1d 71

old 7206-1 4 65001 22122 21924 363 0 0 2w1d 71

====================================================

Thanks and Best Rgds

Subhash Edirisinghe

Harold Ritter · ‎07-20-2006

The RT filtering doesn't take place on RRs as they need to reflect VPNv4 prefixes between clients. The "no bgp default route-target filter" is only required if the box is not a RR and it does have to keep the prefixes even though it doesn't have any VRF importing them.

Hope this helps,

subhashe · ‎07-22-2006

Hi,

Thanks for the valuable information and your help in sloving this issue

Best Rgds

Subhash Edirisinghe

David Salazar · ‎03-16-2013

Regards, Subhash Edirisinghe

The VPNv4 route is sent to the peer and internal, as you did in redistributing the PE Router with MBGP (address-family ipv4 vrf TEST).

Look at this example:

BGP routing table entry for 2:2:171.1.1.1 / 32, version 5

Paths: (1 available, best # 1, table SITE-B)

Advertised to update-groups:

1

local

1.1.10.2 from 0.0.0.0 (10.3.3.3)

Origin incomplete, metric 2297856, localpref 100, weight 32768, valid, sourced, best

Extended Community: RT: 2:2

Cost: Pre-bestpath: 128:2297856 (default-2145185791) 0x8800: 32768:0

0x8801: 101:640000 0x8802: 0x8803 65281:1657856: 65281:1500

mpls labels in / out 28/nolabel

R3-PE #

from 0.0.0.0 indicates that the router which issued the command "show bgp vpnv4 unicast all 171.1.1.1" this locally inserting the path to the BGP table, as this router establishes iBGP peering with another P router when the router receives P rejects the update by BGP's own rules (rejects routes with ASPATH empty).

If Router P (7206 in your case) you set it as a RR, the rule is overlooked and not refused VPNv4 route.

I imagine you already solved the problem, but please comment if given earlier by me was the same thing that allowed you to solve.