84 lines
4.9 KiB
HTML
84 lines
4.9 KiB
HTML
|
<?xml version="1.0" encoding="utf-8"?>
|
||
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
||
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="dc.language" scheme="rfc1766" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<meta name="dc.date" scheme="iso8601" content="2005-10-03" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow"/>
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<title>APPN filtering support</title>
|
||
|
|
<link rel="stylesheet" type="text/css" href="ibmidwb.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="ic.css" />
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
<a id="Top_Of_Page" name="Top_Of_Page"></a><!-- Java sync-link -->
|
||
|
|
<script language = "Javascript" src = "../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
|
||
|
|
|
||
|
|
<a name="appnfilsup"></a>
|
||
|
|
<h4 id="appnfilsup">APPN filtering support</h4>
|
||
|
|
<p>Before we discuss APPN filtering support, an explanation of node types
|
||
|
|
in an APPN network is needed:</p>
|
||
|
|
<ul>
|
||
|
|
<li>A <span class="bold">peripheral node</span> is at the edge of a network. It
|
||
|
|
can participate in the network, but it cannot provide intermediate routing
|
||
|
|
to other systems in the network. A peripheral node can be an <span class="bold">end node (EN)</span> such as MADISON and PARIS in the figure below. A peripheral
|
||
|
|
node can be a <span class="bold">low-entry networking node (LEN)</span>, such
|
||
|
|
as CHICPC1 and CHICPC2. A peripheral node can also be a network node in a
|
||
|
|
different network (NETID). From CHICAGO's perspective, LONDON is a peripheral
|
||
|
|
node.</li>
|
||
|
|
<li>A <span class="bold">network node (NN)</span> provides routing services among
|
||
|
|
systems in the network. In CHICAGO, and ATLANTA are examples of network nodes.</li>
|
||
|
|
<li>A <span class="bold">Branch Extender</span> node is an extension to the APPN
|
||
|
|
network architecture that appears as a network node (NN) to the Local Area
|
||
|
|
Network (LAN), and as an end node (EN) to the Wide Area Network (WAN). This
|
||
|
|
reduces topology flows about resources in the LAN from being disconnected
|
||
|
|
from the WAN.</li></ul>
|
||
|
|
<p>APPN filtering support provides the ability to create a firewall that is
|
||
|
|
based on APPC location names. You use two different types of filter lists: </p>
|
||
|
|
<ul>
|
||
|
|
<li>A <span class="bold">session-endpoint filter</span> controls access to and
|
||
|
|
from a location. For example, in the session endpoint filter on the CHICAGO
|
||
|
|
system in the figure below, it specifies which locations can establish a session
|
||
|
|
with CHICAGO or with PAYROLL. CHICAGO and PAYROLL are two different locations
|
||
|
|
on the CHICAGO system.
|
||
|
|
<p>Similarly, the session endpoint filter on the MADISON
|
||
|
|
system specifies which locations can establish a session with the MADISON
|
||
|
|
location.</p>
|
||
|
|
<a name="appnnetb"></a>
|
||
|
|
<div class="fignone" id="appnnetb"><span class="figcap">Figure 11. Two connected APPN networks</span>
|
||
|
|
<img src="rv4n400.gif" alt="Two connected APPN networks" /></div>
|
||
|
|
<p>On iSeries, you
|
||
|
|
can use the new QAPPNSSN configuration list, by itself or in conjunction with
|
||
|
|
the QAPPNRMT configuration list, to create a session endpoint filter.</p></li>
|
||
|
|
<li>A <span class="bold">directory search filter</span> on a network node determines
|
||
|
|
the following for its associated peripheral nodes:
|
||
|
|
<ul>
|
||
|
|
<li>Access <span class="bold">from </span> the peripheral node (when the peripheral
|
||
|
|
node is the requester). For example, in you can use the directory search filter
|
||
|
|
on LONDON to control the possible destinations for users on the PARIS system.
|
||
|
|
Similarly, you can use the directory search filter on CHICAGO to control the
|
||
|
|
possible destinations for users on CHICPC1 and CHICPC2.</li>
|
||
|
|
<li>Access <span class="bold">to</span> the peripheral node (when the peripheral
|
||
|
|
node is the destination). In for example, you can use the directory search
|
||
|
|
filter on CHICAGO to determine which locations can access CHICPC1. Because
|
||
|
|
both CHICAGO and DALLAS provide connections to MADISON, you must set up the
|
||
|
|
directory search filters on both CHICAGO and DALLAS to restrict connections
|
||
|
|
to MADISON.
|
||
|
|
<p>Similarly, you can use the directory search filter on CHICAGO
|
||
|
|
to specify which USANET locations are permissible destinations for EURONET
|
||
|
|
users.</p></li></ul>
|
||
|
|
<p>To create a directory search filter use the QAPPNDIR configuration
|
||
|
|
list.</p></li></ul>
|
||
|
|
<a id="Bot_Of_Page" name="Bot_Of_Page"></a>
|
||
|
|
</body>
|
||
|
|
</html>
|