through my studies on CCNP ROUTE, while sniffing EIGRP packets, I noticed that packets have IP TTL of 2. I also verified this for RIP. OSPF doesn't have this property since it's link state.
Why does the EIGRP and RIP have IP TTL of 2?
I already asked one CCIE person, but he didn't know.
I came to believe that this may have something to do with frame relay hub&spoke topologies. For example hub routing EIGRP multicasts from one spoke to another (assuming subinterfaces)?
Any advice/idea/explanation would be greatly appreciated.
Thanks.
It permits spoke-to-spoke route advertisement using neighbor command. That's it.
Let's look at this simple hub&spoke frame relay topology:
R2
/
R1--
\
R3
with R1 being a hub (R2 and R3 don't have PVC between them).
R1's DLCI 102 to R2
R1's DLCI 103 to R3
R2's DLCI 201 to R1
R3's DLCI 301 to R1
I used physical/multipoint interfaces (subinterfaces) with one subnet:
R1 - 10.0.0.1/24
R2 - 10.0.0.2/24
R3 - 10.0.0.3/24
Working layer 3 connectivity between R1-R2 and R1-R3 is provided by frame relay inverse arp automatically. I used static mapping to make layer 3 work between R2 and R3 by mapping each other's IP address to DLCI to R1. (ex. frame-relay map ip 10.0.0.3 201 on R2).
This way there is full layer 3 connectivity.
Then I created loopback on R2 and R3 to announce one subnet and enabled EIGRP routing for those subnets. Next, I manually configured R2 to create neighbuorship with R3 IP on 10.0.0.0/24 subnet and vice versa.
And now the conclusion... R2 (or R3) sends EIGRP HELLO with IP TTL of 2, R1 gets this packet and notices that it's destination is on the same interface as it arrived in. This is generally solved by sending an ICMP redirect message, which got sent. Also the EIGRP HELLO is rerouted to the same interface (not switched!) and therefore gets it's TTL decreased.
TTL value of 2 is set on NBMA (Non-Broadcast Multi-Access) networks only.
NBMA is a special network with these features:
All Peers belong to the same IP subnet (broadcast domain).
Layer-2 connection has a hub-and-spoke (star) topology.
All communication between spokes will pass through hub, eventhough the
spokes belong to same IP subnet.
Examples of NBMA:
Framerelay.
DMVPN Hub-and-spoke.
In a normal LAN, all the peers can directly reach one another.Therefore, the TTL will be '1' for a normal LAN.
In NBMA, the TTL value must be increased to '2' to cater to the extra hop introduced by the hub router. Therefore, EIGRP uses TTL of '2' on NBMA networks.
Related
Hi I've been learning networks for a while now and I can't seem to find a solution for this doubt online.
I learnt that if you are sending a packet to a class B network's destination 141.49.255.255, it means you are broadcasting the packet to the whole class B network of 141.49.0.0; I also learnt that if you are sending a packet to a class A network's destination address like 10.255.255.255, you are again broadcasting the packet in the network ID 10.0.0.0
My question is, what am I doing when I'm sending a packet to class B 141.255.255.255 ? Am I sending it to a single host or a network?
Forget classes. Everything is being done in CIDR for the last two decades.
Sending to 141.255.255.255/16 is a subnet broadcast to 141.255.0.0/16. The same address may also be
141.255.255.255/8 - subnet broadcast to 141.0.0.0/8
141.255.255.255/6 - unicast(!) to the node 141.255.255.255
Most often, broadcasts are sent to 255.255.255.255. Routers (usually) don't forward broadcasts, so it's limited to the segment anyway.
However, there are some subtle differences: running e.g. 192.168.1.0/24 and 10.1.0.0/16 inside the very same Ethernet segment, a broadcast to 192.168.1.255/24 is physically sent to all nodes (Ethernet broadcast), even the ones with a 10.1.0.0/16 address. These however will the drop and ignore the packet since it doesn't address them.
In contrast, a broadcast to 255.255.255.255 will be sent to all nodes and processed by all nodes.
My question is pretty basic and my apologized for that. In TCP/IP network, if you take a look on layer 2 (Ethernet), we have some fields like Source and Destination MAC address. If you think in your browser, it is totally understandable that you can type a IP, and then the layer 3 (IP) will know the destination IP, then the frame is sent to layer 2.. However, how the layer two know the destination MAC address ? The source MAC address is stored in the network card and it is understandable but on what part of communication the destination MAC address will be known ?
I will give you the basic of how the routing works. This will clarify your doubts:
1) Assuming that we have a layer 3 IP packet which we want to send to some destination which have a DIP = y.
2) The route lookup in the routing table would give you the next hop and the outgoing interface through which the packet needs to go out.
3) Now we have the next hop. Still we dont have the layer 2 encap information which is the DMAC. Assuming this is the first packet we are sending and we dont have the DMAC vs next hop IP mapping yet.
4) The system will generate a ARP Query which will be broadcasted with a DMAC FF:FF:FF:FF:FF:FF within the subnet. This query asks who has the the next hop IP. (Remember we got this from the route lookup).
5) The router having the next hop IP would respond back to the src router (Unicast reply), thus we would know what is the DMAC that needs to be put on layer 2 header.
6) The L3 packet will now be encapsulated in layer 2 header with the dmac as already known now.
7) Remeber the dip won't change in the layer 3 header. This way the packet would traverse hop by hop. At each hop the layer 2 DMAC would change and not the DIP.
Remember that the MAC address identifies each router uniquely on a hop by hop basis.
Hope that clarifies your doubt.
Your computer determines the destination MAC address of the next hop is typically determined on an Ethernet network by using ARP, an Ethernet broadcast protocol that allows you to ask which device is assigned a particular IP address.
MAC address is resolved using layer-2 devices such as network switches. ARP tables is the tool to resolve IP to MAC.
# arp -an
I am familiar with the basic OSI model but I always get confused how does a packet travel from one machine to another over the Internet and what OSI layers do come into picture? For example, for the following topology:
Machine A<----->Switch<---->Router<---->Router<---->Router<---->Switch<---->Machine B
where the multiple routers are shown to represent the Internet, what happens at the OSI layer level, when Machine A send a packet (say a simple "ls" command over FTP) to Machine B.
The above is just a suggested example, but if any one can explain with any other network topology, that is fine too. All I am looking a very basic explanation of how the packet gets transformed to different OSI layers at each nodes (Machine, Switch, Router, etc.).
Routers use the IP layer (layer 3) and switches use the data-link layer (layer 2). Layer 1 is the physical 1s and 0s that go over a wire, Layer 2 is the data-link layer, which is protocols like Ethernet and Point-To-Point Protocol (PPP), which carries information between adjacent nodes about MAC address from and to and allows for error detection and retransmission. Layer 3 is the IP layer, which carries information about where in the whole network the packet is from and to, not just the current hop.
The transmission would go like this:
Machine A wants to send a packet to Machine B. Machine A knows Machine B's IP address, so it places that in the layer 3 packet. Machine A needs to place the MAC Address of the next hop in the layer 2 packet, however. If it does not know, then it will send something called an ARP request (Address Resolution Protocol, read here: http://www.tildefrugal.net/tech/arp.php ) to the network, with the destination IP. One of a few things will happen here:
The IP is local. The machine with that IP will reply back to the sender with its MAC address.
The IP is non-local. The gateway router will detect this and send its MAC address.
The IP is non-local and Machine A's default gateway and subnet mask are set. Using this information Machine A can determine the non-locality of the IP address and send it to the router's MAC address (ARPing if not known yet).
(If Machine A found this out earlier, it will be in the ARP cache and Machine A will just use that.) Now that the MAC address is sent, the packet can be transferred (the physical layer 1 performing the actual transfer of data on the wire). The next stop will be the switch. The switch knows which outbound port the MAC address listed as the layer 2 destination is on, because it tracks every MAC address it's seen a packet come from and which port it came on - if it does not know, then it will flood it out every single port, guaranteeing it'll arrive.
As such, the packet arrives at the router. The cool thing about the IP model is that it divides every single IP address in the network/world into a hierarchy - Subnets by definition cannot overlap subnets partially, they either wholly contain them or are wholly contained by them. So as long as subnets follow this hierarchy, the router can unambiguously determine where each of the 4 billion possible IP addresses are on the network just by looking at what subnet the IP will fall under in its table! The packet is then sent out that port.
As the packet travels through interconnected ISPs' routers, backbone infrastructure and so on, it arrives at Machine B's router, where the opposite process happens - router B sees that its destined for Machine B and sends it inbound. (Similarly, Router B will have to use a process like ARP to find Machine B's MAC address if not known.) The rest should be trivial from here.
good references:
https://web.archive.org/web/20120129120350/http://www.tildefrugal.net/tech/arp.php
http://en.wikipedia.org/wiki/Data_link_layer
http://en.wikipedia.org/wiki/Network_switch
http://en.wikipedia.org/wiki/Network_layer
http://en.wikipedia.org/wiki/Routing
http://en.wikipedia.org/wiki/Router_(computing)
http://en.wikipedia.org/wiki/Address_Resolution_Protocol
The only thing that can travel over a copper wire are pulses of electricity.
The binary number 1 is represented by a pulse of electricity or no pulse of electricity for 0.
Just keep in mind that real data of any kind cannot be sent over copper wire, fibre optic, or through the air ...only a representation of the data which has previously been converted to a 1 or a 0 and then is reconverted back at the receiving end.
Network layer protocol supervises the transmission of packets from a source machine to a destination. Data is broken down into packets, or datagrams, up to 64 kb long before it is transmitted, with a stamp of destination IP address, and forwarded to the network gateway. A gateway can be router to interconnect networks.
I'm doing some mobile project, that need to P2P communication with two devices.
And I faced with problem. (cause it's rare that smartphone have public ip)
I found some answers. It is 'UDP Hole Punching'.
I guess I understand about 'UDP Hole Punching' 100% conceptually, and write some codes.
But it doesn't work.
This is my situation.
Device A connected NAT(A) for Wi-Fi.
Device B connected NAT(B) for Wi-Fi.
NAT(A) and NAT(B) is different one.
Relay Server S bind socket and waiting for devices. (S is WebServer but Network Status is good.)
At the first, A and B send dummy packet to S. Then S save UniqueID(to tell A and B), Public IP, Port.
And S send information to each device A and B.
Like this:
- IP Address and Port Number about A. -> send to B
- IP Address and Port Number about B. -> send to A
Now A and B send UDP packet to other device based on information(IP Address and Port Number) from S.
(15 per second. using same socket that used server-device session)
But it's not working. (actually intermittently work. maybe once in 10 times? and I don't know why success and fail. there is no any tiny little common relation.)
I think it's not NAT Type problems. I tested South Korea and 90% NAT in South Korea is not Symmetric Cone.
Depending on the implementation of the NAT, it may not work at all. NAT hole punching requires, some special form of NAT implementation:
a) If the NAT recognizes UDP traffic it may (but some times does not) NAT-translate by changing the sender port number to some random port number (and changing the sender IP to the public IP address) and then redirects -for some limited period of time- incoming UDP traffic on that port back to the host behind the NAT (changing back the port number and changing the receiver IP). That's where it works.
b) Another possibility is, that the NAT does redirect only traffic from special host to that opened port to the host behind the NAT. That is where it will not work.
c) It's not standardized what "refreshes" the timeout for the incoming traffic rule. The timeout may be prolonged by incoming traffic. But it may be needed to have outgoing traffic to the same host (Server S) to prolong the timeout.
It also seems UDP state expires very quickly for some implementations (within 100 ms in some cases). This means, you'll either need to continue to send keep alive packets to your Server 'S' -OR- you need at least to send UDP packets in shorter periods than 100 ms (e.g. once every 50 ms or 20 ms).
Hi All
I ve two PC's A and B which are connected to LAN1 .A is listening on UPNP multicast address 239.255.255.250 .
I have a mobile device D which is connected to a WIFI and the WIFI is connected to LAN1 .
Ip address of PC A is xxx.yyy.209.80 PC B is xxx.yyy.209.81 and device D is xxx.yyy.209.82.
If I send a multicast packet to 239.255.255.250 from PC B it reaches PC A.
But if I send a multicast pakcet from device D it never reaches PC A .Can anyone tell me why ?How to resolve it ?
Thanks in advance
Kozlov
I realize this post is 3 years old but the following information may be useful to someone. I have an iPhone App that uses a 239.x.x.x address and I have issues with certain wireless access points. I found a document that says the following:
There are some special multicast groups, say "well known multicast
groups", you should not use in your particular applications due the
special purpose they are destined to:
224.0.0.1 is the all-hosts group. If you ping that group, all multicast capable hosts on the network should answer, as every
multicast capable host must join that group at start-up on all it's
multicast capable interfaces.
224.0.0.2 is the all-routers group. All multicast routers must join that group on all it's multicast capable interfaces.
224.0.0.4 is the all DVMRP routers, 224.0.0.5 the all OSPF routers, 224.0.013 the all PIM routers, etc. All this special multicast groups are regularly published in the "Assigned Numbers" RFC.
In any case, range 224.0.0.0 through 224.0.0.255 is reserved for local
purposes (as administrative and maintenance tasks) and datagrams
destined to them are never forwarded by multicast routers. Similarly,
the range 239.0.0.0 to 239.255.255.255 has been reserved for
"administrative scoping" (see section 2.3.1 for information on
administrative scoping).
Anyway I changed my address to 238.x.x.x and that did not help with the Netgear R6100 AP. The issue I have seen with Wireshark is that LAN packets are not forwarded to wireless devices. I have not tried the other direction.