address-family ipv4 multicast


I'm on R&S track and not familiar with MPBGP-Multicast (more closely to SP track).

http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/guide/1cfmbgp.html

 

Is there good blog or example how this works ? 

 

Comments

  • It's pretty much the same behaviour as with unicast. You use the multicast family to populate RPF table. So sources and RP's should be present in the multicast family. You can use network statements or redistribute just as in the unicast family.

  • Thanks for the link. I have some question related with MSDP & MBGP.

     

    I test MSDP is working fine with just Unicast BGP. What is the advantage of using Multicast BGP ?

     

    What is the common design between MSDP and MBGP ?

    a. MSDP Peer: Is the SA RPF check should be done with Unicast BGP ?

    b. RPF check for Multicast traffic between domain should be done with Multicast BGP ?

     

     

  • I test MSDP is working fine with just Unicast BGP. What is the advantage of using Multicast BGP ?

    We can apply different policies for multicast and unicast routes by using MBGP address family. For example if there are two link connecting between 2 ASes then we can apply a policy saying that use one link for multicast and other for unicast or any other complex policy. 

  • MBGP does not carry any information related to multicast addresses.

    So it doesn't matter if you are using unicast or multicast BGP.

    The reason for having a dedicated multicast RPF table/multicast address-family is to achieve an
    incongruent next-hop selection for unicast versus multicast RPF routes; that is to say, the next hop used to route unicast packets to some prefixes can be different from the next hop used for multicast RPF checks.

    Why different NH for unicast & multicast?

    To avoid routers not capable of multicast routing as multicast RPF next hops but
    still use them as unicast forwarding next hops

    To use different links and routers for multicast and unicast traffic— for example,
    where ISPs publicly peer at a Multicast Internet Exchange (MIX) to exchange multicast traffic only

     

  •  

    Amarjeet

     

    Topology :

    R1(Source-0) -- R2(RP/MSDP/AS100)--Link1-Unicast-BGP--R3 (RP/MSDP/AS200)-- R4 (Receiver-0)

    R5(Source-1)                                 --Link2-Multicast BGP-                              - R6 (Receiver-1)

    R7(Source-2)                                 --Link3-Multicast BGP-                             - R8 (Receiver-2) 

     

    Can we have this design ?

        a. Advertise Source-0 and MSDP  via link-1 using Unicast BGP

        b. Advertise Source-1 via Link2 using Mulitcast BGP  and only allow group-1 using multicast boundary.

        c. Advertise Source-2 via Link3 using Multicast BGP  and only allow grop-2  using multicast boundary.

     

    Should source-1 and source-2  be advertised via Unicast BGP too ?

     

     

  • Narayan

    Thanks for the link. It's getting clearer now.

    If you can give one good example, it will solidify the theory. thanks!

     

  • Narayan

    Thanks for the link. It's getting clearer now.

    If you can give one good example, it will solidify the theory. thanks!

    Hi AndiS,

    As you asked for one good Example of Multicast BGP, I am posting here: This is same example I creted for another thread as well:

    This is a topology:

    R1------- R2-------

                   |         |

                   |         |

                   |         R3
                              |
    R5--------R4------|

    OSPF is configured as IGP and I increased the OSPF cost on R2 so unicast flow will be through R1-R2-R3-R4-R5 but I would like to send the multicast flow via R1-R2-R4-R5 where R1 is sender, R2 is RP and R5 is receiver:

    R1#traceroute 5.5.5.5 so lo0

    Type escape sequence to abort.
    Tracing the route to 5.5.5.5

      1 12.12.12.2 116 msec 136 msec 52 msec
      2 23.23.23.3 208 msec 100 msec 116 msec
      3 34.34.34.4 172 msec 168 msec 176 msec
      4 45.45.45.5 272 msec *  100 msec
    R1#ping 225.5.5.5

    Type escape sequence to abort.
    Sending 1, 100-byte ICMP Echos to 225.5.5.5, timeout is 2 seconds:
    .
    R1#ping 225.5.5.5

    Type escape sequence to abort.
    Sending 1, 100-byte ICMP Echos to 225.5.5.5, timeout is 2 seconds:
    .
    R2#show ip mroute count
    IP Multicast Statistics
    3 routes using 1540 bytes of memory
    2 groups, 0.50 average sources per group
    Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
    Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

    Group: 225.5.5.5, Source count: 1, Packets forwarded: 0, Packets received: 2
      RP-tree: Forwarding: 0/0/0/0, Other: 0/0/0
      Source: 12.12.12.1/32, Forwarding: 0/0/0/0, Other: 2/0/2 you can see here multicast packets are getting dropped due to RPF failure, I haven't configured multicast BGP yet. Let's configure the BGP with multicast SAFI

    R2#show run | section router bgp
    router bgp 1
     no bgp default ipv4-unicast
     bgp log-neighbor-changes
     neighbor 4.4.4.4 remote-as 1
     neighbor 4.4.4.4 update-source Loopback0
     !
     address-family ipv4
      no synchronization
      no auto-summary
     exit-address-family
     !
     address-family ipv4 multicast
      neighbor 4.4.4.4 activate
      no auto-summary
     exit-address-family
    R4#show running-config | section router bgp
    router bgp 1
     no bgp default ipv4-unicast
     bgp log-neighbor-changes
     neighbor 2.2.2.2 remote-as 1
     neighbor 2.2.2.2 update-source Loopback0
     !
     address-family ipv4
      no synchronization
      no auto-summary
     exit-address-family
     !
     address-family ipv4 multicast
      neighbor 2.2.2.2 activate
      no auto-summary
     exit-address-family
    R2#show ip bgp all summary | be Ne
    Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
    4.4.4.4         4            1       8       8        1    0    0 00:04:05        0
    R1#ping 225.5.5.5 re 10

    Type escape sequence to abort.
    Sending 10, 100-byte ICMP Echos to 225.5.5.5, timeout is 2 seconds:

    Reply to request 0 from 5.5.5.5, 444 ms
    Reply to request 1 from 5.5.5.5, 248 ms
    Reply to request 2 from 5.5.5.5, 216 ms
    Reply to request 3 from 5.5.5.5, 228 ms
    Reply to request 4 from 5.5.5.5, 168 ms
    Reply to request 5 from 5.5.5.5, 256 ms
    Reply to request 6 from 5.5.5.5, 88 ms
    Reply to request 7 from 5.5.5.5, 212 ms

    Now we are getting successfull reply from R5, let's run the mtrace on R1

    R1#mtrace 1.1.1.1 5.5.5.5 225.5.5.5
    Type escape sequence to abort.
    Mtrace from 1.1.1.1 to 5.5.5.5 via group 225.5.5.5
    From source (?) to destination (?)
    Querying full reverse path...
     0  5.5.5.5
    -1  45.45.45.5 None  [using shared tree]
    -2  45.45.45.4 None  [using shared tree]
    -3  24.24.24.2 PIM Reached RP/Core [using shared tree]

    Good Luck

  • Hi Narayan

    In the example you have presented, the first part where source R1 is sending multicast to a receiver attached to R5 for a group 225.5.5.5. In this case R1 should get replies back from R5 since you have pim enabled on all interfaces and therefore no RPF failure at R4.  

     

    In the second part where you have configured MP-BGP between R2 and R4 loopbacks. The loopbacks are advertise in IGP and for them the prefer path is R2--R3--R4 since you have raised cost between R2 and R3. Thats means data traffic will always follow this path. Therefore even with BGP the path remain the same for the flow between source to receiver.

     

     

     

     

  • In the example you have presented, the first part where source R1 is sending multicast to a receiver attached to R5 for a group 225.5.5.5. In this case R1 should get replies back from R5 since you have pim enabled on all interfaces and therefore no RPF failure at R4.  
    .

    No, you don't get reply, why you are thinking you will get reply in this case?

    1. My unicast flow is R1-R2-R3-R4-R5 and PIM is not enabled between R2-R3-R4, PIM is enabled between R2-R4 inteface and R4-R5 not on all interfaces of R4. I think you didn't look on my show ip mroute count output, you can see the dropped multicast packets.

    So my intention is to accept the multicast traffic via R2-R4 so  I configured BGP multicast between R2 and R4, after this working fine. Yes we can configure static multicast route within same AS domain but my intention is to show the example of how multicast BGP works. In reality mBGP is between ASs and AS has it's own RP but here I have one RP which is R2.

    Therefore even with BGP the path remain the same for the flow between source to receiver.
    .

    Not clear for me what you mean?

  • 1. My unicast flow is R1-R2-R3-R4-R5 and PIM is not enabled between R2-R3-R4, PIM is enabled between R2-R4 inteface and R4-R5 not on all interfaces of R4. I think you didn't look on my show ip mroute count output, you can see the dropped multicast packets.

    I was under an impression that PIM is enabled on all interfaces.Its all right then.

  • I was under an impression that PIM is enabled on all interfaces.Its all right then.

    If PIM is enabled on all interfaces, why we need static multicast route or Multicast BGP, isn't it?[:P]

  • If PIM is enabled on all interfaces, why we need static multicast route or Multicast BGP, isn't it?Stick out tongue

    For multicast traffic path manipulation. 

  • Correct.  It’s so you can use a different set of links for unicast traffic vs. multicast traffic.  Basically traffic engineering for how the multicast tree is built.

     

    Brian McGahan, CCIE #8593 (R&S/SP/Security)

    [email protected]

     

    Internetwork Expert, Inc.

    http://www.INE.com

     

    From: [email protected] [mailto:[email protected]] On Behalf Of dcancerian
    Sent: Sunday, March 18, 2012 12:45 PM
    To: Brian McGahan
    Subject: Re: [CCIE SP] address-family ipv4 multicast

     

    imageNarayan.Neupane:

    If PIM is enabled on all interfaces, why we need static multicast route or Multicast BGP, isn't it?Stick out tongue

    For multicast traffic path manipulation. 




    INE - The Industry Leader in CCIE Preparation
    http://www.INE.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • Correct.  It’s so you can use a different set of links for unicast traffic vs. multicast traffic.  Basically traffic engineering for how the multicast tree is built.

    True, My example also to show the different path for unicast traffic than multicast. In my example Unicast flow is R1-R2-R3-R4-R5 and  multicast flow through R1-R2-R4-R5 and PIM is not enabled between R2-R3-R4. I configured Multicast BGP between R2 and R4 to flow the multicast traffic between.

    But my question was to dcancerian as he was saying PIM is enabled on all interfaces and multicast traffic flow is in same path as unicast. That is the reason of questioning him if I have to flow the multicast traffic in same path of unicast, there is no need of static multicast route or BGP multicast.

     

  • But my question was to dcancerian as he was saying PIM is enabled on all interfaces and multicast traffic flow is in same path as unicast. That is the reason of questioning him if I have to flow the multicast traffic in same path of unicast, there is no need of static multicast route or BGP multicast.

    The reason i mentioned you about this because in your scenario R2 and R4's loopback are forming bgp peering on their loopbacks and these loopbacks are reachable to each other via unicast best path(R2--R3--R4) due to higher cost between R2 and R4. So unless you change the next hop at R2 and R4 towards each other for address family ipv4 multicast , the multicast traffic will flow the same path as unicast because in this case next hop is always recurse towards the unicast shortest path.

  • If PIM is everywhere as well as IGP, you are correct there is no reason to do static multicast routes or to run multicast BGP unless you want to do traffic engineering.  Basically the static mroutes or MBGP have two applications, either fixing RPF failures because PIM isn’t everywhere or traffic engineering.

     

    Brian McGahan, CCIE #8593 (R&S/SP/Security)

    [email protected]

     

    Internetwork Expert, Inc.

    http://www.INE.com

     

    From: [email protected] [mailto:[email protected]] On Behalf Of Narayan.Neupane
    Sent: Sunday, March 18, 2012 2:51 PM
    To: Brian McGahan
    Subject: Re: [CCIE SP] RE: address-family ipv4 multicast

     

    imageBrian McGahan:

    Correct.  It’s so you can use a different set of links for unicast traffic vs. multicast traffic.  Basically traffic engineering for how the multicast tree is built.

    True, My example also to show the different path for unicast traffic than multicast. In my example Unicast flow is R1-R2-R3-R4-R5 and  multicast flow through R1-R2-R4-R5 and PIM is not enabled between R2-R3-R4. I configured Multicast BGP between R2 and R4 to flow the multicast traffic between.

    But my question was to dcancerian as he was saying PIM is enabled on all interfaces and multicast traffic flow is in same path as unicast. That is the reason of questioning him if I have to flow the multicast traffic in same path of unicast, there is no need of static multicast route or BGP multicast.

     




    INE - The Industry Leader in CCIE Preparation
    http://www.INE.com

    Subscription information may be found at:
    http://www.ieoc.com/forums/ForumSubscriptions.aspx

  • the multicast traffic will flow the same path as unicast because in this case next hop is always recurse towards the unicast shortest path.

    I understand what you mean but in both cases (BGP peering on 2.2.2.2-4.4.4.4) or 24.24.24.2-24.24.24.4, I can see all multicast packets are forwarded between R2 to R4 and unicast via R3 see the output of debug ip mpacket detail on R2:

    R2#show  ip int brief | ex un
    Interface                  IP-Address      OK? Method Status                Protocol
    FastEthernet0/0            12.12.12.2      YES manual up                    up
    FastEthernet1/0            23.23.23.2      YES manual up                    up
    FastEthernet2/0            24.24.24.2      YES manual up                    up
    Loopback0                  2.2.2.2         YES manual up                    up
    Loopback1                  172.16.0.1      YES manual up                    up

    BGP peering on 24.24.24.2-4

    *Mar  1 01:05:32.003: IP(0): MAC sa=cc00.1f60.0000 (FastEthernet0/0), IP last-ho                                                                                        p=12.12.12.1

    *Mar  1 01:05:32.003: IP(0): IP tos=0x0, len=100, id=113, ttl=254, prot=1
    *Mar  1 01:05:32.003: IP(0): s=1.1.1.1 (FastEthernet0/0) d=225.5.5.5 (FastEthern                                                                                        et2/0) id=113, ttl=254, prot=1, len=100(100), mforward
    R2#

    *Mar  1 01:05:33.995: IP(0): MAC sa=cc00.1f60.0000 (FastEthernet0/0), IP last-ho                                                                                        p=12.12.12.1
    *Mar  1 01:05:33.995: IP(0): IP tos=0x0, len=100, id=114, ttl=254, prot=1
    *Mar  1 01:05:33.995: IP(0): s=1.1.1.1 (FastEthernet0/0) d=225.5.5.5 (FastEthern                                                                                        et2/0) id=114, ttl=254, prot=1, len=100(100), mforward
    R2#
    *Mar  1 01:05:36.023: IP(0): MAC sa=cc00.1f60.0000 (FastEthernet0/0), IP last-ho                                                                                        p=12.12.12.1
    *Mar  1 01:05:36.023: IP(0): IP tos=0x0, len=100, id=115, ttl=254, prot=1
    *Mar  1 01:05:36.027: IP(0): s=1.1.1.1 (FastEthernet0/0) d=225.5.5.5 (FastEthern                                                                                        et2/0) id=115, ttl=254, prot=1, len=100(100), mforward
    R2#
    *Mar  1 01:05:37.999: IP(0): MAC sa=cc00.1f60.0000 (FastEthernet0/0), IP last-ho                                                                                        p=12.12.12.1
    *Mar  1 01:05:37.999: IP(0): IP tos=0x0, len=100, id=116, ttl=254, prot=1
    *Mar  1 01:05:37.999: IP(0): s=1.1.1.1 (FastEthernet0/0) d=225.5.5.5 (FastEthern                                                                                        et2/0) id=116, ttl=254, prot=1, len=100(100), mforward

     

    BGP peering on 2.2.2.2-4.4.4.4 these routes are advertising by OSPF via R2-R3-R4:

    *Mar  1 01:09:33.171: IP(0): MAC sa=cc00.1f60.0000 (FastEthernet0/0), IP last-hop=12.12.12.1
    *Mar  1 01:09:33.171: IP(0): IP tos=0x0, len=100, id=125, ttl=254, prot=1
    *Mar  1 01:09:33.171: IP(0): s=1.1.1.1 (FastEthernet0/0) d=225.5.5.5 (FastEthernet2/0) id=125, ttl=254, prot=1, len=100(100), mforward
    R2#
    *Mar  1 01:09:35.175: IP(0): MAC sa=cc00.1f60.0000 (FastEthernet0/0), IP last-hop=12.12.12.1
    *Mar  1 01:09:35.175: IP(0): IP tos=0x0, len=100, id=126, ttl=254, prot=1
    *Mar  1 01:09:35.175: IP(0): s=1.1.1.1 (FastEthernet0/0) d=225.5.5.5 (FastEthernet2/0) id=126, ttl=254, prot=1, len=100(100), mforward
    R2#
    *Mar  1 01:09:37.231: IP(0): MAC sa=cc00.1f60.0000 (FastEthernet0/0), IP last-hop=12.12.12.1
    *Mar  1 01:09:37.231: IP(0): IP tos=0x0, len=100, id=127, ttl=254, prot=1
    *Mar  1 01:09:37.231: IP(0): s=1.1.1.1 (FastEthernet0/0) d=225.5.5.5 (FastEthernet2/0) id=127, ttl=254, prot=1, len=100(100), mforward
    R2#
    *Mar  1 01:09:39.215: IP(0): MAC sa=cc00.1f60.0000 (FastEthernet0/0), IP last-hop=12.12.12.1
    *Mar  1 01:09:39.215: IP(0): IP tos=0x0, len=100, id=128, ttl=254, prot=1
    *Mar  1 01:09:39.215: IP(0): s=1.1.1.1 (FastEthernet0/0) d=225.5.5.5 (FastEthernet2/0) id=128, ttl=254, prot=1, len=100(100), mforward
    R2#
    *Mar  1 01:09:41.191: IP(0): MAC sa=cc00.1f60.0000 (FastEthernet0/0), IP last-hop=12.12.12.1
    *Mar  1 01:09:41.191: IP(0): IP tos=0x0, len=100, id=129, ttl=254, prot=1
    *Mar  1 01:09:41.191: IP(0): s=1.1.1.1 (FastEthernet0/0) d=225.5.5.5 (FastEthernet2/0) id=129, ttl=254, prot=1, len=100(100), mforward
    R2#
    *Mar  1 01:09:43.199: IP(0): MAC sa=cc00.1f60.0000 (FastEthernet0/0), IP last-hop=12.12.12.1
    *Mar  1 01:09:43.199: IP(0): IP tos=0x0, len=100, id=130, ttl=254, prot=1
    *Mar  1 01:09:43.199: IP(0): s=1.1.1.1 (FastEthernet0/0) d=225.5.5.5 (FastEthernet2/0) id=130, ttl=254, prot=1, len=100(100), mforward

    You can see all multicast packets are forwarding to fa2/0 inteface, which is connected to R4, so there is separate path for multicast:

    R1-R2-R4-R5 and unicast R1-R2-R3-R4-R5

    R1#mtrace 1.1.1.1 5.5.5.5 225.5.5.5
    Type escape sequence to abort.
    Mtrace from 1.1.1.1 to 5.5.5.5 via group 225.5.5.5
    From source (?) to destination (?)
    Querying full reverse path...
     0  5.5.5.5
    -1  45.45.45.5 PIM Prune sent upstream [1.1.1.1/32]
    -2  45.45.45.4 PIM  [1.1.1.1/32]
    -3  24.24.24.2 PIM Reached RP/Core [1.1.1.1/32]
    -4  12.12.12.1 PIM No route
    !

    R1#traceroute 5.5.5.5 so lo0

    Type escape sequence to abort.
    Tracing the route to 5.5.5.5

      1 12.12.12.2 16 msec 96 msec 40 msec
      2 23.23.23.3 64 msec 52 msec 68 msec
      3 34.34.34.4 52 msec 92 msec 72 msec
      4 45.45.45.5 96 msec *  148 msec

     

  • I understand what you mean but in both cases (BGP peering on 2.2.2.2-4.4.4.4) or 24.24.24.2-24.24.24.4, I can see all multicast packets are forwarded between R2 to R4 and unicast via R3 see the output of debug ip mpacket detail on R2:

    Why its working like that ?

    RP is R2'2 loopback. Is it correct? PIM is enabled on all interfaces. Is that correct?

    What are the outputs of these commands at R4 ?

    Show ip route 2.2.2.2 with recursion to outgoing interface

    Show ip route 1.1.1.1 with recursion to outgoing interface

    show ip mroute 225.5.5.5

  • RP is R2'2 loopback. Is it correct? PIM is enabled on all interfaces. Is that correct?

    No I am enabling PIM on fa2/0 (towards R4) only.

  • Thanks Narayan, Dcancerian and Brian for give example and discuss it. I think i got it now.

     

Sign In or Register to comment.