Problem with BGP Session

Problem
You want to figure out why the BGP session is not being established.

Solution
Start by looking at the current state of the TCP sessions on the router:

aviva@RouterF> show system connections extensive



Also look at the information in the system logging files:

aviva@RouterF> show log messages



Check that the TCP session can pass Internet control packets:

aviva@RouterF> ping tos 0xc0 RouterD



Discussion
When two BGP peers have a problem establishing a BGP session, one of the first indications is that you see BGP hold-time expired error messages on the routers in the router's system logging files. You also see that the State field in the show bgp neighbor command output is not Established and that the State field in the show bgp summary command is Active or Connect, indicating that the BGP session is not established.

The hold-time expired errors usually occur because the TCP session between a pair of peers cannot effectively transmit data between the routers, not because of a problem with BGP itself. When the TCP session doesn't work properly, the BGP session times out, and BGP signals the problem by sending hold-time expired messages and generating a BGP Notification message to the remote peer. Notification messages are logged at the system logging severity level warning.

Some of the most frequent causes of hold-time expired errors are MTU issues on a directly connected link, issues related to forwarding of Internet control packets, and IGP failures on IBGP sessions.

Looking at the TCP MTU path behavior, first let's look at the TCP session. By default, a TCP session transmits 576 bytes in a single packet to minimize the chances that the packet will be fragmented at a device along the path to the destination. Most links use an MTU of at least 1,500 bytes. Path MTU discovery, which is disabled by default in the JUNOS BGP, allows BGP to dynamically determine how large the packets can be in a TCP session without being fragmented. This means that BGP tries to use 576-byte packets for the TCP sessions. However, on directly connected EBGP sessions, TCP uses MTU-sized packets. If there is an MTU mismatch between the two sides of the TCP connection, the BGP session cannot be established. One workaround is to enable path MTU discovery within the BGP group:

[edit protocols bgp group external ]
aviva@RouterF# set mtu-discovery



When path MTU discovery is enabled, the don't fragment ( DF) bit is set on all TCP packets sent by the BGP session.

When you are testing session connectivity, in addition to the standard ping command, send packets in which the Internet control CoS bit is set:

aviva@RouterF> ping tos 0xc0 RouterD



If the QoS parameters are misconfigured on a transit router, TCP connectivity can work for regular best-effort traffic but will break for Internet control traffic. The same behavior can happen when you are testing new software or new PICs.

Another way to get information about the TCP session and what might be malfunctioning is to look at the current state of TCP sessions:

aviva@RouterF> show system connections extensive | find tcp
tcp4 0 2 192.168.70.143.23 172.17.28.108.3350 ESTABLISHED
sndsbcc: 2 sndsbmbcnt: 256 sndsbmbmax: 266432
sndsblowat: 2048 sndsbhiwat: 33304
rcvsbcc: 0 rcvsbmbcnt: 0 rcvsbmbmax: 463360
rcvsblowat: 1 rcvsbhiwat: 57920
iss: 2677798142 sndup: 2677853922 sndcc: 0
snduna: 2677853922 sndnxt: 2677853924 sndwnd: 57920
sndmax: 2677853924 sndcwnd: 65535 sndssthresh: 1073725440
irs: 1577022682 rcvup: 1577023284 rcvcc: 0
rcvnxt: 1577023292 rcvadv: 1577081212 rcvwnd: 57920
rtt: 200130618 srtt: 301 rttv: 12
rttmin: 100 duration: 0 mss: 1448
flags: REQ_SCALE RCVD_SCALE REQ_TSTMP RCVD_TSTMP [0x1e0]



Also, use the information in the system logging files, which is very extensive and is similar to the output of the show system connections extensive command:

Aug 24 13:15:46 RouterF rpd[2797]: bgp_traffic_timeout: NOTIFICATION sent to 192.168.
14.1 (Internal AS 3356): code 4 (Hold Timer Expired Error), Reason: holdtime expired
for 192.168.14.1 (Internal AS 3356), socket buffer
sndcc: 0
rcvcc: 0 TCP state: 4,

snd_una: 1404695285
snd_nxt: 1404695285
snd_wnd: 16384
rcv_nxt: 4086106368
rcv_adv:
4086157473, keepalive timer 0



You can learn a lot of information about the TCP connection from the socket buffer information in the system logging message, which is a subset of BSD transmission control block ( TCB) parameters:



sndcc

Bytes on send buffer. A full send buffer typically means that packets from this host are not being acknowledged.



rcvcc

Bytes on receive buffer. Expect 0 bytes here because RPD should not declared a hold time expired if information is available about the buffer.



snd_una



snd_nxt

The difference between these two (snd_nxtsnd_una) is the amount of unacknowledged data on the TCP session.



snd_wnd

Size of the window advertised by the peer.



rcv_adv



rcv_nxt

The difference between these two (rcv_advrcv_nxt) is the size of the window advertised by the local TCP stack.

It is important to try to collect the information on both sides of the session. This gives an indication about whether the data path failure is unidirectional, bidirectional, or dependent on packet size.

If you are seeing hold-time expired errors between IBGP peers, check the IGP logs. If this correlates to a link failure in your IGP, this should probably be your starting point for diagnostics.

See Also
For information about BSD TCBs, see TCP/IP Illustrated (Addison-Wesley).

Usb - key, mouse

Вот такая чудная диковина для виндузячих серверов.

CISCO IOS Basic NAT/PAT

Между прочим ;)

Configuring Basic NAT Functionality
Problem
You want to set up Network Address Translation on your router.

Solution
In the simplest NAT configuration, all of your internal devices use the same external global address as the router's external interface:

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#access-list 15 permit 192.168.0.0 0.0.255.255
Router(config)#ip nat inside source list 15 interface FastEthernet0/0 overload
Router(config)#interface FastEthernet0/2
Router(config-if)#ip address 192.168.1.1 255.255.255.0
Router(config-if)#ip nat inside
Router(config-if)#exit
Router(config)#interface FastEthernet0/1
Router(config-if)#ip address 192.168.2.1 255.255.255.0
Router(config-if)#ip nat inside
Router(config-if)#exit
Router(config)#interface Ethernet0/0
Router(config-if)#ip address 172.16.1.5 255.255.255.252
Router(config-if)#ip nat outside
Router(config-if)#exit
Router(config)#end
Router#

Discussion
In this example, the router will rewrite that address of all of the internal devices whose IP addresses are in the range 192.168.0.0/16. When these internal devices connect to devices on the outside of the network, they will all appear to have the same source address as the external interface of the router, 172.16.1.5.

This example actually includes two internal interfaces and one external. You designate the internal interfaces with the ip nat inside command. You can have as many inside interfaces as you like:

Router(config)#interface FastEthernet0/1
Router(config-if)#ip nat inside

You also need to designate at least one outside interface using the command ip nat outside. There can be several outside interfaces, but this can be very difficult to control, so it is usually not recommended:

Router(config-if)#interface Ethernet0/0
Router(config-if)#ip nat outside

You configure the actual translation action with the line:

Router(config)#ip nat inside source list 15 interface FastEthernet0/0 overload

This tells the router to translate the source addresses of any internal devices that match access-list number 15. The router will translate the source addresses of all of these devices to the address that is configured on the interface FastEthernet0/0, which is the outside interface.

The overload keyword is actually assumed here, so if you leave it off, the router will automatically put it in. This option tells the router that many internal devices can use the same global address simultaneously. Since the router itself uses this address, if even a single internal address translates to this address, it is already overloaded. We will explain this option in more detail in Recipe 21.2.

To help explain what the access-list on this command does, we will change it so that it includes every address in the range except one:

Router(config)#access-list 15 deny 192.168.1.101
Router(config)#access-list 15 permit 192.168.0.0 0.0.255.255

Now if you make a connection from the excluded address, 192.168.1.101, the only difference is that the router will not rewrite this internal address. Instead, this address will appear unchanged on the outside.

NAT can be quite confusing because people usually think that there is some firewall function associated with it. There is not. If you exclude one device from your NAT access-list, as we just discussed, anybody on the outside of the network will be able to connect to this internal device by its real address. But there is nothing to prevent an inbound packet from reaching a particular internal device if the person on the outside knows the real internal address and can route to it. Further, NAT by itself doesn't do any firewall functions, such as UDP or TCP port filtering.

DNAT

Пример:

ip nat inside source static tcp 192.168.10.1 25 171.69.232.209 25

В этом примере внешне инициируемое соединение для порта SMTP (25)
будет посылаться на внутренний хост 192.168.10.1.

BGP attributes

Плотно занялся изучением BGP. Достаточно понятно написано про атрибуты. Из JunOS Cookbook.


Introduction
The IGPs OSPF, IS-IS, and RIP maintain the mapping for the topology within a single administrative domain or AS, along with the set of best paths between systems within the domain. Each AS uses one or more common IGPs and common metrics to determine how to route packets within the AS. The administration of an AS appears to other ASs to have a single coherent interior routing scheme and presents a consistent picture of what destinations are reachable through it.

To handle inter-AS routing, IGPs use an EGP. EGPs keep track of how routing domains are connected to each other and the sequence of domains that must be traversed to reach a particular destination. Although a number of EGPs were developed in the late 1980s, the Border Gateway Protocol (BGP) is the only one currently being used on IP networks and the Internet. Version 1 of BGP was introduced in 1989, and the current iteration, Version 4, is defined in RFC 1771 and has been in use since 1995. A number of additional RFCs define extensions to the base BGP protocol (see http://www.bgp4.as/rfc).

BGP is the routing protocol that holds the Internet together, providing the mesh-like connectivity of Internet service provider (ISP) networks that forms what we call the Internet. ISPs use BGP to connect to each other, forming the virtual backbone of the Internet. Large enterprises also sometimes use BGP to connect to their ISPs, as well as to connect portions of their internal corporate network.

BGP uses a path vector algorithm to determine network topology and paths to destinations. This algorithm defines a route as a pairing between a destination and the attributes of the path to that destination. It considers multiple attributes of the path in order to choose the best route to the destination. In comparison, a distance-vector protocol uses a single distance metric to choose the best route. BGP routing updates carry path information, which is a full list of the transit ASs that must be traversed between the AS receiving the update and the AS that can deliver the packet using its IGP. BGP uses this list to eliminate loops in the path because a router can check the list of ASs to see whether a route has already passed through it. BGP treats each AS equally when considering the path, no matter how big or small it is. BGP does not know how many routers or what type of links are in an AS.

BGP uses TCP port 179 for transport. BGP relies on basic TCP connections to reach its peers, using the fragmentation, retransmission, acknowledgment, and sequencing functions in TCP. If two routers cannot establish a TCP connection between them, they will not be able to establish BGP peering.

BGP requires that all peering sessions be configured explicitly between BGP neighbors. There are two types of BGP peerings, external BGP (EBGP) and internal BGP (IBGP). The basic distinction between them is that an EBGP peering is between two ASs that have different AS numbers and an IBGP peering is within a single AS so the peers have the same AS number. An EBGP peering is between two BGP routers that are directly connected to each other. IBGP peerings can be among multiple routers within an AS. IBGP routers must create a full mesh of IBGP peering sessions to communicate BGP routing information with each other. This full mesh can be physical connections, where all IBGP routers are directly connected and adjacent to each other. Typically, though, the full mesh is virtual, created in the router software configuration, and the connectivity is provided by an IGP. A third type of BGP peering, called multihop or EBGP multihop, allows BGP to set up sessions with neighbors in other ASs that are not directly connected.

BGP requires that each AS have a 16-bit AS number. AS numbers range from 0 tHRough 65535 and are globally unique across the Internet. BGP uses the AS number to prevent routing loops. AS numbers are doled out in blocks to each of the regional Internet registries ( ARIN, APNIC, RIPE, AfriNIC, and LatNIC), and the regional registries assign AS numbers to individual organizations. The AS numbers 64512 tHRough 65534 are reserved for private use, but you can use these on internal enterprise networks as long as the numbers are unique within your network. The examples in this chapter use private AS numbers as well as RFC 1918 private IP addresses. This is purely for demonstration purposesyou should never allow private AS numbers or private IP addresses to reach the public Internet.

By default, BGP routers accept all BGP information from EBGP peers and advertise all BGP information to all EBGP peers. BGP routers advertise all BGP information to IBGP peers if it comes from an EBGP peer and advertise paths learned from IBGP peers only to external peers. BGP does not advertise its internal paths to IBGP peers. This is done instead by IGP. To prevent routing loops, a BGP router does not, by default, accept routes that contain its own AS number.

BGP makes extensive use of routing policy to allow ISPs to enforce administrative policies. The JUNOS software provides both inbound and outbound policy controls at different levels: for all BGP peers, for groups of peers, and for individual peers. A policy with a narrower scope overrides one with a broader scope. Stated another way, a policy applied to a group overrides a BGP-wide policy, and a policy applied to a peer overrides both a group and BGP-wide policy.

Multiprotocol BGP ( MBGP), defined in RFC 2858, is an extension to BGP that supports other protocols, including IPv6, MPLS, and VPNs.

In choosing routes toward a destination, if there is more than one route to the same destination, BGP uses an algorithm to select a single route to use (see the Introduction to Chapter 8). Note that other router vendors may follow a slightly different set of rules to determine the active route.

For more information about BGP, see BGP4: Inter-Domain Routing in the Internet (Addison-Wesley).

BGP Attributes
BGP routers exchange routes, or NLRI, with their neighbors. An NLRI consists of a route prefix and the BGP attributes associated with the route. Attributes contain information about a route, such as where it came from and how to reach it, that BGP uses to choose the best path to a destination. A number of attributes were defined in the original BGP specification, and, over time, attributes have been added to extend the functionality of BGP. Compared to IGP routes, which generally just carry the route, a next hop, metric, and an optional tag, BGP routes typically have about a dozen attributes associated with them.

There are several types of attributes. Well-known attributes are supported by all BGP implementations. Mandatory attributes are included with every prefix. If they are missing, the receiving BGP router will generate an error message. Discretionary attributes are those that BGP routers must recognize and support but don't have to be included with every prefix. When a BGP router passes a prefix to its peers, it includes all well-known, mandatory, and discretionary attributes associated with the prefix, either in the state they were received or in the state after they were modified when they passed through the local AS.

BGP routers can also include optional attributes with prefixes, or those that are not necessarily supported by all BGP routers. Optional attributes can be transitive, which means that BGP must include the information when sending the prefix to another router even if the sending router doesn't understand the option, or nontransitive, which allows a router that doesn't understand the option to silently drop it when advertising the prefix.

The following are some of the common BGP attributes. Most BGP implementations understand these attributes.



ORIGIN (well-known, mandatory)

Designates how BGP learned about the route. It can be one of the following:



I

Route was originally learned from an IGP in the originating AS.



E

Route was originally learned from an EGP.



Incomplete

Route's source is unknown or BGP doesn't have complete knowledge of its origin.



AS_PATH (well-known, mandatory)

Contains a list of AS numbers that form the path to a destination network. There are two types of AS path attributes. The AS_SEQUENCE attribute indicates the networks that the route has transited from the originating AS to the local AS. When advertising a prefix to an EBGP peer, a BGP router modifies the AS path, prepending its AS by adding it to the beginning of the list. The last AS in the path sequence is the originator of the route. For example, in the AS path 65500 65505 65100, the route originated at AS 65100 and the last AS it passed through was 65500. BGP uses the AS path for loop avoidance among ASs. The second type of AS path attribute is AS_SET, which is an unordered list of AS numbers along the path to the destination.



NEXT_HOP (well-known, mandatory)

Contains the IP address of the BGP router that is the next hop toward the destination. The BGP router selects the next hop based on its local routing table. For routes learned from a different AS, the next hop is the IP address of the physical interface to a remote router. If the advertising and receiving routers are in the same AS and the route is in the same AS, the BGP next hop is the IP address of the advertising router. If the route is in a different AS, the BGP next hop is the IP address of a remote BGP router.



LOCAL_PREF (well-known, optional)

Indicates the degree of preference for routes learned by IBGP within an AS. BGP uses this information to choose or favor an exit point from the AS. The higher the preference, the more preferred a route is. This attribute is distributed only in IBGP routing updates.



MED or MULTI_EXIT_DESC (optional, nontransitive)

The multiple exit discriminator is used to determine the exit point from one AS to another AS when there are multiple equivalent paths between the ASs and when all other factors in determining the exit point are equal. The MED is effectively the BGP metric and is a common way for one ISP to make another ISP use the desired link between the two ISPs. Because the MED is nontransitive, it is sent only to adjacent ASs.



ATOMIC_AGGREGATE (well-known, optional)

Indicates that the route is an aggregate of several route prefixes. BGP sets this attribute to indicate that some route information has been lost in the aggregation process.



AGGREGATOR (optional, transitive)

Indicates that the BGP router has summarized a range of prefixes.



COMMUNITY (optional, transitive)

Identifies an administrative or logical grouping of routes that share routing policies. Communities are represented by an identifier that includes the 16-bit AS number and a 16-bit community number. For example, in 65500:1001, the AS number is 65500 and the community number is 1001. BGP has three well-known communities:



NO_EXPORT

Routes cannot be advertised to EBGP peers but can be advertised within a BGP confederation.



NO_ADVERTISE

Routes cannot be advertised at all.



LOCAL_AS

Routes cannot be advertised to EBGP peers, even if the peers are in the same confederation.



MP_REACH_NLRI and MP_UNREACH_NLRI (optional, nontransitive)

Carry IPv6 NLRI information in MBGP.



ORIGINATOR_ID (optional, nontransitive)

Identifies a route reflector for IBGP. It is a 32-bit value that indicates the originator of the route within an AS.



CLUSTER_LIST (optional, nontransitive)

Lists route reflection identifiers of the clusters through which the route has passed. If a cluster sees its own identifier in the list, a loop has occurred and the route is ignored.

JunOS Cookbook

JunOS Cookbook

Perl view my IP

Есть сервер, подключенный к модему с динамическим public ip. Решил обойтись без dynamic dns. На сервере пишу скрипт на Perl, который выходит на сайт whatismyipaddress.com, узнает там свой айпишник, записывает его в файл ip.htm и выкладывает на ftp.


#!/usr/bin/perl
# Script by k4

open DB, "ip.htm";
$pth="/home/user";
chdir $pth;

$lastip=;
chomp $lastip;
#print $lastip;

my $url = 'http://whatismyipaddress.com/';

use LWP::Simple;
my $content = get $url;
die "Couldn't get $url" unless defined $content;

if($content =~ m/(IP\sInformation:\s\)(\d+\.\d+\.\d+\.\d+)(\<\!\-\-\s)/) {

if ($lastip eq $2) { } else { $a=1; print `echo $2 > ip.htm`; }
} else {
print "IP is unknown\n";
}

if ($a) {

use Net::FTP;

$ftp = Net::FTP->new('ftp.host.net', Debug => 0)
or die "Cannot connect to sgsn1: $@";


$ftp->login('login', 'password')
or die "Cannot login", $ftp->message;

#$ftp->cwd("/")
#or die "Cannot change working directory ", $ftp->message;

$ftp->put("ip.htm")
or die "send failed ", $ftp->message;

$ftp->quit;
}