Advertise maps in BGP

A recent discussion on groupstudy pushed me into labbing BGP again.
In BGP, Advertise maps are used for two functions;
1. Conditional Advertisement
2. Route aggregation.

In conditional advertisement, Advertise maps are with an EXIST-MAP (or NON-EXIST map) to perform conditonal advertisement. Here the advertise-map specifies a route-map that matches the prefixes that would be advertised ONLY if the prefixes in the EXIST-MAP exist in the routing table.

The syntax is "neighbor ip-address advertise-map map-name {exist-map|non-exist} map-name"

The other use of advertise-maps is in specifying what attribute would be carried along in the as-set attributes of an aggregate during summarization.

Assume we have R1, R2,R3 and R4 in AS 1, 2,3 and 4 respectively
R1 -- R4 --- R3
|
R2

R1, R2, and R3 advertise 150.1.x.0/24 into bgp where x is the router number.

R4 aggregates the routes to 150.1..0.0/16 with as-set attribute.
By default, none of the routers get the update anymore since their
individual routes are a part of the summary.

Using advertise map, we want to make R1 and R3 get the summary; so we only advertise the attributes of the prefix form R2 with the summary.

Using as path access-lists and route-maps on R4 we have,

ip as-path access-list 1 permit ^2$
route-map adv permit 10
match as-path 1

router bgp 4
aggregate-address 150.1.0.0 255.255.0.0 as-set summary-only advertise-map adv

Now, R1 and R3 get the summary, R2 doesn't because its AS number is carried along with the summary

R1(config-router)#do sh ip bg | i 150.1.0.0
*> 150.1.0.0 192.168.1.4 0 0 4 2 i

R2(config-router)#do sh ip bg | i 150.1.0.0
R2(config-router)#

Ok. That's it for now. Back to security :-) I was trying to look into NAC with the CTA and CSA. Fun stuff :D

Cheers,
Amplebrain

Configuring BGP through the PIX/ASA.

When configuring BGP through the ASA, a basic understanding of how the ASA works and how BGP is implemented is very important. I would highlight some of my findings about the BGP/ASA relationship in this post.

1. The ASA (when in routed mode) is a HOP: This doesnt matter if we are configuring ibgp since BGP believes that the underlying IGP would take care of reachability to the neighbor but with ebgp, we need to explicitly state that the bgp neighbor is not on the same subnet. The ebgp multihop command is used to achieve this. Lets assume the following topology;

R2(f0/0) --- (ins) ASA (out) --- (f0/0) R3.

on R2 (and similarly on R3), we need to configure:

router bgp 1
neighbor 192.168.13.3 remote-as 2
neighbor 192.168.13.3 ebgp-multihop 2

When configuring ebgp multihop, we should also ensure that there is a route to the neighbor with a length greater than 0 (default route will not work) in the routing table..

Assuming we have on R2,

ip route 0.0.0.0 0.0.0.0 192.168.12.1

When we try to negotiate the BGP connection, it would fail (except R3 configured properly - which would always make R3 active). When we look at the debugs, we would see;

BGP: 192.168.13.3 active open failed - no route to peer, open active delayed 29090ms (35000ms max, 28% jitter)

But when we take a look at the routing table, sure enough, our default route is there...

R2(config-router)#do sh ip rou
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route

Gateway of last resort is 192.168.12.1 to network 0.0.0.0

C 192.168.12.0/24 is directly connected, FastEthernet0/0
S* 0.0.0.0/0 [1/0] via 192.168.12.1

This is because the router actually searches for a route going to 192.168.13.3 and finds none.

R2(config-router)#do sh ip rou 192.168.13.3
% Network not in table

To fix this, we insert a route with a longer match in the routing table (doesnt have to be a host route, anything from a /1 would do)

R2(config-router)#ip route 192.168.0.0 255.255.0.0 192.168.12.1

That should fix things considerably and the BGP neighbor should come up.

2. The ASA does NAT: If the ASA NATs the address of the BGP peer, the neighbor statement should reflect this. Assuming we had a static statement on the ASA,
static (i,o) 192.168.13.2 192.168.12.2

Then on R3, we would peer with 192.168.13.2 instead of 192.168.12.2

neigh 192.168.13.2 remote 1

This would work well if Authentication is NOT configured.

3. Configuring BGP Authentication: BGP Authentication uses special tcp option for MD5 (option 19) to carry the Authentication information. This is stated in rfc 2385. The 16-byte MAC is computed based on a one-way hash function (MD5) generated from TCP header, the IP header, the password and a key. The following must be considered when configuring BGP authentication through the ASA:
a. Since the IP header is used in generating the hash, NAT cannot be used to change the ip address of the peers as this would break the authentication. If nat-control is enabled, the real and translated ip address must be the same.
b. Since the tcp header is used, the sequence number must not be randomized (default behavior of the ASA.) To stop randomization we can append the norandomseq option behind a static address mapping (that does not change the IP address) of the neighbor. This would only work in routed mode (of course)

static (inside,outside) 192.168.12.2 192.168.12.2 no randomseq

We can also disable random sequencing in the global_policy.

c. Finally, option 19 must be allowed to pass through the ASA for BGP traffic. This can be achieved by allowing it in the global_policy. The configuration on the ASA is shown below.

tcp-map BGP
tcp-options range 19 19 allow
!
class-map BGP
match port tcp eq bgp
!
policy-map global_policy
class BGP
set connection random-sequence-number disable
set connection advanced-options BGP
!

That would be all for now.
Further Reading

BGP through ASA configuration exmaple
RFC 2385: Protection of BGP Sessions via the TCP MD5 Signature Option

Amplebrain.