Archives for posts with tag: BGP

I was asked question about MPLS labels within a VRF. Well the question was ” when I type the command ‘show mpls ldp bindings vrf xxx‘ ” I don’t see any labels for my remote site prefixes.

In this case these labels aren’t assigned by LDP they are assigned by BGP.

The command he was looking for was “show ip bgp vpnv4 vrf xxx labels” I think a light went on in his head when i explained this to him!

If your still confused , imagine the LSP (unidirectional) R1 -> R4 is basically a virtual connection if you like , where R4 is the egress LSR for the packet. The packet will travel via R1 -> R2 -> R3 -> R4. The next hop actually is listed as R4 even though it has to pass through R2 and R3. Which by the way has it own labels to add on top of bottom of stack label for R4.


R1 pushes on the label 1234 for R4 and another label on top for R2 which is 22, next R2 removes its own label (22) and adds the label for R3 which is 33, R3 removes its own label (33) and forwards the packet with the label 1234 to R4. Bottom of stack bit is set to 1, R4 removes the label and forwards.



Neighbours with the lowest BGP router identifier will establish the connection to the remote peer via TCP port 179, the source port will be random. We can modify this behaviour with a few simple commands.

For example we want R1 to be a passive peer. That means that R2 and R3 will actively look to establish the session.



So from R1 if we leave everything as default then we can work out that R1 it the lowest router identifier, courtesy of a loop-back interface which is So it will look to actively establish the connection with any configured peers.

R1#sh ip bgp summary
BGP router identifier, local AS number 500

We can verify this with the following command.

R1#sh ip bgp neighbors | i host
Local host:, Local port: 57717
Foreign host:, Foreign port: 179
Local host:, Local port: 63542
Foreign host:, Foreign port: 179

Lets modify this behaviour, use the commands.

router bgp 500
 neighbor transport connection-mode passive
 neighbor transport connection-mode passive

Then clear the BGP session with clear ip bgp *

Now use the same command as before.

R1#sh ip bgp neighbors | i host
Local host:, Local port: 179
Foreign host:, Foreign port: 34121
Local host:, Local port: 179
Foreign host:, Foreign port: 32711

This shows us that foreign host has established the bgp connection sourcing from random port to port 179 on our local router.

RFC4271 which is the holy grail for BGP-4 states that.

When a BGP speaker is configured as active,
it may end up on either the active or passive side of the connection
that eventually gets established.  Once the TCP connection is
completed, it doesn’t matter which end was active and which was passive.
The only difference is in which side of the TCP connection has port number 179.

There exists a period in which the identity of the peer on the other
end of an incoming connection is known, but the BGP identifier is not
known.  During this time, both an incoming and outgoing connection
may exist for the same configured peering.  This is referred to as a
connection collision.



4-Byte Autonomous System Number provides us with 4.3billion unique ASN’s , going far beyond the original 2-Byte range of 65536.

So what happens when you have a router that doesn’t yet support 4-Byte ASN? I’ll show you what to do.

You wouldn’t necessarily be configuring all 3 routers in the real world.

First see the simple topology below

4-Byte ASN

4-Byte ASN

R3 in the middle is still using a 2-Byte ASN and the IOS doesn’t support 4-Byte ASN. So for this exact purpose IANA assigned a placeholder, AS23456 which is used by the older routers to communicate with new 4-Byte AS numbers.

This is achieved by using a transitive BGP attribute  NEW_AS_PATH and NEW_AGGREGATOR, much like the ATOMIC_AGGREGATOR used when summarising similar routes. This stores like a small note of the actual 4-Byte ASN which is then used by the 4-Byte capable router. Something you might want to note is the AS_PATH length is also maintained, I will demonstrate this.

This particular method is known as AS-PLAIN

So on R2 and R3 setup BGP, the only difference is on R3 instead of using the actual AS number use the placeholder AS23456.

R2#sh run | sec router bgp
router bgp 132678
 bgp log-neighbor-changes
 network mask
 neighbor remote-as 500
no auto-summary
R3#sh run | sec router bgp
router bgp 500
 no synchronization
 bgp log-neighbor-changes
 neighbor remote-as 23456
 neighbor remote-as 23456
 no auto-summary

Now on R1 I’ve used AS_PATH Prepend to demonstrate the fact that the AS_PATH length doesn’t change, On my route map I prepended the AS path 4 times

R1#sh run | sec router bgp
router bgp 131456
 bgp log-neighbor-changes
 neighbor remote-as 500
 neighbor route-map prepend-AS out
no auto-summary

Now lets confirm the configurations above, using the commands SH IP BGP” from R3. We will expect to see the placeholder ASN23456

   Network          Next Hop            Metric LocPrf Weight Path
*>              0             0 23456 i
*>              0             0 23456 23456 23456 23456 23456 i

Now  let’s do the same from R2 , we should now expect to see the 4-Byte ASN in the AS_PATH.

     Network          Next Hop            Metric LocPrf Weight Path
 *>                  0         32768 i
 *>                            0 500 131456 131456 131456 131456 131456 i

To see exactly what is sent between the router’s I’ve used Wireshark to capture the packets, you can see the message sent from R3, AS_PATH and NEW_AS_PATH

Wireshark Capture

Wireshark Capture


If you need to work out the ASDOT version of an ASPLAIN 4-Byte ASN use the examples below.

4-Byte ASN-194534
1. 194534 / 65535 = 2 (integer)
2. 194534 – ( 65535 * 2) = 63464
3. 63464 – 2 (integer) = 63462
4  ASDOT = 2.63462

Here is a different example this time with an even longer ASN

4-Byte ASN-2394951
1. 2394951 / 65535 = 36 (integer)
2. 2394951 -(65535*36) = 2394951-2359260 = 35691
3. 35691-36 (integer) = 35655
4. ASDOT =36.35655


This lab is setup for Multicast Source Discovery Protocol (MSDP) I will also be applying Source Active (SA) filtering on our Rendezvous Points (RP). On this occasion I will use Auto-RP to discover RP on each domain then use MSDP to enable us to share SA messages about our multicast sources. The SA filtering will be applied to R2 and R3. When using MSDP setup a multicast boundary, imagine a line between domains where you create an access-list which permits or allows any multicast address which you specify.

The reason I am using Auto-RP is to show the significance of using the multicast boundary, we will block the Auto-RP multicast address of and this will guarantee the boundaries between our domains, but not limited to only that purpose.

The main commands you will need are “ip msdp peer [ip address] connect-source [interface]” for SA filtering use the command “ip msdp sa-filter in | out [peer ip] list [access-list]” for the multicast boundary under interface use the command “ip multicast boundary [access-list] in | out filter-autorp” My previous blog “Multicast Notes” will provide a little more detail, and also some examples of access-lists.

MSDP Topology

MSDP Topology


Attached are the config’s for each router (Router Configs). As I’m using GNS3 I had to enter commands “no ip route-cache” and “no ip mroute-cache” on each PIM interface. Also add “no ip cef”. You won’t need this for physical routers.

Verify our msdp peers with the command “show ip msdp summary” from R3 shows we have 2 MSDP peers, both show as UP. All is looking good at this point.

R3#sh ip msdp summary
MSDP Peer Status Summary
Peer Address     AS   State   Uptime/  Reset    SA   Peer Name
Downtime Count  Count     2     Up         00:09:29      0          0            ?     6     Up         00:10:19      0          0            ?

We can also use the command “show ip msdp peer” from R3 to show us is if any SA filtering is being applied and also how many SA messages received from the peer. In our example we have received 1 SA message from our peer highlighted in red, and we are filtering inbound SA messages, also highlighted in red.

MSDP Peer (?), AS 2
Connection status:
State: Up, Resets: 0, Connection source: Loopback1 (
Uptime(Downtime): 00:17:41, Messages sent/received: 18/19
Output messages discarded: 0
Connection and counters cleared 00:19:31 ago
SA Filtering:
Input (S,G) filter: 101, route-map: none
Input RP filter: none, route-map: none
Output (S,G) filter: none, route-map: none
Output RP filter: none, route-map: none
Input filter: none
Peer ttl threshold: 0
SAs learned from this peer: 1
Input queue size: 0, Output queue size: 0
Message counters:
RPF Failure count: 0
SA Messages in/out: 1/0
SA Requests in: 0
SA Responses out: 0
Data Packets in/out: 0/0

To display any SA messages the router has received we use the command “show ip msdp sa-cache” this will display the source tree entry for any multicast sources our neighbour is aware of, bearing in mind all SA messages are flooded to MSDP neighbours unless filtered by an SA-filtering

R3#sh ip msdp sa-cache
MSDP Source-Active Cache – 1 entries
(,, RP, BGP/AS 2, 00:01:50/00:05:04, Peer

Now let’s consider SA-filtering, as per my multicast notes blog I will use this to filter messages sent from R2 to R3. The scenario is as follows, R5 is the multicast source of and but R7 doesn’t need to receive multicast traffic from R5 on only traffic from R5 is required. So on R2 which is the nearest RP to R5 I will filter outbound messages to R3. In reverse we could do an inbound filter on R2. Configuration is as follows on R2.

access-list 101 permit ip host host
ip msdp sa-filter out list 101

Let’s test this with a ping to the multicast address.

R5#ping rep 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to, timeout is 2 seconds:
Reply to request 0 from, 28 ms
Reply to request 0 from, 156 ms
Reply to request 1 from, 52 ms
Reply to request 1 from, 180 ms
Reply to request 2 from, 48 ms
Reply to request 2 from, 176 ms

R5#ping rep 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to, timeout is 2 seconds:
Reply to request 0 from, 52 ms
Reply to request 1 from, 48 ms
Reply to request 2 from, 40 ms

So as you can see above R7 replies to but not, so the filter works as expected.

Also on R2 I used an inbound SA-Filter this does the opposite from an outbound filter. So the commands will only accepts SA-messages from peer with ( ,

ip msdp sa-filter in list 102
access-list 102 permit ip host host

Below you can see some packet captures on the routers showing the source active messages being sent from R2 to R3 and also from from R3 to R6.

MSDP SA from R2 -> R3

MSDP SA from R2 -> R3

MSDP SA from R3 -> R6

MSDP SA from R3 -> R6


Advertising a default route in BGP with an alternate default route as backup.

So you have your MPLS WAN and your filtering internet at your main data centre, everything going along nicely until the CE router at your data centre goes hard down, all your users are suddenly wondering why they can’t use Facebook or YouTube anymore!
Advertising a default route is easy but advertising multiple…………… now thats a different story.

You need to find a way of making the backup route less desirable, that way it would only be used if the original was unavailable, so here’s how to do it.

You will at least be familiar with BGP path selection, prefix lists, route-maps

Advertise your default route from your main data centre. Here is a sample config

router bgp xxxxx
neighbor x.x.x.x remote-as xxxxx

In order for BGP to advertise any route it must exist in the routing table so either you use a static route or you’re running a dynamic routing protocol to advertise into your router like EIGRP from your main data centre switch. (I would recommend you use a dynamic routing protocol)
Now that your default route is being advertised this will filter out to the rest of your WAN routers.
So your secondary default route is a little different you still need to advertise this but with some sort of distinguishing feature, the simplest way to do this is to use AS-Prepend this adds on the AS (Autonomous System) number you specify to the advertised route, If you know how BGP Path selection works you will know that BGP will prefer the shortest AS_PATH, regardless of bandwidth or connection type so imagine RIP routing it uses a hop count for route selection it’s the same idea as that. Note. BGP path selection does not solely rely on AS_PATH but for the purposes of this discussion we will assume you are not using WEIGHT, LOCAL_PREF or IGP redistribution.

Firstly you need to create a prefix list to match only the default route

ip prefix-list 10 description Secondary-default
ip prefix-list 10 seq 5 permit

Next thing you want to do is use a route map to tie in the conditions you need to set for the default route.

route-map default-route permit 5
match ip address prefix-list 10
set as-path prepend xxxxx xxxxx xxxxx xxxxx xxxxx
route-map default-route permit 10

Then all that’s left to do is advertise the route map via BGP

router bgp xxxxx
neighbor x.x.x.x remote-as xxxxx
neighbor x.x.x.x route-map default-route out

Again making sure the default route exists in your routing table otherwise it won’t be advertised.

Some commands you might use to confirm your changes will be

sh ip bgp
sh ip bgp
sh ip bgp neighbor x.x.x.x advertised-routes
sh ip route
sh ip route
sh run | inc ip route

Easy as that!

BGP is by far the most versatile and configurable routing protocol I have ever worked with it surprises me every time work with it I learn something new about it.