To share what I've learned !

Following Log messages are normal in the IX scenario but decode the error message is quite interesting: We will see why this error message popped up : : %BGP-3-NOTIFICATION: sent to neighbor 10.10.194.236 2/7 (unsupported/disjoint capability) 0 bytes  FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0039 0104 xx0D 00B4 C06A 1102 1C02 0601 0400 0200 0102 0280 0002 0202 0002 0246 0002 0641 0400 00C4 0D its a raw hex out  of the BGP open message and starts from the marker  16byte FF so the actual output starts from 0039  2 byte length value : 00 39 - 57 1 byte Type : 01 open message 1 byte Version : 04 2 byte ASN : xx0D  [ modified to remove the relevant information ] 2 byte holdtime : 00 B4 - 180 Seconds 4 byte BGP identifier : C06A 1102 [ modified ] 1 byte Optional parameter length : 1C   - 28 bytes Refer RFC: http://tools.ietf.org/html/rfc5492 http://tools.ietf.org/html/draft-ietf-idr-ext-opt-param-02 http://www.iana.org/assignm...

I was confused by the wording of Cisco regarding the route-map continue statement Route maps have a linear behavior, not a nested behavior. Once a route is matched in a route map permit entry with a continue command clause, it will not be processed by the implicit deny at the end of the route-map. Therefore I've designed the following lab to check the actual behaviour  R1 configuration: R1#show run Building configuration... ! hostname R1 ! interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface Loopback1 ip address 20.20.20.1 255.255.255.0 ! interface FastEthernet1/0 ip address 10.10.10.1 255.255.255.252 duplex auto speed auto ! router bgp 65001 no synchronization bgp router-id 1.1.1.1 bgp log-neighbor-changes network 20.20.20.0 mask 255.255.255.0 neighbor 10.10.10.2 remote-as 65002 neighbor 10.10.10.2 send-community both neighbor 10.10.10.2 route-map TEST out no auto-summary ! ip bgp-community new-format ! route-map TEST permit 10 set community ...

this lab is directly taken from BGP Design & Implementation Chap 4. GNS3 configurations attached below. Summary - In the boarder router if the summary route injected as follows aggregate-address 172.16.0.0 255.255.0.0 as-set summary-only downwards the originality of the prefix may be lost therefore to specify the best exist path we can regenerate the path we use inject path . bgp inject-map Map1 exist-map Map2 Map1 injects the path Map2 checks whether path is available , it at least two match statements one is route-source & aggregate prefix. Whether u can inject weird prefix other than aggregate .. (eg aggregate is 172.16.0.0/16 but if you try to inject 10.0.0.0/24 ???) As usual you can't :) following is the attached diagram R5 Relevant configuration. router bgp 100 no synchronization bgp log-neighbor-changes bgp inject-map AS200-Specific exist-map AS200-aggregate neighbor 192.168.12.2 remote-as 100 neighbor 192.168.12.2 send-community neighbor 192.168.23....

Introduction: This we can use to advertise the prefixes automatically when one peer goes down rather manually advertise the prefixes. Design Notes: In this example I’m trying to advertise 10.0.0.0/16 through AS 65001 but if the peer (203.143.0.5) goes down automatically advertise the 10.0.0.0/16 through AS 65002(203.143.0.1). To make the configuration works we need to match against a prefix that advertise from that(203.143.0.5) peer. But to make sure that learned through that peer we can use AS-Path match or community based match. Here in this example I’m matching against 172.16.0.0/24 advertise through 65001 and match against the as path ^ 65001. Configuration Notes: This is the only configuration different from normal one: neighbor 203.143.0.1 advertise-map otherblock non-exist-map[exist-map] inblock Better notes on this: Normal Status: R2#show ip bgp neighbors 203.143.0.1 | inc Cond Condition-map inblock, Advertise-map otherblock, status: Withdraw R0#show ip route Gateway of last...