Fun With Route-Maps And BGP

I’ve always been a little bit hazy on the circumstances under which a BGP neighbour needs to be cleared. This extremely informative page from Cisco casts a bit of light on the situation. Especially, the section on when to clear a BGP neighbourship.

The official line is any in/outbound policy update will require the BGP session to be cleared to take effect. Obviously, this depends on the direction the policy is applied when you clear the neighbourship in/outbound.

So my question is whether a new route-map constitutes a policy update. Now this may sound like a stupid question (remember the title of the blog please dear reader). But someone legitimately asked me if applying a new policy constituted an update. So let’s find out.

This is my topology:

Test Topology
Test Topology

This is what I’m doing:
– Loopback0 (10.1.1.1/32) is advertised into OSPF on R1 along with the 1.1.1.0/30 network.
– The 1.1.1.0/30 network is advertised into OSPF on R2.
– BGP is used to advertise the 3.3.3.0/24 network using a peer-group TEST.
– R1 and R2 have an iBGP peering in AS 65000 using the physical addresses of the /30.
– R1 and R2 use a loopback address for their peering.

BGP configuration on R1 and R2 looks like this:


R1#show run | section router bgp
router bgp 65000
bgp router-id 1.1.1.1
bgp log-neighbor-changes
neighbor TEST peer-group
neighbor TEST remote-as 65000
neighbor 1.1.1.2 peer-group TEST
!
address-family ipv4
neighbor TEST soft-reconfiguration inbound
neighbor TEST route-map TEST out
neighbor 1.1.1.2 activate
no auto-summary
no synchronization
network 2.2.2.2 mask 255.255.255.255
network 3.3.3.0 mask 255.255.255.0
exit-address-family

R1#show run | section access-lis
access-list 1 permit 2.2.2.2
access-list 1 permit 10.1.1.1
access-list 1 permit 3.3.3.0 0.0.0.255
R1#show run | section route-map
neighbor TEST route-map TEST out
route-map TEST permit 5
match ip address 1
set ip next-hop 10.1.1.1

R2#show run | section router bgp
router bgp 65000
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 65000
neighbor 1.1.1.1 soft-reconfiguration inbound
no auto-summary

Pretty vanilla as you can see.

You can see the routes being learnt on R2 via BGP:

R2#sh ip bgp
BGP table version is 17, local router ID is 10.1.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
r>i2.2.2.2/32 10.1.1.1 0 100 0 i
*>i3.3.3.0/24 10.1.1.1 0 100 0 i

This shows the next hop for the 3.3.3.0/24 network having its next hop set to 10.1.1.1 by the route map on R1.

I now remove the route map on R1, so it’s no longer applied to the peer-group and clear the session to see what BGP comes up with:


R2#sh ip bgp
BGP table version is 19, local router ID is 10.1.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
r>i2.2.2.2/32 1.1.1.1 0 100 0 i
*>i3.3.3.0/24 1.1.1.1 0 100 0 i

You can see BGP naturally wants to set the next hop using the 1.1.1.1 address as the next hop on R1.

I then reapplied the route-map on R1 so the next-hop is set to 10.1.1.1 and checked the route:

I observed no next hop change.

I then cleared the BGP neighbourship outbound using “clear ip bgp 1.1.1.2 soft out” to see what would happen:

R2#sh ip bgp
BGP table version is 21, local router ID is 10.1.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
r>i2.2.2.2/32 10.1.1.1 0 100 0 i
*>i3.3.3.0/24 10.1.1.1 0 100 0 i

As you can see, the next hop set by R1 has taken effect. Pretty basic stuff, but it’s something you find yourself questioning in the absence of explicit information. I blame the way a lot of the technical specs need to be interpreted very carefully.

This has also cleared up the confusion regarding which direction the neighbourship needs to be cleared in depending on the direction the policy is applied. Here, we advertise a route out to a neighbour, but we influence the next hop inbound to us (we’re R1 by the way). Clearing the neighbourship outbound from R1 effects the change we’re trying to achieve.

ASA Prompt Customisation

I occasionally run into Cisco ASAs that don’t identify their status (active/standby). This is rectified by configuring the “prompt “. These are:


asa-1-pri(config)# prompt ?

configure mode commands/options:
context Display the context in the session prompt (multimode only)
domain Display the domain in the session prompt
hostname Display the hostname in the session prompt
priority Display the priority in the session prompt
state Display the traffic passing state in the session prompt

“state” will tell you if the device is active or standby.

You can check what’s currently on the ASA with:

asa-1-pri# show run prompt
prompt hostname context

SCP File To ASA

Need to do this a few times for some work. It looks like the ASA is a bit picky about how you specify the destination location when you try and do it from a UNIX box.

Enable SSH copy on the ASA

ssh scopy enable

Copy the ASA image from the local directory on your UNIX box to the device.

scp -v asa825-51-k8.bin username@IP_ADDRESS:disk0:asa825-51-k8.bin

If you don’t use this format the UNIX box will give you an error message along the lines of “lost connection”, though the transfer will seem to have completed.