I am working on a project in which I need to analyse the rib-dumps from the Oregon Routeviews Project.
I download the .bz2 file from here for a specific time and date for a specific node. These files are generated every 2 hours.
Then I unzipped and parsed using a zebra parser.
In the end, I get a text file with almost a million entries in the following format
194.33.63.0/24 58511 8468 31493 31493
There are also a lot of entries with the same last number but different IP in the beginning.
For example
194.28.28.0/22 58511 31500 50911
194.28.28.0/23 58511 31133 50911
My inference is that these numbers are Autonomous System numbers and they somehow denote BGP Hops, but I am not clear how they relate to the IP address in the starting. And what exactly is the source/destination AS?
I really think you should go and do some reading on how BGP works and what the routeing information carried by the BGP messages you are looking at is and means.
To get you started...
...a route in BGP speak is a prefix and some attributes. Key among the attributes are the next-hop and the AS-Path. In announcing a route to a BGP peer (neighbour) the BGP router is saying that it can reach the prefix and if packets with destinations in the prefix are forwarded to the next-hop, they will be forwarded on towards their destination. The AS-PATH lists the ASes through which packets are (expected to) travel on their way to the destination.
So what you are seeing is reachable prefixes and the AS-PATH attribute for each one. I'm guessing you left out the next-hop (for eBGP, that will generally be the/an address of the BGP router which is advertising the route -- but in any case all eBGP routes will generally have the same next-hop).
The AS-PATH can be read from left to right: the first AS is the one from whom the route was learnt, the last AS is the one that contains the prefix. Packets forwarded to the next-hop are (currently) expected to travel through those ASes, in that order, on their way to their destination. So the first AS would be the source -- the immediate source of the route. The last AS can be called the destination, but is also known as the origin -- the origin of the route.
[Technically, the AS-Path should be read from right to left, and lists the ASes which the route has traversed this far. Most of the time that's the same as reading left to right for packets traversing the network towards their destination.]
as-50911 origin or destination,
as-58511 source
194.28.28.0/22 should be the owner of as-50911 origin
I think you are confused about /23 or /22. 194.28.28.0/23 its not different IP. Its actually the same IP with different prefix length, i.e., /23. The autonomous systems registered their IP addresses with prefix lengths in IRR. Less specific, i.e., /22 means more end node. More specific, i.e., /23 means less end node. Moreover, You should read about prefix length.
Related
When define a subnet, such as 1.2.3.0/24, it means 255 hosts in the subnet start from 1.2.3.0 to 1.2.3.255.
But what if I wrongly define the subnet with 1.2.3.64/24? Does it then mean the range is start from 1.2.3.64 to 1.2.3.255?
I could not find a formal document about this.
EDIT: in Java ipaddress lib (5.2.1), the 1.2.3.64/24 will be treated as range from 1.2.3.64 to 1.2.3.255, instead of 1.2.3.0 to 1.2.3.255!. The code is: new IPAddressString("1.2.3.64/24").getSequentialRange()
EDIT: My apology: the above description of ipaddress lib's behavior is wrong. It was other things that caused me think the the range become 1.2.3.64 to 1.2.3.255.
Indeed, the
new IPAddressString("1.2.3.64/24").getSequentialRange().getLower()
is 1.2.3.64,
and
new IPAddressString("1.2.3.64/24").getSequentialRange().getUpper()
is also 1.2.3.64,
so I think this is a reasonable implementation!. I have no problem of that.
The
new IPAddressString("1.2.3.64/24").getAddress().toPrefixBlock().getLower()`
will be the expect one: 1.2.3.0.
And the `.getUpper()` is 1.2.3.255.
so this is the perfect way to get correct ip range.
There is no formal specification indicating that setting the un-fixed bits (the host bits) to 0 is a convention. However, it is common practice when describing a subnet as opposed to a single address, that you leave the host bits as zero. It is an informal convention. If you are describing a subnet, why would you set those bits to anything other than zero if they are intended to be ignored? So that is what all network engineers and most other people do, they leave the bits as zero when they are describing the full subnet, when the host can take on any value.
The specification for something like 1.2.3.64/24 is that the network part of the address is the first 24 bits, and the host part of the address is the remaining 8 bits. So, the network is 1.2.3.0 and the host is 0.0.0.64. The specification says nothing else.
Likewise, 1.2.3.0/24 indicates the network is 1.2.3.0 and the host is 0.0.0.0. However, like I said, when the host is 0, that is commonly used to refer to the entire subnet, meaning the host can take on any value. When people write down a string for that subnet of 255 addresses, they will write 1.2.3.0/24.
In fact, it is unusual to see 1.2.3.0 used as a single address because many routers do not accept a host of 0.
How you parse those things is specific to any library. Some libraries parse 1.2.3.64/24 as the whole subnet, throwing out the 0.0.0.64. Some libraries parse 1.2.3.64/24 as 1.2.3.64. Some libraries have separate methods to do one or the other.
With the IPAddress library, the same parser parses both addresses and subnets. When it parses 1.2.3.64/24 or 1.2.3.0/24, the parser needs to decide what you mean by each. For the former, it interprets 1.2.3.64/24 as the address 1.2.3.64 with prefix length 24, because why else is the 0.0.0.64 there at all if you do not intend that 64 to mean something? Why throw it out?
For 1.2.3.0/24, it interprets that as the whole subnet, because, like I said, a host of 0 is commonly used to refer to the entire subnet, and it is rare to use 1.2.3.0 as an address.
However, if you wish to choose some other meaning when parsing those things, the library provides other options.
There is no formal specification for this. In fact, there is no formal specification for a lot of the different aspects of IP addressing, a lot of it is informal and simply evolved over the years to the common practices in use.
new IPAddressString("1.2.3.64/24").getSequentialRange() is parsed as the range "1.2.3.64 -> 1.2.3.64". Earlier versions of the library behaved differently, but that is how all the latest releases for the last few years parse it.
Disclaimer: I am the project manager of that library.
It's interesting because I too can't seem to find any formal specification on why setting the un-fixed bits to 0 is the convention. Looking at RFC 4632 says:
[Classless prefixes] make explicit which bits in a 32-bit IPv4
address are interpreted as the network number (or prefix) associated
with a site and which are the used to number individual end systems
within the site.
Even with the convention of setting the un-fixed bits to 0, you may have CIDR notation that has an IP ending in a non-zero number. For example: 192.168.1.254/31 which represents the range of IPs from 192.168.1.254 to 192.168.1.255.
CIDR notation only specifies the number of bits that are fixed, so even if you put .64 it would appear that the /24 still represents only 24 fixed bits of the IP address.
You can see that the CIDR Calculator from ARIN shows that 1.2.3.64/24 still represents all IP addresses from 1.2.3.0 to 1.2.3.255.
Screenshot here.
Now it may be that different systems are implemented to handle this situation differently, so I would personally follow the convention, but from the perspective of CIDR notation (and what I can seem to find in the RFC) it should still represent the entire range.
Suppose we have a condition in AODV protocol
RREQ(route request) packet in AODV(MANET protocol) goes on moving to the destination even if a node at TTL=1 has replied for the route request.For example,n1,n2 and n3 are 3 nodes at TTL=1 and n2 replies to source S but n1 and n3 have rebroadcasted the RREQ packet towards destination D which would perhaps create unnecessary flooding in the network . Now I thought a naive solution to minimize this flooding that n2 will also broadcast another packet containing information that it has replied to the RREQ for S to D probably using something like a higher Destination sequence number in it or containing the same Broadcast ID as the RREQ. But what it will do is create another chance of flooding . So,are there any possible ways by which we could minimize this problem in a more effective manner?NOTE:AODV is a reactive routing protocol in Mobile Ad-Hoc network systems which rely on table routing .
This is a research topic. There are several solutions provided for the same. On of the efficient solution is provided as:
Source node starts broadcasting for the first time with a small TTL value of 1. This RREQ reaches adjacent nodes, they checks weather they contain an updated route for the destination. Those having an updated route for the destination replies with RREP and rest of the nodes can't rebroadcast because TTL is expired. If no one has the route, the RREQ is rebroadcasted by source with one increased value of TTL=2. This way, RREQ packet is rebroadcasted only when the nodes do not have path for the destination.
This method also increases flooding of RREQ packets but it is an optimization problem, still it is one of the good method to solve this problem.
Hope its clear now.
The Condition Of node in Aodv protocol is just check the receiving packet type, if its RREQ means just forward to all of its neighbours .if u want to minimize RREQ u can add your condition in Recvpacket() functions.better is u can use number of hops to create a new condition.
I'm trying to make a list of all MAC addresses that are reserved, do not exist, should not be used, should only be used locally etc. (Just like the list of reserved IP-addresses on Wikipedia, but for MAC.) Basically I want to loop over all MAC-addresses from a switch and filter out the "real" ones.
This page suggests all addresses starting with 00-00-5E or 01-00-5E are reserved, but when I look them up it seems like 00-00-5E is also assigned to the Information Sciences Institute (part of a university in California).
So 2 questions:
1) Is there any place I can find a list of reserved MAC-adresses?
2) What's up with 00-00-5E? Is only part of that range reserved, or is there some reason they assigned it to ISI?
I was just looking into this myself recently. I believe that the IANA (which you refer to in one of your links) will give the most authoritative answer: IANA Ethernet Number Assignments
I don't think that this means that these addresses can never be used though. According to RFC5342, Section 2.1
"The 2**8 unicast identifiers from 00-00-5E-00-00-00 through 00-00-5E-00-00-FF are reserved and require IESG Ratification for allocation (see Section 5.1)."
So basically, it appears you need special permission from IESG (Internet Engineering Steering Group) to get an address in that range, which I suppose the ISI has obtained somehow.
Section 2.1 of RFC5342 deals with 48-Bit MAC Identifiers and OUIs, and it doesn't make any mention of any address ranges that are strictly forbidden or permanently reserved from what I've understood.
The following OUI are reserved as per RFC 5342:
OUI 01:00:5E:(00:00:00-7f:ff:ff) - Used for IPV4 Multicast and MLPS Multicast.
OUI 00:00:5E:(00:01:00 – 00:01:FF) - Used for Virtual Router Redundancy Protocol (VRRP) IPV4
OUI 00:00:5E:(00:02:00 – 00:02:FF) - Used for Virtual Router Redundancy Protocol (VRRP) IPV6
OUI 33:33:00 – 33:33:FF - Reserved for IPV6 Multicast
OUI CF:00:00 – CF:FF:FF - Reserved by IANA for PPP(Point to Point Protocol)
OUI 00:00:5E (00:00:00 - 00:00:FF) - Requires IESG Ratification for allocation.
Was looking into this myself.. I know it's been a while since the post was active.. but I found these to be ok to use locally:
x2-xx-xx-xx-xx-xx
x6-xx-xx-xx-xx-xx
xA-xx-xx-xx-xx-xx
xE-xx-xx-xx-xx-xx
Source: https://honeywellaidc.force.com/supportppr/s/article/Locally-Administered-MAC-addresses
The registration authority for MAC addresses is the IEEE. It hands out OUIs (Organizationally Unique Identifiers), which give you a three byte prefix, and 2^24 addresses within it, for a fee (currently 2 995USD). You also get the rights to the corresponding multicasts, which have the prefix with the lowest bit of the first byte set. For instance, 00:80:C2 is allocated to the IEEE 802.1 committee, which uses 01:08:C2:00:00:00 for Spanning tree.
So, there isn't really a list of reserved addresses. There is a list of OUIs that have been allocated, unless the buyer has paid (a lot) extra for privacy. You can use any address that has the local bit set freely. A tiny fraction of multicast addresses have a significant meaning because heavyweights like IEEE, Cisco, IANA assign meanings to them. From the IEEE registration point of view, there is no particular significance to these blocks (except possibly to those it has allocated to itself).
Now, how did the 01-00-5E range end up allocated to the Information Sciences Institute? The simple
answer is that they paid for it. So, really the question should be 'how did the Internet get to use part of the range allocated to ISI?'. The answer is that the IANA used to be run from an office in ISI: specifically IANA was the legendary Jon Postel
Bottom line: you are on a bit of a fool's errand. You can distinguish local addresses and multicast addresses, and make some attempt to tie up allocated unicast addresses to vendor blocks. And you can probably do a bit more with well-known multicast addresses but only by tracking down individudal vendor's documentation (IANA is obviously an important one but only definitive for 1 of the 2^22 available blocks). One of the best places to start is probably the Wireshark codebase.
I read them from the COMPUTER NETWORKs. but i cannot tell from them.
Do they refer the same thing?
point-to-point links means source and destination module (may be through some intermediate machine)
see from the words, it means one point and another.(Just two point)
So, it seems the same meaning with Unicasting.
What's the difference?
Unicasting is a transport-layer action that happens over a link.
When I use traceroute, I often see abbreviations in the hostnames along the route, such as "ge", "so", "ic", "gw", "bb" etc. I can guess "bb" means backbone.
Does anyone know what any these strings abbreviate, or know any other common abbreviations?
These are ISO-3166-1 Alpha2 geographical domain id's converted to lower case.
ge - Georgia
gw - Guinea-Bisseau
so - Somalia
bb - Barbados
ic - old code for Iceland?
Just look for ISO-3166 for the complete list of country codes. And RFC 1700 for the geo domain list.
Can you please provide the output from one of your traceroutes?
Hostnames using components such as bb for backbone and gw for gateway tend to put those towards the start of a hostname, e.g. bb1.toto.com.au or gw2.wtf.co.uk.
This follows a naming convention of more specfic to less specific elements in the name as you traverse from left to right.
Geographical domains are, almost always, at the end of the hostname.
The examples you provided makes me think it's not about country codes.
I guess it's just what you thought: ISP network admins using shorcut when naming their servers.
bb = backbone
gw = gateway
ic = interconnect?
ge = ?
so = stackoverflow? :)
They're unlikely to be country codes. When you're in charge of a large scale network, you come up with naming schemes that make sense to you, mixing geographical and functional notations, but without being too verbose since it's too wasteful to type.
gw, for example, always stands for gateway. ge typically means "gateway external", i.e. a border gateway to a "friendly" network. ix stands for interchange.
Unless they are the top level domain name (eg "foo.bb" rather than "bb.example.net"), then they are choosen by the organisation that owns that domain name, remember if you own a domain name, you own all subdomains. In that case, you can call it whatever you want. There's no specification and people call it many different things.
There are many 2 level top level domains, one for each country. E.g. .fr for France. More info: http://en.wikipedia.org/wiki/CcTLD
Short version; Country codes
Likely not totally correct, but...
A comlete listing of country codes is at
http://www.iso.org/iso/country_codes/iso_3166_code_lists/english_country_names_and_code_elements.htm
Other Top Level Domains (TLD) are at:
http://www.icann.org/en/registries/listing.html
actually, "ge" most likely stands for "Gigabit Ethernet", and it's quite common for the ports on routers to be named after the interface name.
Hence the first Gig-E port on a router will quite often have a hostname that includes "ge0" or similar.
You'll also see:
"fa" for "Fast Ethernet" (on Cisco routers)
"s0" for "Serial" (i.e. E1 or T1 ports)
"lo0" for "Loopback"
so = sonet, pos = packet over sonet
xe= ten gigabit
ge= gigabit