summaryrefslogtreecommitdiffstats
path: root/Bachelor/CCNA4/en_CCNA4_v30/ch5/5_1_5/content.html
blob: 68ac54e77320f1ec6a04084dd9d803657abec299 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
<html>



<head>

<meta http-equiv="Content-Language" content="en-us">

<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">

<title>Content</title>

<base target="_self">

</head>



<body background="../../images/bg.gif" topmargin="0" leftmargin="0" marginheight="0" marginwidth="0" onLoad="window.focus();" link="#808080" vlink="#808080" alink="#808080">



<table border="0" cellpadding="0" cellspacing="0" width="100%">

  <tr>

    <td bgcolor="#336666" width="18" valign="top">

    <img border="0" src="../../images/content_lines.gif" width="16" height="25">

    <img border="0" src="../../images/transdot.gif" width="2" height="1"></td>

    <td bgcolor="#336666"><b><font face="Arial" size="2" color="#FFFFFF">5</font></b><font face="Arial" size="2" color="#FFFFFF"><b>.1</b></font></td>

    <td bgcolor="#336666"><img border="0" src="../../images/transdot.gif" width="10" height="1"></td>

    <td bgcolor="#336666" width="100%"><b style="mso-bidi-font-weight:normal"><span style="font-family:Arial;mso-bidi-font-family:&quot;Times New Roman&quot;"><o:p>

    <font size="2" color="#FFFFFF">Frame Relay Concepts</font>

      </o:p>

      </span></b></td>

    <td width="9" bgcolor="#336666">&nbsp;</td>

  </tr>

  <tr>

    <td bgcolor="#669999" height="25" width="18">&nbsp;</td>

    <td bgcolor="#669999" height="25"><b>

    <font face="Arial" size="2" color="#FFFFFF">5.1.5</font></b></td> 

    <td bgcolor="#669999"><img border="0" src="../../images/transdot.gif" width="10" height="1"></td>

    <td bgcolor="#669999" height="25" width="100%"><strong>

    <font face="Arial" size="2" color="#FFFFFF">Frame Relay address mapping and 

    topology</font></strong></td>

    <td bgcolor="#669999" height="25" width="9">&nbsp;	</td>

  </tr></table>



<table border="0" cellpadding="0" cellspacing="0" width="95%" bordercolor="#111111">

      <tr>

        <td width="15"></td>

        <td>



          <font FACE="Arial" SIZE="2">

          When more than two sites are to be connected, consideration must be 

          given to the topology of the connections between them.</font><p>



          <font FACE="Arial" SIZE="2">

          Frame Relay is unlikely to be cost-effective when only two sites are 

          interconnected with a point-to-point connection. Frame Relay is more 

          cost-effective where multiple sites must be interconnected.</font></p>

          <p>



          <font FACE="Arial" SIZE="2">

          WANs are often interconnected as a star topology. A central site hosts 

          the primary services and is connected to each of the remote sites 

          needing access to the services.

          <img border="0" src="../../images/1.gif" align="absmiddle" width="12" height="12"> In this 

          hub and spoke topology the location of the hub is chosen to give the 

          lowest leased line cost. When implementing a star topology with Frame 

          Relay, each remote site has an access link to the frame relay cloud 

          with a single VC. The hub has an access link with multiple VCs, one 

          for each remote site.

          <img border="0" src="../../images/2.gif" align="absmiddle" width="12" height="12"> Because 

          Frame Relay tariffs are not distance related, the hub does not need to 

          be in the geographical center of the network.</font></p>

          <p>



          <font FACE="Arial" SIZE="2">

          A full mesh topology is chosen when services to be accessed are 

          geographically dispersed and highly reliable access to them is 

          required. 

          With full mesh, every site is connected to every other site. Unlike 

          with leased line interconnections, this can be achieved in Frame Relay 

          without additional hardware.

          <img border="0" src="../../images/3.gif" align="absmiddle" width="12" height="12"> It is 

          necessary to configure additional VCs on the existing links to upgrade 

          from star to full mesh topology. Multiple VCs on an access 

          link will generally make better use of Frame Relay than single VCs. 

          This is 

          because they take advantage of the built-in statistical multiplexing.&nbsp;<img border="0" src="../../images/4.gif" align="absmiddle" width="12" height="12"></font></p>

          <p>



          <font FACE="Arial" SIZE="2">

          For large networks, full mesh topology is seldom affordable. This is 

          because the number of links required for a full mesh topology grows at 

          almost the square of the number of sites. While there is no equipment 

          issue for Frame Relay, there is a limit of less than 1000 VCs per 

          link. In practice, the limit will be less than that, and larger 

          networks will generally be partial mesh topology. With partial mesh, 

          there are more interconnections than required for a star arrangement, 

          but not as many as for a full mesh. The actual pattern is very 

          dependant on the data flow requirements.</font></p>

          <p>



          <font FACE="Arial" SIZE="2">

          In any Frame Relay topology, when a single interface is used to 

          interconnect multiple sites, there may be reachability issues. This is 

          due to the nonbroadcast multiaccess (NBMA) nature of Frame Relay. 

          Split horizon is a technique used by routing protocols to prevent 

          routing loops. Split horizon does not allow routing updates to be sent 

          out the same interface that was the source of the route information. 

          This can cause problems with routing updates in a Frame Relay 

          environment where multiple PVCs are on a single physical interface. </font></p>

          <p>



          <font FACE="Arial" SIZE="2">

          Whatever the underlying topology of the physical network, a mapping is 

          needed in each FRAD or router between a data link layer Frame Relay 

          address and a network layer address, such as an IP address. 

          Essentially, the router needs to know what networks are reachable 

          beyond a particular interface. The same problem exists if an ordinary 

          leased line is connected to an interface. The difference is that the 

          remote end of a leased line is connected directly to a single router. 

          Frames from the DTE travel down a leased line as far as a network 

          switch, where they may fan out to as many as 1000 routers. The DLCI 

          for each VC must be associated with the network address of its remote 

          router. This information can be configured manually by using map 

          commands. It can also be configured automatically, taking LMI status 

          information and sending a Reverse Address Resolution Protocol (RARP) 

          message on each VC identified. This process is described in more 

          detail in a separate section.</font></p>

          <p>

          <TABLE bgcolor="#B0AFAF" width="95%" border="0" cellspacing="0" cellpadding="0">

        <TR>

        <TD valign="top">

        	<TABLE bgcolor="#669999" width="100%" cellspacing="0" cellpadding="0" border="0">

        	<TR>

        	<TD width="5">

            <img border="0" src="../../images/lab_toplft.gif" width="116" height="23"></TD>

        	<TD><IMG alt="" height="1" width="3" src="../../images/s.gif"></TD><TD align="right" valign="top">

            <IMG alt="" src="../../images/corner_ur_7.gif" width="7" height="7"></TD>

        	</TR>

        	</TABLE>

        

        	<TABLE bgcolor="#B0AFAF" width="100%" cellspacing="0" cellpadding="0" border="0">

	        <TR>

      		<TD>

        		<TABLE width="100%" cellpadding="2" cellspacing="0" border="0" bordercolor="#111111">

        		<TR>

        		<TD bgcolor="#ffffff" width="15">&nbsp;</TD>

        		<TD bgcolor="#ffffff"><font FACE="Arial" SIZE="2" COLOR="#000000">

            	<p><font color="#808080">

                <img border="0" src="../../images/links_icon.gif" width="25" height="25">

                <b>Web Links</b></font></p>

            	</font><font FACE="Arial" SIZE="2" COLOR="#808080">



            	<p>Configuring Dynamic and Static Mapping for Multipoint Subinterfaces<p>

          <a target="_blank" href="http://www.cisco.com/warp/public/125/17.html#17-A">

          http://www.cisco.com/warp/public/

          125/ 17.html#17-A</a></font></p>

            	

                <p>    		

                <IMG alt="" height="2" width="1" src="../../images/s.gif"></p>

                </TD>

        		</TR>

        		</TABLE>

        	</TD>

        	</TR>

        	</TABLE>

        </TD>

        </TR>

        </TABLE><p>

        &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

          <font face="Arial" size="2">&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;

          </font>

        </td>

      </tr>

    </table>



</body>



</html>