Are you sure there is anything in $content? One way to check would be to use the debugger.

Update: as a general thing, simultaneous read and write access to a file gets messy. Also, not sure, but your use of DATA as the file handle might be causing trouble as well; it's a special word.

use strict;
use warnings;

open my $fh,'>>','logname' or die "Could not open logname";
while (1) {
  my $content = $rh->cmd(...);
  if (defined $content) {
    print $fh $content
  } else {
    print 'Nothing to be done!'
  }
  sleep 1;
}
close $fh;
[download]

Adding use strict; use warnings; would have pointed this out to you btw.

Having worked quite a bit with Juniper devices myself, I used Net::Telnet::Cisco but had to customize the "prompt" setting in order to get ->cmd() to work as expected. If you are using that module and didn't set the appropriate "prompt" setting, then ->cmd() will hang indefinitely while waiting for a Cisco command prompt, which is a little different.

I know I'm guessing a lot here, but I hope it helps. FYI, here's how I do it with MX, EX and SRX series -- seems to work pretty well:
@lines = $session->cmd( String => 'show version | no-more', Prompt => '/\n\S+\>/');

Putting it all together, try this:

use strict;
use warnings;

# Open your $rh and authenticate here
# ...

open(my $fh, "+>>default_ve.txt") || die "Couldn't open file: $!";
my @lines = $rh->cmd(String => 'show version | no-more', Prompt => '/\
+n\S+\>/');
foreach my $line (@lines) {
  print $fh $line;
}
close $fh;

# Close $rh or do more stuff here
# ...
[download]

Finally, note the use of "| no-more" to safeguard against output longer than your (virtual) terminal size which would cause an interactive prompt. Use it always, just to be safe.

If you're not using a Juniper device, read the stuff about the loop and disregard everything else :o)

Other observations which are likely unrelated to your problem:

• It looks like you have an infinite loop. How does your code break out of the while loop?
• DATA is typically reserved for use with __DATA__: Special Literals
• Basic debugging checklist

As GotToBTru said, it's probable $content doesn't contain anything. Isn't there a way to check if the command failed with whatever module you're using?

Though here the problem probably isn't with the file, it can happen, and you can get that kind of information by checking the return value of print: print DATA $content or die "Couldn't write to file: $!";

Perl may be buffering your output. Setting autoflush to unbuffer output is discussed as a faq here: perlfaq5 / How do I flush/unbuffer an output filehandle? Why must I do this?. That said, please also carefully consider the other suggestions in this thread.