How can i fix ploss on network? - networking

Sometimes I experience ploss on packets going to my server. This problem is not constant and there are instant interruptions. Checked for physical problems on the server. I am using OSPF as routing protocol in internal network. What settings do you think I should check in OSPF to fix these problems?
enter image description here
set protocols ospf area 0.0.0.1 interface ae0.888
set protocols ospf area 0.0.0.4 interface ae2.999
set protocols ospf export OSPF_EXPORT
set policy-options policy-statement OSPF_EXPORT term FIRST from protocol direct
set policy-options policy-statement OSPF_EXPORT term FIRST from protocol rip
set policy-options policy-statement OSPF_EXPORT term FIRST from protocol ospf
set policy-options policy-statement OSPF_EXPORT term FIRST then accept

Related

Why only MAC address is used to transfer the packet to a device?

I am sorry if its basics, but I did not find the appealing answer for it over the Internet.
Why only MAC is used to transfer the packet to a device ? MAC address is only obtained by ARP for a specific IP address. So, why not just let the routers maintain IP addresses of the neighbouring routers and route packets using IP addresses of routers instead of MAC addresses ?
Why not redesign the architecture, to only use IP address for routing as well as moving the packet in the data link layer too ?
Why do we need MAC addresses?" Why can't network devices such as the routers just send the packet to the next router using the router's IP address?
Note : I know that MAC address is used to identify the system in a network. But you see the source never knew the MAC address of receiver. All it knew was its IP address and MAC address of next hop.
I'm reading Data Comm and Networking by Forouzan ( Ed 5) and it says that even routers have an IP address. So why use the mac address at all. The router can store the IP address of the source and route it to the next router .
EDIT : The question that I was getting as suggestion to this one does not answer my query. There are multiple counter points and proof that I have presented here which could have been done which is not answered by the one which is suggested. So please read my question before making any assumptions.
What do you think makes more sense: Having one protocol like Ethernet handle all the layer 2 details so that its layer 3 payload doesn't have to care, or force IP, ARP, WoL, IPX, MPLS, SLPP, and dozens more implement it on their own? The whole purpose of OSI layers is that upper layers need not know all the lower layer's details and lower layers need need not support the upper layer's features.
MAC addresses are used for the layer 2 protocol which encapsulates a layer 3 protocol. If all the necessary features were embedded into IP, then you'd be leaving other protocols to re-implement layer 2 routing on their own. This would be wildly inefficient.

Does the Internet Protocol do Routing?

Many sources in the web have different opinion on this. It is obvious that the Internet Protocol speicfied in RFC 791 is responsible for addressing host interfaces, encapsulating data into datagrams (including fragmentation and reassembly). But what is about routing? Is this the function of IP or is this realized by the protocols RIP, OSPF nad BGP?
The word "routing" has two closely related meanings:
1) As RFC 791 section 1.4 says "The selection of a path for transmission is called routing." When a layer 3 packet (IP datagram) arrives on an incoming interface, the router does a longest-prefix-match lookup in the routing table to decide on which outgoing interface and next-hop the packet should be forwarded.
2) The act of filling the routing tables, by running some routing protocol such as RIP, OSPF, or BGP is also called "routing".
The former is often done in hardware, and the latter is done in software.
When the difference matters, the former is often called forwarding (hence "FIB" for Forwarding Information Base) and the latter is called routing (hence "RIB" for Routing Information Base).

TCP/IP - Why does a part of a packet may use a connection-less services in a connection-oriented service.

While reading the book on TCP/IP I came across the words which are as "Although it looks as though the use of the flow label may make the source and destination addresses useless, the parts of the Internet that use connection-less service at the network layer still keep these addresses for several reasons.One reason is that part of the packet path may still be using the connection-less service. Another reason is that the protocol at the network layer is designed with these addresses and it may take a while before they can be changed". Now my question to you is if a connection has been formed between hosts in a connection-oriented manner then how come a path of a packet may still be using the connection-less services. Because as per my knowledge prevails the virtual path always be formed at while 3-way handshake is taking place which is the TCP/IP connection (which uses a connection-oriented service) ? And my second question for the second reason is that which protocol they are talking about since these words are stated below the Heading of "Connection-Oriented Services" therefore, it's making me pissed off to understand the literal meaning behind the words(The core conceptual understanding). And correct if anyone thinks I am having a wrong concept at any place. I'll be obliged. Thanks.
TCP as a connection-oriented protocol runs on top of IP which is connection-less. The routers used in transport only look at the IP packet, the TCP segment is simply payload and transported along. TCP provides several algorithms to form a virtual connection over a connection-less network.
The IP packet goes from hop to hop. On each hop, a router makes a forwarding decision solely based on the destination IP address. (More sophisticated devices may inspect more packet elements including source address and payload, but they aren't simple routers.)
The "path" is made up of all these individual hops. Because each hop is based on an independent routing decision the path can change at any time and for any packet. The path is not laid out by the TCP handshake.
Basically, you have to look at each protocol layer individually. Each one serves its own function.
I hope this also answers the second question.

BGP control plane information in MPLS VPN

I am learning about MPLS VPN networks. From my understanding an IGP runs on all core routers (P and PE), while BGP runs on all PE routers. Once the IGP has conveyed reachability information to all routers, and all routers have converged, the exact labels to be used to transfer packets are assigned using LDP.
My doubt is, how are BGP control packets transmitted between PEs.
There are two options.
1. To use the Label switched paths between PEs.
2. To use normal IP forwarding through the P routers.
Which of these two methods is actually used?
If both can be used how does the PE router make a decision on which one to use?
Do we have to manually configure it in the router?
Do these answers vary for different routers like Juniper, Cisco etc. ?
My doubt is, how are BGP control packets transmitted between PEs.
There are two options:
To use the Label switched paths between PEs.
To use normal IP forwarding through the P routers.
If both can be used how does the PE router make a decision on which one to use?
LSPs are preferred over per-hop IP forwarding, if an LSP is available.
Do we have to manually configure it in the router?
By 'it', do you mean configure use of the LSP for BGP control-plane information? It happens automatically on a Cisco IOS box
Do these answers vary for different routers like Juniper, Cisco etc. ?
Cisco will send BGP information through an LDP LSP, as long as the BGP endpoint prefix has an label binding.
I can't remember Juniper's behavior off-hand, they offer somewhat more granular control over LSP behavior.
BGP uses TCP te setup its connection and to send their packets to his neighbors.
This means that your neighbors need to see each other on layer 3 (ip) level.
I hope this is the info that you needed.
see: http://en.wikipedia.org/wiki/Border_Gateway_Protocol
section "operation" for more details on this matter.

Creating a TCP connection between 2 computers without a server

2 computers are in different subnets.
Both are Windows machines.
There are 2-5 IGMP-ready routers between them.
They can connect each other over multicast protocol (they have joined the same multicast group and they know about each other's existance).
How to establish a reliable TCP connection between them without any public server?
Programming language: C++, WinAPI
(I need a TCP connection to send some big critical data, which I can not entrust to UDP)
You haven't specified a programming language, so this whole question may be off-topic.
Subnets are not the problem. Routability is the problem. Either there is routing set up or there isn't. If they are, for example, both behind NAT boxes, then you're at the mercy of the configuration of the nat boxes. If they are merely on two different subnets of a routed network, it's the job of the network admin to have set up routing. So, each has an IP address, and either can address the other.
On one machine, you are going to create a socket, bind it to some port of your choice, and listen. On the other, you will connect to the first machine's IP + the selected port.
edit
I'm going to try again, but I feel like there's a giant conceptual gap here.
Once upon a time, the TCP/IP was invented. In the original conception, every item on the network has an IPV4 address, and every machine could reach every other machine, via routing, except for machines in the 'private' address space (10.x, etc).
In the very early days, the only 'subnets' were 'class A, class B, class C'. Later the idea of subdividing a network via bitmasks was added. The concept of 'subnet' is just a way of describing a piece of network in which all the hosts can deliver packets to each other by one hop over some transport or another. In a properly configured network, this is only of concern to operating system drivers. Ordinary programs just address packets over the network and they arrive.
The implementation of this connectivity was always via routing protocol. If you have a (physical) ethernet A over here, and a (physical) ethernet B over there, connected by some sort of point-to-point link, the machines on A need to know where to send packets for B. Or, to be exact, they need to know where to send 'not-A' packets, and whatever they send them needs to know where to send 'B' packets. In simple cases, this is arranged via explicit configuration: routing rules stuffed into router boxes or even computers with multiple physical interfaces. In more complex cases, routing boxes intercommunicate via protocols like EGP or BGP or IGMP to learn the network topology.
If you use the Windows 'route' command, you will see the 'default route' that the system uses to send packets that need to leave the local subnet. It is generally the address of the router box responsible for moving information from the local subnet to everywhere else.
The whole goal of this routing is to arrange that a packet sent from a.b.c.d to e.f.g.h will get there. TCP is no different than UDP, except that you can't get there by multicast or broadcast: you need to know the exact address of your correspondent.
DNS was invented to allow hosts to learn each other's IP addresses without having human being send them around in email messages.
All this stops working when people start using NAT and firewalls to turn off routing. The whole idea of NAT is that the computers behind the NAT box are not addressable at all. They all appear to have one IP address. They can send stuff out, but they can only receive stuff if the NAT box has gone to extra trouble to map them a port.
From your original message, I sort of doubt that NAT is in use here. I just don't understand your comment 'I don't have access to the network.' You say that you've sent UDP packets here and there. So how did you do that? What addresses did you use?

Resources