2013-04-03 12:05 PM
Has anyone had any experience creating a custom feed based around IPv6 addresses?
Specifically, I want to do something very similar to what is in the examples that show how to create department listings using IP ranges, I just want to set up a similar feed using our IPv6 ranges. A couple of the methods that I have used have failed, and I am not sure if it is in how I am structuring the XML file, or if it is a format issue in the CSV file in how I am listing the IPv6 ranges.
Any ideas?
Thanks
2013-04-17 09:35 AM
I just received the following response from support:
I learned from Dev currently range lookups are only supported with IPV4. Support for IPV6 is being added to IP Feeds in version 10.2 which is due out in a few weeks.
2013-04-03 06:33 PM
Upload your CSV and we'll take a look to see if we can spot the problem.
2013-04-03 08:39 PM
These are just examples, but basically my CSV looks like:
2001:0db8:85a3:0042::/64,Dept 1
2001:0db8:85a3:0043::/64,Dept 2
2001:0db8:85a3:0044::/64,Dept 3
2001:0db8:85a3:0045::/64,Dept 4
2001:0db8:85a3:0046::/64,Dept 5
My XML looks something like this:
<FDF>
<FlatFileFeed name="IPv6 Source Dept Listing" path="dept_list_ipv6.csv" separator="," comment="#">
<MetaCallback name="dept source" valuetype="IPv6">
<Meta name="ipv6.src"/>
</MetaCallback>
<LanguageKeys>
<LanguageKey name="deptipv6.src" valuetype="Text"/>
</LanguageKeys>
<Fields>
<Field index="1" type="index" range="cidr"/>
<Field index="2" type="value" key="deptipv6.src" />
</Fields>
</FlatFileFeed>
</FDF>
2013-04-03 09:27 PM
First of all, do you have a meta key in your index for deptipv6.src and .dst?
Second I've not done a feed with ipv6 before, and I'm not certain that CIDR would apply.
To keep it simple, use ranges. Here is a sample XML that could use low and high ranges. The trick will be to define the boundary IP addies in your csv.
<FlatFileFeed name="NetName" path="acmenetworks.txt" separator=","
comment="#">
<LanguageKeys>
<LanguageKey name="netname" valuetype="Text"
srcname="netname.src" destname="netname.dst" />
</LanguageKeys>
<Fields>
<Field index="1" type="index" range="low"/>
<Field index="2" type="index" range="high"/>
<Field index="3" type="value" key="netname"/>
</Fields>
</FlatFileFeed>
Note in this example it calls for a netname keys for your index, but you can change that to your deptipv6 key instead.
Give this a try and let me know if you are successful.
2013-04-04 05:05 AM
The "System Administration Guide Version 9.8", pages 232 says on IPv6 addresses: "Does not support CIDR notation". The guide is from July 2012, but the statement probably still holds.
However, the template of Fielder doesn't work either. It seems like the attribute "range" requires IPv4 addresses. If I try to compile the feed with IPv6 ranges, I get the following output:
Creating feed IPv6 Source Dept Listing...
done. 0 entries, 4 invalid records
All feeds complete.
2013-04-04 07:18 AM
Thank you both. I am farther than I was yesterday.
Fielder, I tried that XML and updated my csv to use ranges:
2001:0db8:85a3:0042:0000:0000:0000:0000,2001:0db8:85a3:0042:ffff:ffff:ffff:ffff,Dept 1
2001:0db8:85a3:0043:0000:0000:0000:0000,2001:0db8:85a3:0043:ffff:ffff:ffff:ffff,Dept 2
etc,
And I got the same error that Johannes is getting.
The thought behind my original XML I posted above was that I needed to define in the feed that I wanted to look at ipv6 addresses. I didn't think SA/NW would understand that the indexes were "ip's" like it does with v4 addresses.
Once I got the failure fure from the xml above, I tweaked my original to look like this:
<FDF>
<FlatFileFeed name="IPv6DeptList" path="dept_listing_ipv6.csv" separator="," comment="#">
<MetaCallback name="IPv6 Source Address" valuetype="IPv6">
<Meta name='ipv6.src'/>
</MetaCallback>
<LanguageKeys>
<LanguageKey name="ipv6dept.src" valuetype="Text" />
</LanguageKeys>
<Fields>
<Field index="1" type="index" range="low"/>
<Field index="2" type="index" range="high"/>
<Field index="3" type="value" key="ipv6dept.src"/>
</Fields>
</FlatFileFeed>
</FDF>
Once I did that and retried creating the feed, it accepted all of my entries (minus 1, but I think I know why).
Haven't checked to see if its "working" yet, but this is farther than I have gotten before.
So if this works, my next question is, how would the MetaCallback along with my new ipv6dept key name, and then specify ipv6dept.src and ipv6dept.dst in the same file, instead of having to call them out in separate feeds? If that isn't possible when using the MetaCallback, thats fine. Still just looking to create the feed as efficiently as possible.
2013-04-04 08:09 AM
Since its IP v6, I don't think you need a metacallback. And like in my example above, you simply specify a language key of ipv6dept. You use two index keys of ipv6dept.src and dept.dst.
In the example I posted above this would create meta in two keys- both src and dst. No need for two feeds
2013-04-04 08:24 AM
Hmm, then I am not sure why it will not accept the entries in the csv when I use your method. Format issue in the csv somehow?
I didn't change the csv when I created the metacallback version, but all of my entries were invalid otherwise. I did try using the valuetypes of Text, as well as IPv6.
2013-04-04 09:47 AM
I did a couple of tests with Investigator 9.7.5.9 and the the compiler of 9.8.5.5:
Here's a working feed-definitions.xml based on the feed of aebay:
<FDF>
<FlatFileFeed name="IPv6DeptList" path="dept_list_ipv6.csv" separator="," comment="#">
<MetaCallback name="meta" valuetype="IPv6">
<Meta name='ipv6.src'/>
<Meta name='ipv6.dst'/>
</MetaCallback>
<LanguageKeys>
<LanguageKey name="ipv6dept" valuetype="Text" srcname="ipv6dept.src" destname="ipv6dept.dst" />
</LanguageKeys>
<Fields>
<Field index="1" type="index" range="low"/>
<Field index="2" type="index" range="high"/>
<Field index="3" type="value" key="ipv6dept"/>
</Fields>
</FlatFileFeed>
</FDF>
2013-04-04 03:21 PM
Thanks Johannes! Just made that change, and will be watching for that key to start populating. Still new to feed writing, and wasn't sure how to tackle more than one Meta field.
I'll post again if I have any issues, but that looks like the solution right now.
Thanks again all,
-A