implementations of TCP/IP networking. If
both of these local files have not been configured with a
hard-coded resolution of the desired NetBIOS name and address,
and the Windows client is configured to use a DNS server, the
DNS server is queried. NetBIOS and Other Network
Layer Protocols
By default, NetBIOS uses the NetBEUI
Frame (NBF) protocol at the lower layers of the OSI model for
network communications. NetBEUI has the advantage of being very
simple to configure, making it highly suitable to small
networks unlikely to have a full-time administrator. The main
limitation of NetBEUI is that it is broadcast-based and cannot
operate over routed networks. To work on a larger scale,
NetBIOS must replace NetBEUI with either the IPX/SPX or TCP/IP
protocol suites at the network layer of the OSI model. The
TCP/IP protocol suite is most commonly used. When NetBIOS
interfaces with the TCP/IP protocol stack, it creates the
NetBIOS over TCP/IP (NetBT) protocol. This is slightly
misleading, because NetBIOS actually interfaces with UDP, not
TCP, at the transport layer of the TCP/IP stack, using the
NetBIOS Data Protocol to form NetBT. Recall that NetBIOS
provides connection and session management at higher layers in
the OSI model. This means NetBIOS does not need to rely on TCP
for these functions and is able to use the more
bandwidth-efficient UDP at transport layer. NetBIOS Node
Type
Recall that NetBIOS is broadcast-based, but TCP/IP
is primarily unicast-based. This means that the behavior of the
NetBIOS name resolution process over TCP/IP can be configured
depending on the size and nature of the network.
Misconfiguration of the NetBIOS node type is a common cause of
network problems at the transport layer. The behavior of
NetBIOS nodes over TCP can be configured as one of four
options: - B-node (Broadcast node)
- P-node
(Peer-to-peer node)
- M-node (Mixed node)
- H-node (Hybrid node)
NetBIOS hosts configured
as NetBIOS broadcast nodes use only UDP datagram broadcasts for
NetBIOS name registration and resolution. In large networks,
this has the negative impact of increasing the load on the
network. By default, routers contain packets generated by
NetBIOS name registration and resolution from broadcast nodes.
This means that NetBIOS B-node operation is not suitable where
resources need to be accessed across a router. Peer-to-peer
NetBIOS hosts do not use broadcasts. These hosts rely on having
a NetBIOS name server configured to support the operation of
NetBIOS name registration and resolution activities. Although
this enabled NetBIOS computers to communicate across routers,
it makes the network completely reliant on the operation of the
NetBIOS name server. If the NetBIOS name server were to fail,
the NetBIOS clients would not be able to communicate with each
other because they could not broadcast to locate each other.
Computers with mixed node configuration use both B-node and
P-node operation for NetBIOS name registration and resolution.
The default mode of operation for a mixed node host is
broadcast. Therefore, if a broadcast fails to return a positive
response, the host reverts to peer-to-peer operation. This
enables a computer to locate resources on a local network
easily and to use a NetBIOS name server if a required resource
is not located on the local network segment. NetBIOS hosts
configured as hybrid node clients also use both peer-to-peer
and broadcast operation for NetBIOS name registration and
resolution. Unlike Mixed nodes, Hybrid nodes default to using
peer-to-peer and revert to using broadcast when peer-to-peer
fails to return a positive response.
Content
6.2 Troubleshooting Transport Layer Issues on
the Router 6.2.1 Common issues with extended
ACLs Network problems can arise from transport layer
problems on the router, particularly at the edge of the network
where security technologies are examining and modifying the
traffic. This section will discuss two of the most commonly
implemented transport layer security technologies. They are
access control lists and Network Address Translation. Recall
that access lists are used to filter all traffic entering and
leaving the router. Obviously, the most common issues with
extended access lists will be the result of misconfiguration by
the network engineer. There are eight areas where
misconfigurations commonly occur: - Selection of
traffic flow
- Order of access control elements
- Implicit “deny any any”
- Addresses and wildcard
masks
- Selection of transport layer protocol
- Source and destination port(s)
- Use of the
‘established’ keyword
- Uncommon protocols
Selection of traffic flow
Although these points are
not listed in any particular order, the most common router
misconfiguration of extended access lists is applying the
access list to the incorrect traffic. Traffic is defined by
both the router interface through which the traffic is
traveling, as well as the direction in which this traffic is
traveling. Once defined, an access list must be applied to the
correct interface and the correct traffic direction must be
selected in order to function properly. Order of Access
Control Elements
Another common mistake made when
configuring ACLs is the order in which access control elements
(ACEs) are configured. Although an access list may have an
element to specifically permit a particular traffic flow,
packets will never match that element if they are being denied
by another element earlier in the list. Recall that the
guideline for configuring an access control list is specific to
general. This means that the most specific elements are
configured at the top of the list and the less specific
elements are configured at the end. The more information
defined in an element, the more specific that element is. For
example, the element permit tcp 10.0.0.0 0.255.255.255 any
eq 110 established is more specific than the element
permit tcp 10.0.0.0 0.255.255.255 any eq 110 because the
first element used the additional keyword established.
The element permit udp host 10.32.96.7 eq 53 any is more
specific than both of these because it matches a more specific
(smaller) range of source addresses. Implicit “deny any
any”
Every extended access list has a deny any
any element implied as the final entry in the list. This
serves as a security catch all, ensuring traffic that does not
match any of the administratively configured access control
elements is not allowed through. This does not normally pose an
issue when configuring firewall routers, as the guideline for
configuring highly secure access lists is to deny everything
and specifically permit particular traffic flows. In a
situation where high security is not required on the access
list, forgetting about this implicit access control element may
be the cause of an access list misconfiguration. Addresses
and wildcard masks
Although setting a source or
destination address may seem like something difficult to get
wrong, it still happens quite often. There are, however, a
number of things that make correctly selecting source and
destination addresses more complex: - Running NAT on the
router
- Using complex wildcard masks to select
patterns of addresses
If the router is running both
access lists and NAT, the order in which each of these
technologies is applied to a traffic flow is important. The
order of operations in the switching path is quite complex, as
shown in Figure . The important points to remember here are:
- Inbound traffic is processed by the inbound access
list before being processed by outside-to-inside NAT.
- Outbound traffic is processed by the outbound access list
after being processed by inside-to-outside NAT.
Wildcard masks are typically used to select ranges of
addresses. For example, the address 198.162.10.0 and wildcard
mask 0.0.0.255 could be used to select all hosts in the Class C
network address-space 198.162.10.0. Generally, these sorts of