what's the difference between point-to-point links and unicasting? - networking

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.

Related

Understanding format of RIB dumps from Oregon Route-views

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.

Malformed Action frames in ns-3 mesh network simulation

I have built a simulation model of the IEEE 802.11s based mesh network in ns-3 version ns3.28. The network consists of one moving node moving randomly and three static nodes. The pcap file generated from the model when viewed in Wireshark shows malformed Action frames.
I have attached the picture below. The same is the case for beacon frames. Can anyone describe why are these packets malformed?
I don't know how to fix it in the code but I think I know whats going on. The header is supposed to be a IE_MESH_PEERING_MANAGEMENT (117) with sub-type PEER_CLOSE (3) and Tag length 7 (see here). The reason for close is set to REASON11S_MESH_CONFIRM_TIMEOUT (57).
Somehow it was serialized in the wrong order. You should open a bug with ns3 for them to fix this.

NAT64 embedded formats used by actual phone carriers

I'm refactoring some of my network code due to Apple's guidelines to support full IPv6 networks, and they state one reason for this is that carriers are starting to make the conversion.
When I test with Apple's NAT64 network, I see IPv4 addresses coming in mapped to IPv6 in the form:
64:ff9b::xxxx:yyyy
Based on the NAT64 spec, it seems there are other possibilities, but I am not sure if these are ever used.
I'm hoping that I can just assume the above format, but I would like to know what NAT64 mapping styles other phone carriers are using.
EDIT: I omitted an important detail from my original question - that I need to do some filtering based on IPv4 ranges in certain scenarios. So I need to be able to convert IPv6 to IPv4 for the addresses where that is possible.
There are many ways. Don't assume anything. Query the DNS64 and use what you get. Everything else will break.

How do clients on wireless networks decide who can transmit at any given time?

I've been thinking about wireless networking a little bit recently, and I came upon a realization last night that I can't find an answer to: how do clients know when they can transmit and not stomp over another clients' transmission?
I assume there is documentation for this sort of thing available, but I've been unable to find anything useful over a half hour of casual Google queries, probably because I don't know the right terms. Apologies in advance if this is a silly question . . .
Here's why I'm confused: based on my understanding of how RF hardware works, we can model the transmission medium as a safe shared register between different RF clients (because what one client broadcasts can be overwritten by other clients and get a muddle between the two). But safe registers only have consensus number 1, so how can we establish who can transmit at any given point? I'm assuming that only one client can transmit at once -- perhaps this is my fundamental misunderstanding?
Even the use of a randomized consensus protocol seems unwieldy, because the only ones I know of use atomic registers, not safe registers, and also have no upper bound, so two identical devices with the same random seed would proceed for a very long time.
Thanks!
Please check: Carrier sense multiple access with collision avoidance

Avoiding switch loop

Will I have loop problems with this topology because S2 and S3 are both connected to S1 and s4 ?
Please check out this wikipage. It summarizes switching loops and the problem associated with them.
Obviously, to solve this issue you could just remove a link/ switch (S1 or S4) which forms the physical loop in the first place; although the result is you lose redundancy.
The ideal solution is to configure spanning tree protocol (STP) on these switches to dynamically block some interface(s) so that one active path exists between the two endpoints (PCs on S2 to PCs on S3) at any time. Note, with spanning tree configured you do not get load-balancing over the redundant link/ switch.
What you need is Spanning tree protocol, turn on this function in your switch.
It's a loop-free topology for any bridged Ethernet local area network.
This protocol will disables links that are not part of the spanning tree, leaving a single active path between any two network nodes.
We often use RSTP(802.1w) instead of STP(IEEE 802.1D), for the previous provides faster spanning tree convergence after a topology change.
If you use VLAN in your environment, you may choose MSTP(Multiple Spanning Tree Protocol).
In simple ring topology, u can use ring protocols too!
like G8032 (ERPS)
G8032 wiki
http://en.wikipedia.org/wiki/Ethernet_Ring_Protection_Switching
G8032 archive
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/cether/configuration/xe-3s/ce-xe-3s-book/ce-g8032-ering-pro.html

Resources