From: easyman (easyman@primetek.com.tw)
Date: Wed Jan 04 2006 - 03:24:47 GMT-3
Yes, I have the same doubt.
It become a habit to use "neighbor send-community" if I configured any of
the communities(well-known or not).
But in definition, COMMUNITY is an "Optional transitive" attribute.
From Doylye's books,
If an optional attribute is transitive, a BGP process should accept the path
in which it is included, even if it doesn't support the attribute, and it
should pass the path on to its peers.
Can we extended the definition to "a BGP process should accept the attribute
in which
^^^^^^^^
it is included, even if it doesn't support the attribute, and it should pass
the attribute
^^^^^^^
with the path on to its peers".
Comments are appreciated
Regards
Lin
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Schulz, Dave
Sent: Wednesday, January 04, 2006 1:39 AM
To: Cisco certification
Subject: Local-as and no-export community issue
Here is an interesting problem that I ran into in the lab....and, can't
seem to find the solution. I have 3 AS's in BGP and want to use the
local AS option with communities....
I have R4 as AS400....sending to R1 (AS155/local-as100)....connected to
R3 in the same AS.....
R4(AS400)---------------------------R1(AS 155 (local-as100)
------------------R3 (AS155(localAS155)
All adjacencies form and everything is operating correctly, except....
The networks that I am sending from R4 to R1 get sent with the community
of "no-export".....the routes come through, but the R3 router does not
maintain the "no export" attributes. I know that this works without the
local-as options, but can't understand why this would make any
difference in this scenario. Also, I can fix the issue by configuring
the neighbor statement with the send-community option on R1, pointing to
R3 (everything is working)....of course, this allows the community
option to be passed....however, I wouldn't think that I would have to do
that, since the community option should be controlled from R4, otherwise
a remote provider/customer can override your intentions to not allow
them to become a transit AS. Thoughts?
Here are the configs for R4 and R1.....
R4.......
interface Loopback10
ip address 41.4.4.4 255.255.255.0 secondary
ip address 42.4.4.4 255.255.255.0 secondary
ip address 43.4.4.4 255.255.255.0 secondary
ip address 44.4.4.4 255.255.255.0 secondary
ip address 45.4.4.4 255.255.255.0 secondary
ip address 40.4.4.4 255.255.255.0
!
interface Loopback104
ip address 172.16.104.1 255.255.255.0
!
interface Serial0
ip address 172.16.14.4 255.255.255.0
!
router bgp 400
no synchronization
bgp log-neighbor-changes
network 40.4.4.0 mask 255.255.255.0
network 41.4.4.0 mask 255.255.255.0
network 42.4.4.0 mask 255.255.255.0
network 43.4.4.0 mask 255.255.255.0
network 44.4.4.0 mask 255.255.255.0
network 45.4.4.0 mask 255.255.255.0
neighbor 172.16.14.1 remote-as 100
neighbor 172.16.14.1 send-community
neighbor 172.16.14.1 route-map COMM out
no auto-summary
!
!
access-list 1 permit 40.4.4.0 0.0.0.255
access-list 1 permit 41.4.4.0 0.0.0.255
!
route-map COMM permit 10
match ip address 1
set community no-export
!
R1.....
interface Serial0.14 point-to-point
ip address 172.16.14.1 255.255.255.0
!
interface Serial0.123 multipoint
ip address 172.16.123.1 255.255.255.0
!
router bgp 155
no synchronization
bgp log-neighbor-changes
neighbor 172.16.14.4 remote-as 400
neighbor 172.16.14.4 local-as 100
neighbor 172.16.123.3 remote-as 155
no auto-summary
!
access-list 1 permit 225.5.5.5
!
route-map COMM permit 10
set community no-export
!
Routes..........
R3#sh ip bgp 40.4.4.0
BGP routing table entry for 40.4.4.0/24, version 6
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.1.1.6
100 400
172.16.14.4 (metric 128) from 172.16.123.1 (172.16.101.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
R1#sh ip bgp 40.4.4.0
BGP routing table entry for 40.4.4.0/24, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table, not
advertised to EBGP peer)
Advertised to non peer-group peers:
172.16.123.3
100 400
172.16.14.4 from 172.16.14.4 (172.16.104.1)
Origin IGP, metric 0, localpref 100, valid, external, best
Community: no-export
Dave Schulz,
Email: dschulz@dpsciences.com <mailto:dschulz@dpsciences.com >
This archive was generated by hypermail 2.1.4 : Wed Feb 01 2006 - 07:45:47 GMT-3