BGP

#########BGP ########
###############Transiting Non-BGP Speaking Devices ###########
Method 1: Redistribute BGP into IGP at the EBGP boundaries
Method 2: Create a GRE tunnel encompassing the NON BGP speaker. ibGP between the TUnnel end points to peer using the GRE Tunnel ip addresses

Method 1: NOTE: All IGP peers (EIGRP/OSPF) will see the redistributed BGP routes, ==> over 2,00,000 Internet routes
Method 2: NOTE: All IGP peers will not see the BGP routes

weight: can be applied on the neighbor stmt or via route-map inbound, affects only local router
local-prefrence: can be applied via route-map inbound, affects all neighbors in the AS
med: can be applied by EBGP neighbor via route-map outbound, affects only directly connected AS. Default metric is 0, so we need to apply metric higher than 1 on other branch to influence selection.
Lower the MED the better.

##########need to clarify: if I would have modified MED within my OWN AS via route-map inbound, would it make sense ??????
##########need to clarify: next-hop-self modification via route-map outbound or directly applying on the neighbor stmt, wht is the diff (if any) ?

no-export : Cannot Advertise to EBGP neighbor
no-advertise : Cannot Advertise to any neighbor


##########need to clarify: IN which scenarios will you use local-as ?
"The local-AS feature allows a router to appear to be a member of a second autonomous system (AS), in addition to its real AS. This feature can only be used for true eBGP peers. You cannot use this feature for two peers that are members of different confederation sub-ASs"

##########ORF################
Why do it ?
Outbound Route Filtering: Under Normal BGP Process, Upstream routers dump all their BGP updates/routes to their downstream peers.
This has two disadv:
1) BW wasted in sending updates on the link
2) Resources on the downstream router, to filter out unwanted routes.

So to avoid this, we can use ORF , where the downstream peer themselves ask for what prefixes they want.

########On upstream Router ( The guy dumping the prefixes) ########
router bgp 2
!
address-family ipv4
neighbor 155.1.146.4 activate
neighbor 155.1.146.4 capability orf prefix-list receive
exit-address-family


########On downstream Router ( The guy wanting partial prefixes) ########
!
router bgp 3
neighbor 155.1.146.1 remote-as 2
!
address-family ipv4
neighbor 155.1.146.1 activate
neighbor 155.1.146.1 capability orf prefix-list send
neighbor 155.1.146.1 prefix-list DENY_VLAN5 in
exit-address-family


################## aggregate-address x.x.x.x y.y.y.y summary-only ##############
without keyword summary-only : supernet and individual subnets sent
with keyword summary-only: only supernet sent

##########need to clarify: IN real lab, I will not have access to BB Routers.
In that case how do I verify , tht BB routers are indeed recieving the summary route only !

I mean in the scenario present in pg104 of Adv Technologies Lab:
I applied summary-only to R1's BGP, but didnt on R3.
So the R3's 10.2.0.0/16 and 10.3.0.0/16 were making it to AS1.
This I Realised only after seeing R4's sh ip bgp. But how do i know this in real lab ?

Ans: be deligent and ensure tht all routers neigboring with BB rtrs AS , i.e all entry points into BB's AS are secured
by issuing sh ip bgp neigh X.X.X.X advertised-routes cmd

they dont care abt sub optimal routing tht summary-only will create unless explicitly specified
################suppress-map ######################
suppress-map filters Out the specific networks that the aggregate advertises.
this has an indirect effect in the sense that remaining specific subnets are NOW advertised along with the summary.

==> when there is no suppress-map, and summary-only keyword is used, only summary is sent
now with suppress-map, the specific prefixes not mentioned in suppress-map are adv along with summary

==> suppress-map is at BGP process level, applies to all neighbors

################unsuppress-map ######################
Even though you have aggregate-add with summary-only option, if you have per neighbor (peer level) a unsuppress-map stmt, it will allow sending more specific prefixes which were normally suppressed by aggregate address

e.g: neighbor 155.1.0.5 unsuppress-map UNSUPPRESS
WHere UNSUPPRESS is the route-map permitting the prefix-list which has more specific subnest suppressed by aggregate-address .. summary-nly option


#################(resolved) need to clarify: aggregate-address as-set summary-only############
R1 & R2 dont get summary of 155.1.0.0/21 why ?
Despite R5 sending the summary route , R1 and R2 are reluctant to add them ..why ?

Rack1R1#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 155.1.1.0/24 0.0.0.0 0 32768 i
Rack1R1#


Rack1R2#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 155.1.2.0/24 0.0.0.0 0 32768 i

Rack1R3#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 155.1.0.0/21 155.1.0.5 0 0 5 {1,2} i
Rack1R3#

Rack1R5#sh ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 155.1.0.0/21 0.0.0.0 100 32768 {1,2} i
s> 155.1.1.0/24 155.1.0.1 0 0 1 i
s> 155.1.2.0/24 155.1.0.2 0 0 2 i
s> 155.1.5.0/24 0.0.0.0 0 32768 i
Rack1R5#

Rack1R5#sh ip bgp neighbors 155.1.0.1 advertised-routes
Network Next Hop Metric LocPrf Weight Path
*> 155.1.0.0/21 0.0.0.0 100 32768 {1,2} i

Rack1R5#sh ip bgp neighbors 155.1.0.2 advertised-routes
Network Next Hop Metric LocPrf Weight Path
*> 155.1.0.0/21 0.0.0.0 100 32768 {1,2} i

Rack1R5#sh ip bgp neighbors 155.1.0.3 advertised-routes
Network Next Hop Metric LocPrf Weight Path
*> 155.1.0.0/21 0.0.0.0 100 32768 {1,2} i

ANS: http://www.cisco.com/warp/public/459/aggregation.html#aggregatingwiththeassetargument

-->(Avoid Loops) With the as-set argument, the path information in the BGP table for the aggregate route changes to include a set from 300 {200,100}. This set indicates that the aggregate actually summarizes routes that have passed through AS-200 and AS-100. The as-set information becomes important in the avoidance of routing loops because the information records where the route has been.
Note: Because the aggregate as-set has AS-1 & AS-2 only, R3 in AS-3 accepts the aggregate route and installs the route in the routing table. The BGP loop detection mechanism causes this route acceptance. The BGP loop detection mechanism does not detect its own AS in as-set.

-->Note: The as-set argument contains information about each individual route that the aggregate summarizes. Changes in the individual route cause an update of the aggregate.

Impact of the Use of suppress-map with Other Configuration Commands

The aggregate-address command includes other configuration commands, such as suppress-map. In order to understand the impact of the use of all the configuration commands in combination, note that aggregate-address only inherits the attributes from the more-specific routes when you use the as-set configuration command. Examples of the attributes that aggregate-address can inherit include no-export and no-advertise.

*

----- When you use the suppress-map configuration command along with the summary-only configuration command, the summary-only configuration command does not have any effect. With use of the suppress-map configuration command, the more-specific routes that the suppress-map suppresses are not advertised. However, the routes that the suppress-map does not cover are advertised in addition to the aggregated route. Therefore, the notes in this section apply to the use of suppress-map either with or without the summary-only configuration command.
*

-----When you use as-set with suppress-map, although the suppressed routes are not advertised, the aggregated route inherits the attributes of all the suppressed routes. But you can override the inherited attributes with the use of other configuration commands, such as attribute-map. The Change the Attributes of the Aggregate Route section describes the use of attribute-map.
*

-----When you use the as-set and suppress-map configuration commands with advertise-map, the aggregate forms. The aggregate inherits the attributes only out of the routes that are selected in the advertise-map, irrespective of whether suppress-map suppresses the route. See the Use advertise-map to Aggregate a Subset of Specific Routes section.
*

-----When you use advertise-map and attribute-map along with as-set and other configuration commands, the attribute-map overrides the attributes that are chosen in the advertise-map.

<<<----->>>In general, when you use advertise-map, only the advertise-map influences the aggregate. In the absence of advertise-map, the aggregate inherits the attributes of the more-specific routes, both suppressed and unsuppressed. In both the cases, you can use the attribute-map configuration command to override the chosen attributes.


######################the Aggregate inherits the community from the specific prefixes ==> use attribute-map ##################
So if there is an specific prefix being received from some ebgp peer, and lets say its community is no-export
then the aggregate will also carry the community no-export, thus having the effect tht no (ebgp/ibgp) peers will get it

thus to alliviate this, we have to use attribute-map and attach a route-map which sets the community to none.

#####################advertise-map, excludes the prefixes from being counted in the aggregate ##################
This means when we use as-set, the prefixes EXCLUDED by the advertise-map, thier parent AS# are not mentioned in the { }
Hence the remote AS which dont have their AS# in {} now accept the summary, even though they now MAY have a specific prefix covered by the aggregate

Read this on CCO http://www.cisco.com/warp/public/459/aggregation.html#aggregatingwiththeassetargument


########## allow-as in #######################
basically disables BGP loop prevention mechanisim
when ebgp peer receives an prefix update with its own AS# in the AS_PATH and if allow-as in is configured for that ebgp peer.
then the prefix is accepted.

This has to be configured on the peer where we want the prefix to be accepted in.