OSFP redistribution into MBGP

Hi,

I've noticed lately that OSPF redistribution into MBGP(multicast address-family) is not working.

I'm using following topology with R1,R2 and R3 running one OSPF area 0 as IGP with  125.1.X.R/24, and loopbacks 120.1.R.R/24

X = neighbor routers(R1,R2=12, R2,R3=23)

R = router number

Example: R1: 125.1.12.1, R2:125.1.12.2/125.1.23.2, R3:125.1.23.3

R1---R2---R3

  • R1's OSPF routing table is as follows

R1(config-router)#do show ip route ospf
     125.0.0.0/24 is subnetted, 3 subnets
O       125.1.23.0 [110/20] via 125.1.12.2, 00:44:34, FastEthernet0/1
     120.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O       120.1.3.3/32 [110/21] via 125.1.12.2, 00:44:34, FastEthernet0/1
O       120.1.2.2/32 [110/11] via 125.1.12.2, 00:39:37, FastEthernet0/1

  • I'm running BGP as 123 on all routers with R2 as RouteReflector and I'm also activating multicast ipv4 address family

R1(config-router)#do show bgp ipv4 multicast summary
BGP router identifier 120.1.1.1, local AS number 123
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
120.1.2.2       4   123      57      57        1    0    0 00:36:56        0

 

R2(config-router-af)#do show bgp ipv4 multicast summary
BGP router identifier 120.1.2.2, local AS number 123
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
120.1.1.1       4   123      58      58        1    0    0 00:37:24        0
120.1.3.3       4   123      53      53        1    0    0 00:37:59        0

R3(config-router-af)#do show bgp ipv4 multicast summary
BGP router identifier 120.1.3.3, local AS number 123
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
120.1.2.2       4   123      17      17        1    0    0 00:01:38        0

  • At this moment, everything should be ready for redistribution

R1:

!
router bgp 123

 address-family ipv4 multicast

 redistribute ospf 1 match internal

!

! However, nothing is injected into BGP

!

R1(config-router)#do show bgp ipv4 multicast       

R1(config-router)#

  • I enable "ip multicast-routing" on all routers in the network, I'm also enabling PIM SM on all interfaces. The result is the same, no prefixes were injected into MBGP

This is a similar problem with VOL1(8.29,8.30). Is there anybody who had this problem before?

Comments

  •  

    Have you tried adding route-reflector-client under the bgp multicast address family?

    That could be the problem.

  • I have RR under multicast family. The problem is on the local router injecting OSPF routes into BGP.

    Just verifying local originated prefixes on the router performing redistribution R1, and there will nothing.

    R1#show bgp ipv4 multicast regexp ^$

    R1#

  • Well I don't know a lot about multicast MBGP but I do know that multicast MBGP is used to exchange rpf information

    between two different multicast domains.

    The rpf table is populated by Static mroute/MBGP etc

    What are you trying to achive in general?

  • I think the title is suggesting already what I'm trying to do. It is all about ospf routes which are not injected localy into BGP, multicast family after issuing "redistribute ospf 1 " under address-family ipv4 multicast

  • Have you tried without match internal keyword just to see if that way will work ?

     

     

  • Well, I don't think the router will grab route learn from the same domain and readvertise it into 

    the same domain. It is a form of spilt horizon. Try redistributing a connected interface that is not

    part of the ospf domain and see what happens. 

  • Hi

     

    It does work but seem "flaky".  If you redis any other protocol it works fine.  I did red ospf also and nothing.  if you redis ospf to the ipv4 unicast address-family it triggers the multicast redistribution -  Not sure why:

    router bgp 500

     bgp log-neighbor-changes

     !

     address-family ipv4

      redistribute ospf 1

      no auto-summary

      no synchronization

     exit-address-family

     !

     address-family ipv4 multicast

      redistribute ospf 1

      no auto-summary

     exit-address-family

    Rack1R5(config-router-af)#do sh ip bgp ipv4 mul     

    BGP table version is 90, local router ID is 150.1.5.5

    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

    *> 150.1.4.4/32     155.1.45.4              65         32768 ?

    *> 150.1.5.0/24     0.0.0.0                  0         32768 ?

    *> 155.1.45.0/24    0.0.0.0                  0         32768 ?


    Rack1R5(config-router)#do sh ip route ospf

         150.1.0.0/16 is variably subnetted, 11 subnets, 2 masks

    O       150.1.4.4/32 [110/65] via 155.1.45.4, 00:08:08, Serial0/1/0

    Rack1R5(config-router)#do sh ip ospf int br

    Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C

    Lo0          1     0               150.1.5.5/24       1     LOOP  0/0

    Se0/1/0      1     0               155.1.45.5/24      64    P2P   1/1




    I guess some interplay with OSPF and BGP as they are closly linked but it seems buggy as it works sometimes and sometimes not.  


    Nick
  • I tried as well with other IGP and it worked, i also noticed that once redistribution into address-family ipv4 unicast is done SOMETIMES it will trigger multicast address-family too.

    I was and I'm still thinking that there is something which will trigger ospf redistribution into MBGP .

  • I've noticed a very interesting thing. Once i'm redistributing connected into multicast family, ospf routes are also triggered. If i'm removing redistribute connected ospf routes are still injected into BGP. After clearing multicast family peers ospf routes will still be injected into BGP.

    It looks more like a bug to me. I think i will try with another IOS, currently i'm using 12.4(15)T14 

  • Hi Andrei

     

    I was configuring this on Version 12.4(24)T5

     

    Nick

  • There seems to be no logical explanation for this behavior other than that it's a bug.

Sign In or Register to comment.