As mentioned in perlsub, parameters passed into a subroutine are passed as a flat list. From the subroutine's perspective, it's impossible to determine where @VRF_names ends, and @spines_ip begins. It's all just a flat list of values.

You want to pass in a reference to an array:

sub BuildLeaf {
    my (
        $hostname,       $lo_add,        $ospf_process,
        $ospf_area,      $bgp_as,        $bgp_pass,
        $VRF_names_aref, $spines_ip_aref
    ) = @_;
    # Do your stuff here.
}
[download]

And then in the sub call, change @{$vrf_info[0]} and @{$spine_info[1]} to $vrf_info[0] and $spine_info[1]. Within the subroutine, you will need to dereference the array-refs appropriately. See perlref and perlreftut for details. We can't really guess how you might be using the passed-in arrays without seeing the code, so it would be impractical for us to demonstrate the appropriate array-ref dereferencing for your particular use case. But the documentation is good, although possibly a bit opaque on first read. The online book Modern Perl would probably offer a gentler introduction to wielding references.

As an example, this is one possible way to pass array references to a sub and to use them within the sub.

my @a = (1, 2, 3);
my @b = (5 .. 7);
process(\@a, \@b); # pass array references to the sub

sub process {
    my ($a1ref, $a2ref); # retrieve the params
    my @array1 = @{$a1ref); # dereference $a1ref inti an array
    my @array2 = @{$a2ref);
    # ... process @array1 and @array2
    # ...
}
[download]

I like named params

mysub({ a1 => \@array1, a2 => \@array2 });

sub mysub{
   my ( $argref ) = @_;  # brackets matter

   # ref to @array1 is @{ $argref->{a1} }
   # ref to @array2 is @{ $argref->{a2} }
[download]

I always used to accept my params within a hashref, but in the last year or so, I've changed to just using a straight up hash instead. I feel it makes the interface a tiny bit cleaner:

mysub(a => \@array1, b => \@array2);

sub mysub {
    my %params = @_;
    print "$_\n" for @{ $params{a} };
}
[download]

BuildLeaf ($leaf_info[0][[$i]],$leaf_info[[1]][[$i]], ...);

This may be just a cut-and-paste problem in posting the OP, but the array indexing used in the example code is doubleplusungood.

An expression like  [1] or  [$i] on its own builds an anonymous array and evaluates as the reference address of the array; this reference address is the only way to access the array, hence "anonymous". A reference address evaluated in numeric context is some (probably rather large) number. The expression  $leaf_info[0][[$i]] evaluates the anonymous array reference returned by  [$i] in the numeric context of an array element index and immediately expands the array  @leaf_info (or to be precise, the anonymous array that is the zeroth element of @leaf_info) to include the indexed array element. (Update: Well, not quite. See Update 2 below.) I doubt this is what you want. E.g.:

c:\@Work\Perl\monks>perl -wMstrict -le
"my @ra;
 ;;
 $ra[3] = 42;
 print 'A: elements in array: ', scalar @ra;
 ;;
 $ra[[1]] = 99;
 print 'B: elements in array: ', scalar @ra;
"
A: elements in array: 4
Use of reference "ARRAY(0x5cc15c)" as array index at -e line 1.
B: elements in array: 6078813
[download]

Update:

BuildLeaf (...,@{@vrf_info[0]},@{@spine_info[[1]]});

Update 2: My code example above shows changes to the array produced by write accesses; the OPed code showed pure read accesses, and these produce different effects:

c:\@Work\Perl\monks>perl -wMstrict -le
"my @ra;
 my $x;
 ;;
 S($ra[3]);
 print 'A: elements in array: ', scalar @ra;
 ;;
 S($ra[[1]][[0]]);
 print 'B: elements in top level array: ', scalar @ra;
 print 'C: elements in 2nd level array: ', scalar @{ $ra[-1] };
 ;;
 sub S { $x = defined($_[0]) . ''; }
"
A: elements in array: 0
Use of reference "ARRAY(0x94c05c)" as array index at -e line 1.
Use of reference "ARRAY(0x432004)" as array index at -e line 1.
B: elements in top level array: 9748573
C: elements in 2nd level array: 0
[download]