unicast to multicast conversion?

Discussion in 'Cisco' started by vt, Feb 10, 2005.

  1. vt

    vt Guest

    Hi,
    I have an important device residing outside my network (which is out of my
    control) that sends a UDP stream of data to a unicast address in my network.
    Problem is, there are multiple hosts in my network and neighbouring internal
    networks that are interested in this UDP stream.
    Multicast jumps to my mind in this scenario but problem is I have no control
    on the external device to have it send to a multicast address.

    Is there a way that I can convert the unicast destination address to
    multicast address, and then have the hosts interested in the traffic as part
    of a multicast group? I have tried NAT to translate unicast to multicast,
    but doesn't seem to work.

    TIA for any suggestions.
     
    vt, Feb 10, 2005
    #1
    1. Advertising

  2. vt

    Guest

    Cisco routers only have the ability to convert broadcast to multicast
    (the ip multicast helper-map command).


    Take a look at VideoLAN software: http://www.videolan.org/streaming/

    Depending on your requirements, you might be able to take the unicast
    traffic into a VideoLAN server and then resend using multicast.
     
    , Feb 10, 2005
    #2
    1. Advertising

  3. vt

    Ivan Ostreš Guest

    In article <cuf0bg$a2k$>,
    says...
    > Is there a way that I can convert the unicast destination address to
    > multicast address, and then have the hosts interested in the traffic as part
    > of a multicast group? I have tried NAT to translate unicast to multicast,
    > but doesn't seem to work.
    >


    Yes, it can be done that way (NAT). When I get access to my lab, I will
    try it out. Can you please post your configs when trying to implement it
    trough nat?


    --
    -Ivan.

    *** Use Rot13 to see my eMail address ***
     
    Ivan Ostreš, Feb 10, 2005
    #3
  4. vt

    vt Guest

    <snip>

    ip multicast routing

    !
    interface FastEthernet1/1
    no switchport
    ip address 10.100.1.254 255.255.255.0
    ip nat inside
    ip virtual-reassembly
    no cdp enable
    ip pim dense-mode
    !

    !
    interface FastEthernet1/4
    no switchport
    ip address 10.100.254.1 255.255.255.252
    ip nat outside
    ip virtual-reassembly
    no cdp enable
    ip pim dense-mode
    !

    !
    interface FastEthernet1/5
    no switchport
    ip address 10.100.254.5 255.255.255.252
    ip nat outside
    ip virtual-reassembly
    no cdp enable
    ip pim dense-mode
    !

    ip nat inside source static 10.100.1.9 233.0.0.1 -----> unidirectional
    UDP stream (src:192.168.14.120, dst:10.100.1.9) always travel from fa1/4 to
    fa1/1
    ip nat inside source static 10.100.1.10 233.0.0.2 -----> unidirectional UDP
    stream (src:192.168.14.120, dst:10.100.1.10) always travel from fa1/5 to
    fa1/1. (note: same source address, but actually from a
    totally different network to which the first UDP stream originates)

    ip nat outside source list 100 pool mypool
    ip nat pool mypool 193.168.14.120 193.168.14.120 netmask 255.255.255.0
    ip access-list 100 permit ip host 192.168.14.120 host
    ----> this is to translate one of the UDP stream from
    src:192.168.14.120 to 193.168.14.120 to differentiate the source.

    <snip>




    "Ivan Ostres" <> wrote in message
    news:...
    > In article <cuf0bg$a2k$>,
    > says...
    >> Is there a way that I can convert the unicast destination address to
    >> multicast address, and then have the hosts interested in the traffic as
    >> part
    >> of a multicast group? I have tried NAT to translate unicast to multicast,
    >> but doesn't seem to work.
    >>

    >
    > Yes, it can be done that way (NAT). When I get access to my lab, I will
    > try it out. Can you please post your configs when trying to implement it
    > trough nat?
    >
    >
    > --
    > -Ivan.
    >
    > *** Use Rot13 to see my eMail address ***
     
    vt, Feb 10, 2005
    #4
  5. vt

    Ivan Ostreš Guest

    In article <cuglvo$jsp$>,
    says...
    >
    > ip nat inside source static 10.100.1.9 233.0.0.1 -----> unidirectional
    > UDP stream (src:192.168.14.120, dst:10.100.1.9) always travel from fa1/4 to
    > fa1/1
    > ip nat inside source static 10.100.1.10 233.0.0.2 -----> unidirectional UDP
    > stream (src:192.168.14.120, dst:10.100.1.10) always travel from fa1/5 to
    > fa1/1. (note: same source address, but actually from a
    > totally different network to which the first UDP stream originates)
    >


    If flow goes from Fa1/4 -> Fa1/1 (s:192.168.14.120/d:10.100.1.9) you
    should do the following:

    int fa1/4
    ip nat inside

    int fa1/1
    ip nat outside

    ip nat outside source static 233.0.0.1 10.100.1.9 extendable

    For Fa1/5 -> Fa1/1 (s:192.168.14.120/d:10.100.1.10):

    ip nat outside source static 233.0.0.2 10.100.1.10 extendable


    Flows are different (S,G) pairs, so there's no really need to translate
    source ip address.

    --
    -Ivan.

    *** Use Rot13 to see my eMail address ***
     
    Ivan Ostreš, Feb 11, 2005
    #5
  6. vt

    Ivan Ostreš Guest

    In article <>,
    says...
    > In article <cuglvo$jsp$>,
    > says...
    > >
    > > ip nat inside source static 10.100.1.9 233.0.0.1 -----> unidirectional
    > > UDP stream (src:192.168.14.120, dst:10.100.1.9) always travel from fa1/4 to
    > > fa1/1
    > > ip nat inside source static 10.100.1.10 233.0.0.2 -----> unidirectional UDP
    > > stream (src:192.168.14.120, dst:10.100.1.10) always travel from fa1/5 to
    > > fa1/1. (note: same source address, but actually from a
    > > totally different network to which the first UDP stream originates)
    > >

    >
    > If flow goes from Fa1/4 -> Fa1/1 (s:192.168.14.120/d:10.100.1.9) you
    > should do the following:
    >
    > int fa1/4
    > ip nat inside
    >
    > int fa1/1
    > ip nat outside
    >


    and, of course:

    int fa1/5
    ip nat inside

    You can watch translations by using 'debug ip nat translation'. It is
    not recommended to do that if you have high volume traffic or many nat
    translations because it could burden the switch's cpu and add additional
    problems.


    Regards,

    --
    -Ivan.

    *** Use Rot13 to see my eMail address ***
     
    Ivan Ostreš, Feb 11, 2005
    #6
  7. vt

    vt Guest

    Thanks Ivan.
    From your suggestion which uses static translations, it won't work for other
    flows.

    I have:
    SNMP traps (UDP) from Fa1/4 -> Fa1/1 (s: 192.168.14.10/d:10.100.1.1)
    and
    SNMP traps (UDP) from Fa1/5 -> Fa1/1 (s: 192.168.14.10/d:10.100.1.1)

    The reason I want to translate the source 192.168.14.10 to 193.168.14.10 is
    so that the SNMP traps are differentiated from the two identical source
    addresses.

    Any suggestion to take this into account?



    "Ivan Ostres" <> wrote in message
    news:...
    > In article <>,
    > says...
    >> In article <cuglvo$jsp$>,
    >> says...
    >> >
    >> > ip nat inside source static 10.100.1.9 233.0.0.1 ----->
    >> > unidirectional
    >> > UDP stream (src:192.168.14.120, dst:10.100.1.9) always travel from
    >> > fa1/4 to
    >> > fa1/1
    >> > ip nat inside source static 10.100.1.10 233.0.0.2 ----->
    >> > unidirectional UDP
    >> > stream (src:192.168.14.120, dst:10.100.1.10) always travel from fa1/5
    >> > to
    >> > fa1/1. (note: same source address, but actually from a
    >> > totally different network to which the first UDP stream originates)
    >> >

    >>
    >> If flow goes from Fa1/4 -> Fa1/1 (s:192.168.14.120/d:10.100.1.9) you
    >> should do the following:
    >>
    >> int fa1/4
    >> ip nat inside
    >>
    >> int fa1/1
    >> ip nat outside
    >>

    >
    > and, of course:
    >
    > int fa1/5
    > ip nat inside
    >
    > You can watch translations by using 'debug ip nat translation'. It is
    > not recommended to do that if you have high volume traffic or many nat
    > translations because it could burden the switch's cpu and add additional
    > problems.
    >
    >
    > Regards,
    >
    > --
    > -Ivan.
    >
    > *** Use Rot13 to see my eMail address ***
     
    vt, Feb 14, 2005
    #7
  8. vt

    Ivan Ostreš Guest

    In article <>,
    says...
    > Thanks Ivan.
    > From your suggestion which uses static translations, it won't work for other
    > flows.
    >


    True. It will give you a control what will and what won't be translated.
    It seems as a fair thing to do....

    > I have:
    > SNMP traps (UDP) from Fa1/4 -> Fa1/1 (s: 192.168.14.10/d:10.100.1.1)
    > and
    > SNMP traps (UDP) from Fa1/5 -> Fa1/1 (s: 192.168.14.10/d:10.100.1.1)
    >
    > The reason I want to translate the source 192.168.14.10 to 193.168.14.10 is
    > so that the SNMP traps are differentiated from the two identical source
    > addresses.
    >
    > Any suggestion to take this into account?
    >


    Didn't know at the moment that SNMP traps are in question. I don't think
    you could really control source translation (the way you want it) with
    just a simple NAT. You could probably do it by using policy NAT
    (www.cisco.com).

    The bigger problem I see here is that you have two hosts on the same
    routing domain with the same IP address which is not really a good
    thing. I can remember just one situation where this could be ok, and
    that is clustering a server but then you should send snmp traps from
    member addresses...

    --
    -Ivan.

    *** Use Rot13 to see my eMail address ***
     
    Ivan Ostreš, Feb 14, 2005
    #8
  9. vt

    Ivan Ostreš Guest

    In article <>,
    says...
    >
    > Didn't know at the moment that SNMP traps are in question. I don't think
    > you could really control source translation (the way you want it) with
    > just a simple NAT. You could probably do it by using policy NAT
    > (www.cisco.com).
    >


    http://www.cisco.com/warp/public/105/nat_routemap.html

    --
    -Ivan.

    *** Use Rot13 to see my eMail address ***
     
    Ivan Ostreš, Feb 14, 2005
    #9
  10. vt

    vt Guest

    Thanks for all your helpful replies and insights, Ivan.


    "Ivan Ostres" <> wrote in message
    news:...
    > In article <>,
    > says...
    >>
    >> Didn't know at the moment that SNMP traps are in question. I don't think
    >> you could really control source translation (the way you want it) with
    >> just a simple NAT. You could probably do it by using policy NAT
    >> (www.cisco.com).
    >>

    >
    > http://www.cisco.com/warp/public/105/nat_routemap.html
    >
    > --
    > -Ivan.
    >
    > *** Use Rot13 to see my eMail address ***
     
    vt, Feb 14, 2005
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Peter Boutzev

    Catalyst 3524 unicast flooding

    Peter Boutzev, Feb 21, 2004, in forum: Cisco
    Replies:
    1
    Views:
    3,218
    Peter Boutzev
    Feb 23, 2004
  2. Nikolai Schupbach
    Replies:
    0
    Views:
    3,183
    Nikolai Schupbach
    Feb 23, 2004
  3. Brad
    Replies:
    3
    Views:
    1,518
  4. Ned
    Replies:
    3
    Views:
    2,188
    Martin Bilgrav
    May 10, 2007
  5. dano
    Replies:
    1
    Views:
    1,262
    Omadon
    Nov 24, 2008
Loading...

Share This Page