BGP

Feb 28 2009

6PE – IPv6 over MPLS

6PE is a really cool feature which allows IPv6 islands to communicate with each other over an MPLS/IPv4 core network. IPv4 addresses space is fast running out so familiarising yourself with IPv6 is probably a good idea.

Consider the toplogy below.

Service providers can leverage their MPLS networks to deliver IPv6 solutions without having to rearchitect their networks. The PE devices are configured with IPv6 routing capability, however the P nodes have no IPv6 routing functionality enabled.

Data packets are encapsualted into MPLS frames on the ingress PE with two labels, the bottom of the stack label being the label assigned to the IPv6 prefix and the top label which is used to forward the packet has a label binding of the PE3s loopback 0 address.

From 6PE2 if we do a cef lookup for the IPv6 prefix connected to 6PE1 we see the following.

6PE2#sh ipv6 cef 2001:2:: 2001:2::/64 nexthop 10.0.0.5 FastEthernet1/0 label 16 19

The bottom of stack label ie 19 is the ipv6 label and can be verified on 6PE2 as below.

6PE2#sh ip bgp ipv6 unicast labels Network Next Hop In label/Out label 2001:2::/64 ::FFFF:1.1.1.1 nolabel/19

The top label ie 16 is generated from a recursive lookup which points to the remote 6PE device ie 6PE1s loopback address.

6PE2#sh ip cef 1.1.1.1 1.1.1.1/32 nexthop 10.0.0.5 FastEthernet1/0 label 16 6PE2#

the 6CEs can use an IPv6 IGP for 6PE-to-6CE connectivity or they can rely on static routing. In this case static routing has been configured as below.

ipv6 route ::/0 FastEthernet1/0 2001:2::2

Watch the video below or download it and watch it on your iPod or iPhone.

By Zarar • BGP, CCIE SP, iPhone, iPod, IPv6, MPLS, PE-CE Routing • 2 • Tags: CCIE SP, IPv6, MPLS

Feb 11 2009

BGP – Remove Private AS

The video below shows how to remove a private AS from BGP as-path list.

Consider the topology below.

AS65300 peers eBGP with R1. R1 then peers eBGP with R2.

R1 is then configured to remove all private ASs in the as-path when it advertises BGP routes to R2.

Watch the video below or download and watch it on your iPod or iPhone.

The commands used in thiss video are as below:

CE1 ! interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface FastEthernet0 ip address 10.0.0.1 255.255.255.252 ! router bgp 65300 bgp log-neighbor-changes network 1.1.1.1 mask 255.255.255.255 neighbor 10.0.0.2 remote-as 1 !

R1
! interface FastEthernet1/0 ip address 10.0.0.2 255.255.255.252 ! interface FastEthernet1/1 ip address 10.0.0.5 255.255.255.252 ! router bgp 1 no synchronization bgp log-neighbor-changes neighbor 10.0.0.1 remote-as 65300 neighbor 10.0.0.6 remote-as 2 neighbor 10.0.0.6 remove-private-as no auto-summary !

R2
! interface FastEthernet0 ip address 10.0.0.6 255.255.255.252 ! router bgp 2 bgp log-neighbor-changes neighbor 10.0.0.5 remote-as 1 !

On R2 we can now see the bgp route 1.1.1.1/32 with the AS65300 in its as-path.
R2 ! R2#sh ip bgp BGP table version is 2, local router ID is 10.0.0.6 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path *> 1.1.1.1/32 10.0.0.5 0 1 i R2#

By Zarar • BGP, CCIE SP, CCIP, CCNP, iPhone, iPod • 5 • Tags: BGP, CCIE SP, CCIP

Jan 23 2009

eBGP multihop

eBGP multihop can be used to loadshare traffic across multiple links between eBGP peers.

Consider the topology below.

By default eBGP sessions can only be established between directly connected interfaces. If you want to connect to a non-connected interface or to a non-connected neighbor, you have to use the eBGP-multihop feature.

For this to work, you need to add a static route or routes if you want to load share so that BGP knows how to reach the non-connected interface.

To prevent the creation of loops through oscillating routes, the multihop will not be established if the only route to the multihop peer is the default route (0.0.0.0).(CCO)

The Video below shows how eBGP-multihop can be used to load-share traffic across multiple links between eBGP peers. Only a single eBGP-multihop session is required, the underlying static routes will load share the traffic. This can be confirmed in the FIB.

(Download and watch the video below on your iPod or iPhone).

The commands used in the above scenario can be found below.

R1
! interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface FastEthernet1/0 ip address 10.0.0.1 255.255.255.252 ! interface FastEthernet1/1 ip address 10.0.0.5 255.255.255.252 ! router bgp 1 neighbor 2.2.2.2 remote-as 2 neighbor 2.2.2.2 ebgp-multihop 2 neighbor 2.2.2.2 update-source Loopback0 ! ip route 2.2.2.2 255.255.255.255 10.0.0.2 ip route 2.2.2.2 255.255.255.255 10.0.0.6

R2
! interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface FastEthernet1/0 ip address 10.0.0.2 255.255.255.252 ! interface FastEthernet1/1 ip address 10.0.0.6 255.255.255.252 ! interface Loopback1 ip address 192.168.1.1 255.255.255.0 ! router bgp 2 network 192.168.1.0 neighbor 1.1.1.1 remote-as 1 neighbor 1.1.1.1 ebgp-multihop 2 neighbor 1.1.1.1 update-source Loopback0 ! ip route 1.1.1.1 255.255.255.255 10.0.0.1 ip route 1.1.1.1 255.255.255.255 10.0.0.5

By Zarar • BGP, CCIE, CCIE SP, CCIP, CCNP, iPhone, iPod • 9 • Tags: BGP, CCIE, CCIE SP, CCIP, CCNP

Jan 22 2009

BGP – Prefix aggregation using a static route

My previous post on BGP prefix aggregation used the bgp “aggregate-address” command. Another way to generate an aggregate is by using a static route.

Consider the toplology below.

Watch the video below to see how to configure a BGP aggregate using a static route. Alternatively down the video here and watch it on your iPod.

The commands used in the above video are listed below.

R1
! interface FastEthernet1/0 ip address 10.0.0.1 255.255.255.252 ! router bgp 1 neighbor 10.0.0.2 remote-as 2 no auto-summary

R2
! interface Loopback0 ip address 192.168.0.1 255.255.255.0 ! interface Loopback1 ip address 192.168.1.1 255.255.255.0 ! interface Loopback2 ip address 192.168.2.1 255.255.255.0 ! interface Loopback3 ip address 192.168.3.1 255.255.255.0 ! interface FastEthernet1/0 ip address 10.0.0.2 255.255.255.252 ! router bgp 2 no synchronization bgp log-neighbor-changes network 192.168.0.0 network 192.168.1.0 network 192.168.2.0 network 192.168.3.0 redistribute static neighbor 10.0.0.1 remote-as 1 no auto-summary

By Zarar • BGP, CCIE, CCIE SP, CCIP, CCNA, CCNP, iPod • 0 • Tags: BGP, CCIE, CCIE SP, CCIP, CCNA, CCNP

Jan 21 2009

BGP peer-groups and dynamic update peer groups

One of many optimizations for BGP is the peer-groups feature.

BGP peer-groups allow you to group BGP peers which have the same outbound policy. There are 2 obvious benefits for doing this.

Reduced the amount of configuration required.
BGP can send a single update to many peers.

Both of these need some clarification.

Consider the topology below.

Lets look at the first benefit ie reducing the amount of configuration required.

If we did not use peer-group then we would have to configure additional lines of configuration to acheive the same thing. Take the simple example below.

neighbor ipv4-iBGP peer-group neighbor ipv4-iBGP remote-as 1 neighbor ipv4-iBGP update-source Loopback0
to then provision a new bgp peer we need to simple add the config below.

neighbor 2.2.2.2 peer-group ipv4-iBGP

lets talk numbers, suppose we had 20 iBGP peers in total we need 20 + 3 ie 23 line of config. Without peer-groups we would need 20 *2 = 40 lines of config.

Now lets talk about the 2nd benefit ie the ability to generate a single update for multiple peers.

For BGP to send an update to its neighbor it first walks through the entire BGP table. BGP tables can easily have over 100,000 prefixes. Without peer-groups BGP must walk through the entire BGP table for each peer. Assume you have 20 neighbors that amounts to walking through 100,000 * 20 = 2,000,000 prefixes, Ouch!. Wouldn’t it be great if we could walk through the BGP table once and then replicate the update to all the peers. Well thats were peer-groups come in handy. If you have 20 peers in the same peer-group, BGP walks through the BGP table once and then replicates the update for all neighbors saving a lot of CPU cycles.

The downside of peer-groups is its lack of flexibility ie it is unlikely your vpnv4 sessions will share the same policy as your ipv4 sessions. Ideally you would like to group your ipv4 sessions into one update group and your vpnv4 session into another group. This is where dynamic update peer groups come into play.

Lets suppose you have an ipv4 and vpnv4 session between r1, r2 and r3. ie a single session carrying multip AFI/SAFI pairs. you would want to group your ipv4 sessions using one update policy and your vpnv4 sessions using another policy. dynamic update peer groups lets you do just that.

There are some other benfits to using dynamic update peer policy – namely in the flexibility to modify policies as well as the fact that update groups are dynamically created by BGP.

The configuration used to configure dynamic update peer groups on R1 can be found below.

R1
! router bgp 1 template peer-policy ipv4 send-community exit-peer-policy ! template peer-policy vpnv4 send-community extended exit-peer-policy ! template peer-session ipv4-iBGP remote-as 1 update-source Loopback0 exit-peer-session ! neighbor 2.2.2.2 inherit peer-session ipv4-iBGP neighbor 3.3.3.3 inherit peer-session ipv4-iBGP ! address-family ipv4 neighbor ipv4-iBGP send-community extended neighbor 2.2.2.2 activate neighbor 2.2.2.2 inherit peer-policy ipv4 neighbor 3.3.3.3 activate neighbor 3.3.3.3 inherit peer-policy ipv4 ! exit-address-family ! address-family vpnv4 neighbor 2.2.2.2 activate neighbor 2.2.2.2 inherit peer-policy vpnv4 neighbor 3.3.3.3 activate neighbor 3.3.3.3 inherit peer-policy vpnv4 exit-address-family !

By Zarar • BGP, CCIE, CCIE SP • 0 • Tags: BGP, CCIE, CCIE SP

Dec 30 2008

Prefix Lists

IP Prefix lists can be used with BGP to permit or deny specific prefixes from being advertised or learnt to or from a neighbor.

Consider the topology below.

We will carry out three exercises.

configure a prefix list to match 192.168.1.0/24
configure a prefix list to match 192.168.1.0/24, 192.168.1.0/25, 192.168.1.0/26.
configure a prefix list to match 192.168.1.0/25 and 192.168.1.0/26

Exercise 1

We configure the following prefix list and attach it to the bgp neighbor 10.0.0.2 using the commands below.

ip prefix-list slash-24-only seq 5 permit 192.168.1.0/24

router bgp 1 ! neighbor 10.0.0.2 prefix-list slash-24-only in

Exercise 2

We configure the following prefix list and attach it to the bgp neighbor 10.0.0.2 using the commands below.

ip prefix-list UP-TO-SLASH-26 seq 5 permit 192.168.1.0/24 le 26

router bgp 1 ! neighbor 10.0.0.2 prefix-list UP-TO-SLASH-26 in

Exercise 3

We configure the following prefix list and attach it to the bgp neighbor 10.0.0.2 using the commands below.

ip prefix-list GE-LE seq 5 permit 192.168.1.0/24 ge 25 le 26

router bgp 1 ! neighbor 10.0.0.2 prefix-list GE-LE in

Now let me try and explain what these 3 prefix lists are actually doing.

Prefix list 1 – slash-24-only

ip prefix-list slash-24-only seq 5 permit 192.168.1.0/24

This is pretty straight forward. This prefix list will match on the exact prefix as configured in the prefix list ie 192.168.1.0/24.

Prefix list 2 – UP-TO-SLASH-26

ip prefix-list UP-TO-SLASH-26 seq 5 permit 192.168.1.0/24 le 26

For a prefix to be permitted by this prefix-list the first 24 bits must match the first 24 bits of 192.168.1.0.

The le 26 then adds a subnet clause which states that the subnet mask being advertised must be less than or equal to 26 bits in length.

Lets consider a bunch of prefixes and see if they would be permited by the above prefix list.

192.168.1.0/24
192.168.1.4/30
192.168.1.128/25
192.168.1.0/23
192.168.1.0/27

Prefix 1 matches both criteria ie the first 24 bits in prefix 1 match the prefix in the prefix list and the subnet mask is less than 26 bits.

Prefix 2 matches the first criteria ie the first 24 bits in prefix 1 match the prefix in the prefix list, however the subnet mask is greater than 26 bits.

Prefix 3 also matches both criteria ie the first 24 bits in prefix 1 match the prefix in the prefix list and the subnet mask is less than 26 bits.

Prefix 4 is an invalid prefix, I’ll let you work out why.

Prefix 5 matches the first criteria but fails on the subnet mask length criteria and as such the prefix is denied.

Prefix list 3 – GE-Le

ip prefix-list GE-LE seq 5 permit 192.168.1.0/24 ge 25 le 26

Now this is an interesting beast. This prefix-list had 2 match clauses.

The prefix must match the first 24 bits on the prefix in the prefix list
The subnet mask must be between 25 and 26 bits in length

Lets consider a bunch of prefixes and see if they would be permited by the above prefix list.

192.168.1.0/24
192.168.1.4/30
192.168.1.128/25

Prefix 1 matches the first criteria ie the first 24 bits match, however the subnet mask is the wrong length.

Prefix 2 matches the first criteria ie the first 24 bits match, however the subnet mask is the wrong length.

Prefix 3 matches both criteria ie the first 24 bits in prefix 1 match the prefix in the prefix list and the subnet mask is greather than 25 bits buts still less than 26 bits.

I hope that makes sense. Anyhow, here is a video showing how to put it all together or alternativley click here to download and watch it on your iPod.

By zismail • BGP, CCIE, CCIE SP, CCIP, CCNP, iPod, Security • 0 • Tags: CCIE, CCIE SP, Security

Dec 28 2008

ARF – Automatic Route Filtering

When designing an MPLS network you will have to decide whether to configure a full mesh of MP-iBGP sessions between your PEs as in diagram 1 below or whether to use a hub and spoke topology as in diagram 2 below.

Diagram 1 – BGP full mesh

Diagram 2 – BGP partial mesh

The most obvious benefit of using a hub and spoke topology is that is scales a lot better than a full mesh topology. As you can see there are a lot less BGP sessions when using partial mesh design.

Automatic Route Filtering

iBGP sessions behave slightly differently with VPNv4 prefix than they do with IPv4 prefixes. Using diagram 2 as an example, In IPv4 world, R1 would send IPv4 prefixes to R3. These prefixes would be accepted by R3 and installed into the BGP table.

In VPNv4 world however this is not the case. In VPNv4 world when prefixes are learned from R1, R3 will reject(filter) the prefixes as R3 is not part of the VPN. ie R3 does not contain a vrf for those particular VPNv4 prefixes. This is known as Automatic Route Filtering, and guess what, its turned on by default. There are two ways to overcome this behavior. The first is to turn off ARF, the second is to configure R3 as a route-reflector. When you configure R3 as a route-reflector it turns ARF off by default.

Consider the toplogy below.

We will configure a VPNv4 session between R1 and R3. We will create a VPN on R1 called VPNA, which contains the prefix 192.168.1.0/24. We will redistribute this prefix into MP-BGP which will create a VPNv4 prefix and advertise it to R3. You will see by default that R3 rejects the route by default. To accept the route we will have to turn off ARF using the command below.

no bgp default route-target filter

Anyway, take a look at the video below and see ARF filtering the VPNv4 prefix or alternatively download it here and watch it on your iPod.

By zismail • BGP, CCIE SP, MPLS VPN • 3 • Tags: BGP, CCIE SP, MPLS VPN

Dec 27 2008

AFIs and SAFIs

BGP uses Open messages to negotiate BGP sessions. These Open messages have optional parameters which allow additional capabilities to be negotiated during setup.

If you want to run anything other than IPv4 unicast then you will have to configure BGP to advertise its additional capabilities i.e. Multi-Protocol extensions (AFI/SAFI) during initial setup.

As an example you may want to run IPv4 multicast, VPNv4 or even IPv6. The table below shows the different AFI and SAFI values. The AFI and SAFI values combine to form pairs which are used during the BGP negotiation phase. Ie if the BGP speaker wants to negotiate IPv4 multicast, then it advertises capability 1/2.

AFI	SAFI	TYPE
IPv4(1)	Unicast(1)	IPv4 Address
IPv4(1)	Multicast(2)	IPv4 Address
IPv4(1)	VPN(128)	VPNv4 Address
IPv6(2)	Unicast(1)	IPv6 Address

Lets suppose you wanted to run an MP-iBGP session between two PE routers to advertise IPv4 Unicast and IPv4 VPN(VPNv4) routes. You would need to negotiate AFI/SAFI pairs 1/1 and 1/128 during the initial BGP setup phase. If after the BGP session is established you would like to add an additional AFI/SAFI pair then BGP will have to renegotiate its capabilities which unfortunately means tearing down the original session. Some folks refer to this as BGP fate sharing.

Anyhow, lets see this in action. Consider the topology below.

Watch the video below or alternatively click here to download it and watch it on your iPod.

The commands used to configure the above can be found below.

R1
! ipv6 unicast-routing ! interface FastEthernet1/0 description "Interface connected to R2" ip address 10.0.0.1 255.255.255.252 ! router ospf 1 log-adjacency-changes network 1.1.1.1 0.0.0.0 area 0 network 10.0.0.0 0.0.0.3 area 0 ! router bgp 1 no bgp default ipv4-unicast neighbor 2.2.2.2 remote-as 1 neighbor 2.2.2.2 update-source Loopback0 ! address-family ipv4 neighbor 2.2.2.2 activate neighbor 2.2.2.2 send-community exit-address-family ! address-family vpnv4 neighbor 2.2.2.2 activate neighbor 2.2.2.2 send-community extended exit-address-family ! address-family ipv6 neighbor 2.2.2.2 activate exit-address-family

R2
! ipv6 unicast-routing ! interface FastEthernet1/0 description "Interface connected to R1" ip address 10.0.0.2 255.255.255.252 ! router ospf 1 log-adjacency-changes network 2.2.2.2 0.0.0.0 area 0 network 10.0.0.0 0.0.0.3 area 0 ! router bgp 1 no bgp default ipv4-unicast neighbor 1.1.1.1 remote-as 1 neighbor 1.1.1.1 update-source Loopback0 ! address-family ipv4 neighbor 1.1.1.1 activate neighbor 1.1.1.1 send-community exit-address-family ! address-family vpnv4 neighbor 1.1.1.1 activate neighbor 1.1.1.1 send-community extended exit-address-family ! address-family ipv6 neighbor 1.1.1.1 activate exit-address-family

By zismail • BGP, CCIE SP, iPod • 0 • Tags: BGP, CCIE SP

Dec 26 2008

BGP Route Aggregation

There are times when it is required to aggregate a set of prefixes. There are a number of reasons why you would want to do this such as, your peering transit edge may not accept certain size prefixes, you may want to reduce the size of the routing table in some part of your network etc etc.

Consider the topology below:-

Watch how to use the aggregate command below, or alternatively download the video and watch it on your iPod.

The commands used in the above setup are as below.

interface FastEthernet1/0 description "Interface connected to R2" ip address 10.0.0.1 255.255.255.252 ! router bgp 1 no synchronization bgp log-neighbor-changes neighbor 10.0.0.2 remote-as 2 no auto-summary

interface FastEthernet1/0 description "Interface connected to R1" ip address 10.0.0.2 255.255.255.252 ! interface Loopback0 ip address 192.168.0.1 255.255.255.0 ! interface Loopback1 ip address 192.168.1.1 255.255.255.0 ! interface Loopback2 ip address 192.168.2.1 255.255.255.0 ! interface Loopback3 ip address 192.168.3.1 255.255.255.0 ! router bgp 2 no synchronization bgp log-neighbor-changes network 192.168.0.0 network 192.168.1.0 network 192.168.2.0 network 192.168.3.0 aggregate-address 192.168.0.0 255.255.252.0 suppress-map SUPPRESS-2-ONLY neighbor 10.0.0.1 remote-as 1 no auto-summary ! access-list 1 permit 192.168.2.0 0.0.0.255 ! route-map SUPPRESS-2-ONLY permit 10 match ip address 1

By zismail • BGP, CCIE, CCIE SP, CCIP, CCNA, CCNP, iPod • 0 • Tags: BGP, CCIE, CCIE SP, CCIP, CCNA, CCNP

Dec 15 2008

IPv4 BGP multicast

IPv4 BGP multicast announcements can be somewhat confusing. It took a while to get my head around it, so now that I have, I will try to explain.

I have set up the topology below.

Everything has been configured in the above scenario EXCEPT the IPv4 BGP multicast session between RP and ASBR-RP. I want to show how you can change the multicast path using IPV4 BGP multicast.

lets start by understanding BGP AS2

The receiver sends a join for group 224.1.1.1, Net-Edge2 receives the igmp join and forwards a PIM JOIN to ASBR-RP. We can now see a (*,G) entry in the multicast routing table as below.

ASBR-RP#show ip mroute (*, 224.1.1.1), 00:24:06/00:02:42, RP 4.4.4.4, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet2/0, Forward/Sparse, 00:24:06/00:02:42

Pretty straight forward so far.

Now lets look at BGP AS1 from an IPv4 routing perspective

AS1 runs ISIS as the IGP. IPv4 192.168.1.0/24 and 2.2.2.2/32 prefixes are advertised into ISIS. ASBR1 is the only device which runs BGP in AS1. ASBR1 then advertises 192.168.1.0/24 and 2.2.2.2/32 to AS2 as IPv4 prefixes. If we examine the IPv4 routing table on ASBR-RP we can see it has an entry for 192.168.1.0/24 and 2.2.2.2/32 as below.

ASBR-RP#sh ip route 192.168.1.0 Routing entry for 192.168.1.0/24 Known via "bgp 2", distance 20, metric 10 Tag 1, type external Last update from 10.0.0.1 00:14:09 ago Routing Descriptor Blocks: * 10.0.0.1, from 10.0.0.1, 00:14:09 ago Route metric is 10, traffic share count is 1 AS Hops 1 Route tag 1

ASBR-RP#sh ip route 2.2.2.2 Routing entry for 2.2.2.2/32 Known via "bgp 2", distance 20, metric 20 Tag 1, type external Last update from 10.0.0.1 00:05:20 ago Routing Descriptor Blocks: * 10.0.0.1, from 10.0.0.1, 00:05:20 ago Route metric is 20, traffic share count is 1 AS Hops 1 Route tag 1

nothing majorly complicated here.

We now setup an MSDP session using the basic config between RP and ASBR-RP using the commands below on RP and ASBR-RP respectivly.

RP#sh run | in msdp ip msdp peer 10.0.0.6 connect-source FastEthernet1/1 remote-as 2 ip msdp cache-sa-state

ASBR-RP

ip msdp peer 10.0.0.5 connect-source FastEthernet1/0 remote-as 1 ip msdp cache-sa-state

no rocket science here.

Now lets kick off some multicast traffic from the source destined to 224.1.1.1 from 192.168.1.1

We should see an entry in the multicast routing table of RP in AS1.

RP#show ip mroute 224.1.1.1 (*, 224.1.1.1), 00:00:06/stopped, RP 2.2.2.2, flags: SP Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Null

(192.168.1.1, 224.1.1.1), 00:00:06/00:02:53, flags: PA Incoming interface: FastEthernet1/0, RPF nbr 11.0.0.1 Outgoing interface list: Null

Everything good so far.

MSDP should now advertise this source to its peer ASBR-RP in AS 2. Lets check to see if this has happened.

ASBR-RP#show ip msdp sa-cache MSDP Source-Active Cache - 1 entries (192.168.1.1, 224.1.1.1), RP 2.2.2.2, BGP/AS 0, 00:01:50/00:05:29, Peer 10.0.0.5

yep we can see it.

Now lets check to see whether we can see the entry in the mcast table on ASBR-RP.

ASBR-RP#sh ip mroute 224.1.1.1 (*, 224.1.1.1), 00:12:56/00:03:11, RP 4.4.4.4, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet2/0, Forward/Sparse, 00:12:07/00:03:11

(192.168.1.1, 224.1.1.1), 00:12:56/00:03:28, flags: T Incoming interface: FastEthernet1/1, RPF nbr 10.0.0.1 Outgoing interface list: FastEthernet2/0, Forward/Sparse, 00:12:07/00:03:11

Yep, we can see it, but notice that the incoming interface is being shown as fastethernet1/1 and the RPF neighbor is 10.0.0.1. This is due to the fact that the PIM Join message was sent using the ipv4 routing table and as such was routed via the lower link in the diagram. This is not what we were trying to acheive, we wanted the SPT tree to flow over the upper link, upon which we configured MSDP. To fix this we simply setup a IPv4 BGP multicast session as follows on RP.

router bgp 1 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 10.0.0.6 remote-as 2 ! address-family ipv4 multicast neighbor 10.0.0.6 activate no auto-summary network 192.168.1.0 exit-address-family

Check on ASBR-RP that the multicast IPv4 prefix is being learnt.

ASBR-RP#sh ip bgp ipv4 multicast Network Next Hop Metric LocPrf Weight Path *> 192.168.1.0 10.0.0.5 10 0 1 i ASBR-RP#

Its also worth noting that this prefix does not enter the unicast routing table as you can see below.

ASBR-RP#sh ip route 192.168.1.0 Routing entry for 192.168.1.0/24 Known via "bgp 2", distance 20, metric 20 Tag 1, type external Last update from 10.0.0.1 00:04:22 ago Routing Descriptor Blocks: * 10.0.0.1, from 10.0.0.1, 00:04:22 ago Route metric is 20, traffic share count is 1 AS Hops 1 Route tag 1

Now if we check the multicast routing table on ASBR-RP we will see the following.

ASBR-RP#sh ip mroute 224.1.1.1 (*, 224.1.1.1), 00:25:48/00:03:06, RP 4.4.4.4, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet2/0, Forward/Sparse, 00:24:59/00:03:06

(192.168.1.1, 224.1.1.1), 00:25:48/00:03:27, flags: T Incoming interface: FastEthernet1/0, RPF nbr 10.0.0.5, Mbgp Outgoing interface list: FastEthernet2/0, Forward/Sparse, 00:24:59/00:03:06

As you can see the incoming interface is now the upper link in the diagram and the RPF neighbor has changed to 10.0.0.5.

Therefore we can conclude the following, the IPv4 BGP multicast entries are used to send PIM Joins as well as conduct RPF checks on incoming multicast data traffic. To further prove that the IPv4 BGP multicast entries are used to forward PIM Join messages we could remove the IPv4 prefixes which are being advertised over the lower link and see if we still have a SPT to ASBR-RP.

ASBR-RP#sh ip mroute 224.1.1.1 (*, 224.1.1.1), 00:01:19/00:03:26, RP 4.4.4.4, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet2/0, Forward/Sparse, 00:01:03/00:03:26

(192.168.1.1, 224.1.1.1), 00:01:19/00:03:22, flags: T Incoming interface: FastEthernet1/0, RPF nbr 10.0.0.5, Mbgp Outgoing interface list: FastEthernet2/0, Forward/Sparse, 00:01:03/00:03:25

Yep, its still there.

However, now that we have withdrawn the IPv4 prefixes from AS2 Net-Edge2 will no longer we able to build an SPT to the source as it has no route to 192.168.1.1 but rather will have to use the shared tree as you can see below.

net-edge2#sh ip mroute 224.1.1.1 (*, 224.1.1.1), 02:42:16/00:02:58, RP 4.4.4.4, flags: SJCL Incoming interface: FastEthernet1/0, RPF nbr 12.0.0.1 Outgoing interface list: Loopback0, Forward/Sparse, 02:42:16/00:02:17

(192.168.1.1, 224.1.1.1), 00:02:51/00:00:08, flags: LJ Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Loopback0, Forward/Sparse, 00:02:51/00:02:17

If we reinject the IPv4 prefix 192.168.1.0/24 using BGP on ASBR1 and then reexamine the multicast entry for 224.1.1.1 on net-edge2 we see the following.

net-edge2#sh ip mroute 224.1.1.1 (*, 224.1.1.1), 00:00:09/stopped, RP 4.4.4.4, flags: SJCL Incoming interface: FastEthernet1/0, RPF nbr 12.0.0.1 Outgoing interface list: Loopback0, Forward/Sparse, 00:00:09/00:02:50

(192.168.1.1, 224.1.1.1), 00:00:00/00:02:59, flags: LJT Incoming interface: FastEthernet1/0, RPF nbr 12.0.0.1 Outgoing interface list: Loopback0, Forward/Sparse, 00:00:00/00:02:59

As you can see net-edge2 is now using the (S,G) tree. MAGIC:-)

Anyway, I hope that makes sense.

By zismail • BGP, CCIE SP, MSDP, Multicast, PIM-SM • 2 • Tags: CCIE SP, IPv4 BGP Multicast, MSDP, Multicast

1 2 3

BGP

Categories

Tags