Friday, August 23, 2013

BGP - Unicast NLRI to Multicast NLRI - translate-update cisco

I have been extremely busy with work, school and CCIE studies so I have not been able to post as much as I want to. There are numerous drafts ready to be posted so hopefully I'll have sometime to share it on here. Alright, enough with the excuses and let's get started. In this blogtorial we will see how we can take a unicast route received from a unicast BGP neighbor and install it in the multicast routing table and advertise it to MBGP peers using translate-update feature. Usually this is done for in-congruent BGP topology where a MBGP capable router peers with router that is incapable of MBGP.

Here is the topology.
The entire configs can be downloaded here so you can lab it up in GNS3.


First let's get BGP configured between R1 and R2. Imagine that R1 is running an older version code where MBGP capability is not avalaible. Further assume that R2 needs to establish a MBGP session with R3 and advertise the multicast source route (192.168.1.0/24) so R3 can build the right trees and pass the RPF checks. 
  
 R1#sh run int gig1/0  
 Building configuration...  
 Current configuration : 117 bytes  
 !  
 interface GigabitEthernet1/0  
  description connected to r2  
  ip address 1.1.1.1 255.255.255.0
  ip pim sparse-dense-mode  
  negotiation auto  
 end  
 R1#sh run | in ip route  
 ip route 192.168.1.0 255.255.255.0 Null0  
 R1#  
 R1#sh run | sec bgp  
 router bgp 1  
  no synchronization  
  bgp log-neighbor-changes  
  network 192.168.1.0  
  neighbor 1.1.1.2 remote-as 2  
  neighbor 1.1.1.2 description connected to r2  
  no auto-summary  
 R1#  

 R2#sh run int gi1/0  
 Building configuration...  
 Current configuration : 117 bytes  
 !  
 interface GigabitEthernet1/0  
  description connected to r1  
  ip address 1.1.1.2 255.255.255.0 
  ip pim sparse-dense-mode   
  negotiation auto  
 end  
 R2#sh run | sec bgp  
 router bgp 2  
  bgp log-neighbor-changes  
  neighbor 1.1.1.1 remote-as 1  
  neighbor 1.1.1.1 description connected to r1  
  !  
  address-family ipv4  
  neighbor 1.1.1.1 activate  
  neighbor 1.1.1.1 translate-update ipv4 multicast  
  neighbor 1.1.1.1 soft-reconfiguration inbound  
  no auto-summary  
  no synchronization  
  exit-address-family  
  !  
  address-family ipv4 multicast  
  neighbor 1.1.1.1 activate  
  no auto-summary  
  no synchronization  
  exit-address-family  
 R2#  

Let's do a few show commands on R2 to verify that 192.168.1.0/24 from R1 is being installed into the mrib.

 R2#sh ip route  
 Gateway of last resort is not set  
    1.0.0.0/24 is subnetted, 1 subnets  
 C    1.1.1.0 is directly connected, GigabitEthernet1/0  
    2.0.0.0/24 is subnetted, 1 subnets  
 C    2.2.2.0 is directly connected, GigabitEthernet2/0  
 !!Notice that 192.168.1.0/24 is not in the unicast routing table. 
 R2#show ip mbgp  
 BGP table version is 2, local router ID is 2.2.2.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  
 *> 192.168.1.0   1.1.1.1         0       0 1 i  
 !!Notice that it is however in the mbgp table.
 R2#sh ip rpf 192.168.1.0  
 RPF information for ? (192.168.1.0)  
  RPF interface: GigabitEthernet1/0  
  RPF neighbor: ? (1.1.1.1)  
  RPF route/mask: 192.168.1.0/24  
  RPF type: mbgp  
  RPF recursion count: 0  
  Doing distance-preferred lookups across tables  
 !!Notice the RPF check is stating that the route is learned via mBGP

We can now easily MBGP peer with R3 and send this route.

 R2#  
 router bgp 2  
  neighbor 2.2.2.3 remote-as 3  
  neighbor 2.2.2.3 description connected to r3  
  !  
  address-family ipv4  
  no neighbor 2.2.2.3 activate  
  no auto-summary  
  no synchronization  
  exit-address-family  
  !  
  address-family ipv4 multicast  
  neighbor 2.2.2.3 activate  
  exit-address-family  
 R2#  

R3 BGP and interface configs.

 R3#  
 interface GigabitEthernet1/0  
  description connected to r2  
  ip address 2.2.2.3 255.255.255.0  
  ip pim sparse-dense-mode  
  negotiation auto  
 !  
 router bgp 3  
  bgp log-neighbor-changes  
  neighbor 2.2.2.2 remote-as 2  
  neighbor 2.2.2.2 description connected to r2  
  !  
  address-family ipv4  
  no neighbor 2.2.2.2 activate  
  no auto-summary  
  no synchronization  
  exit-address-family  
  !  
  address-family ipv4 multicast  
  neighbor 2.2.2.2 activate  
  no auto-summary  
  no synchronization  
  exit-address-family  
 !  
 R3#  

Let's do a few show commands to verify that R3 is installing 192.168.1.0/24 into the mrib.

 R3#sh ip mbgp  
 BGP table version is 2, local router ID is 2.2.2.3  
 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  
 *> 192.168.1.0   2.2.2.2                0 2 1 i  
 R3#sh ip rpf 192.168.1.0  
 RPF information for ? (192.168.1.0)  
  RPF interface: GigabitEthernet1/0  
  RPF neighbor: ? (2.2.2.2)  
  RPF route/mask: 192.168.1.0/24  
  RPF type: mbgp  
  RPF recursion count: 0  
  Doing distance-preferred lookups across tables  
 R3#sh ip mbgp summary  
 BGP router identifier 2.2.2.3, local AS number 3  
 BGP table version is 2, main routing table version 2  
 1 network entries using 120 bytes of memory  
 1 path entries using 48 bytes of memory  
 2/1 BGP path/bestpath attribute entries using 248 bytes of memory  
 1 BGP AS-PATH entries using 24 bytes of memory  
 0 BGP route-map cache entries using 0 bytes of memory  
 0 BGP filter-list cache entries using 0 bytes of memory  
 BGP using 440 total bytes of memory  
 BGP activity 1/0 prefixes, 1/0 paths, scan interval 60 secs  
 Neighbor    V  AS MsgRcvd MsgSent  TblVer InQ OutQ Up/Down State/PfxRcd  
 2.2.2.2     4   2    7    6    2  0  0 00:03:47    1  
 R3#  

There you have it. 192.168.1.0/24 received from a BGP peer is converted into multicast NLRI and sent to R3 in a mBGP session. This should really be done in a stop-gap situation and should not be implemented in a permanent design.

Many more articles to come so stay tuned.

Please reshare/subscribe/comment/+1 if you like my posts as it keeps me motivated to write more and spread the knowledge.

1 comment:

  1. Thanks for the blog. It's really great. Have a doubt . Why R2 is not learning prefix "192.168.1.0/24" in R2 unicast table where network command is there in R1?

    ReplyDelete