Monday, April 17, 2017
Wednesday, April 24, 2013
Tuesday, April 2, 2013
IPv6 OSPF Configuration lab
This short lab should provide some exposure to configuring OSPF for IPv6 under IOS. OSPFv3 is to IPv6 as OSPFv2 is to IPv4, and the two OSPF versions are not compatible with one another. The two protocols can be run simultaneously to support parallel (but separate) IPv6 and IPv4 routing domains, but the lab provided here will cover only OSPFv3.
Since the 2001:db8:0:3::/64 and 2001:db8:0:4::/64 subnets have no neighboring OSPFv3 routers, we'll designate the F0/1 interfaces on R3 and R4 as passive to protect against malicious or accidental adjacency formation.
Area configuration is still performed under the OSPF process. Here we'll configure area 2 as a stub since it has only one connection to the backbone. (This won't have any affect on our internal OSPF routes, but will cause the ABR R3 to inject a default route into the the area.) Be sure to apply the stub configuration to both routers 3 and 4.
IPv6 Addressing
The first step in base configuration is to enable IPv6 unicast routing:R1(config)# ipv6 unicast-routingNext we'll need to assign IPv6 addresses to the necessary interfaces. IPv6 stateless address autoconfiguration (RFC 4862) allows the interface ID portion of the address to be automatically formed from an EUI-64 address. We'll take advantage of this by appending the
eui-64 keyword to the ipv6 address command and leaving the interface ID portion of the IPv6 address zeroed.R1(config)# interface f0/1 R1(config-if)# ipv6 address 2001:db8:0:12::/64 eui-64Although we could address our serial interfaces in the same manner, setting the interface ID manually makes it easier to define the static frame relay mappings. We'll also have create frame relay mappings for the link-local (FE80::/10) addresses, so we may as well manually specify the interface IDs of those addresses as well.
R1(config)# interface s1/0 R1(config-if)# ipv6 address 2001:db8::1/64 R1(config-if)# ipv6 address fe80::1 link-localCreating IPv6 frame relay mappings is very similar to the commands issued for IPv4 addresses. The most important detail to remember is that link-local interface addresses must also be mapped, as all OSPFv3 communication takes places across these addresses.
R1(config-if)# encapsulation frame-relay R1(config-if)# no frame-relay inverse-arp R1(config-if)# frame-relay map ipv6 2001:db8::3 103 R1(config-if)# frame-relay map ipv6 2001:db8::2 103 R1(config-if)# frame-relay map ipv6 fe80::3 103 broadcast R1(config-if)# frame-relay map ipv6 fe80::2 103We can verify that each interface has both a link-local address and our configured global unicast address assigned:
R1# show ipv6 interface brief ... FastEthernet0/1 [up/up] FE80::C001:47FF:FEFD:1 2001:DB8:0:12:C001:47FF:FEFD:1 Serial1/0 [up/up] FE80::1 2001:DB8::1 ...Likewise, we can verify our frame relay mappings as we would with IPv4:
R1# show frame-relay map | include Serial1/0 Serial1/0 (up): ipv6 FE80::2 dlci 103(0x67,0x1870), static, Serial1/0 (up): ipv6 FE80::3 dlci 103(0x67,0x1870), static, Serial1/0 (up): ipv6 2001:DB8::2 dlci 103(0x67,0x1870), static, Serial1/0 (up): ipv6 2001:DB8::3 dlci 103(0x67,0x1870), static,Once all interfaces on routers have been addressed, it's a good idea to verify connectivity across individual links before moving onto OSPF configuration. You can ping global unicast IPv6 addresses just like IPv4 addresses, but notice that you are prompted for the outgoing interface when pinging a link-local address. This is because the router has no way of knowing which link you want to reach.
R1# ping fe80::2 Output Interface: serial1/0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to FE80::2, timeout is 2 seconds: Packet sent with a source address of FE80::1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/18/36 ms
Configuring OSPFv3
OSPFv3 differs from its predecessor in a number of ways, as we'll see in the following configurations. The first step, of course, is to enable the OSPF process:R1(config)# ipv6 router ospf 1If you have console logging enabled, you may notice this message pop up:
%OSPFv3-4-NORTRID: OSPFv3 process 1 could not pick a router-id, please configure manuallyAlthough OSPFv3 deals solely with IPv6 addresses, it still uses 32-bit router IDs, which are expressed in dotted-decimal (IPv4) format. Since we haven't configured any IPv4 interfaces in our lab, we'll need to define the OSPFv3 router IDs manually on each router:
R1(config-rtr)# router-id 1.1.1.1Although formatted as an IPv4 address, the router ID is an arbitrary value used to identify an OSPF router to its neighbors.
Since the 2001:db8:0:3::/64 and 2001:db8:0:4::/64 subnets have no neighboring OSPFv3 routers, we'll designate the F0/1 interfaces on R3 and R4 as passive to protect against malicious or accidental adjacency formation.
R3(config-rtr)# passive-interface f0/1
R4(config-rtr)# passive-interface f0/1Next we'll need to assign interfaces to OSPF areas. Unlike OSPFv2, which used the
network command under the router process to assign subnets to areas, OSPFv3 area assignments are made under interface configuration.R1(config)# interface s1/0 R1(config-if)# ipv6 ospf 1 area 0 R1(config-if)# interface f0/1 R1(config-if)# ipv6 ospf 1 area 1Be sure to set the DR priorities appropriately for frame relay interfaces, to ensure that R3 (the multipoint hub) becomes the DR. You might also want to set the priorities for the other two frame relay routers to zero.
R3(config)# interface s1/0 R3(config-if)# ipv6 ospf priority 100Since our frame relay cloud is a non-broadcast multiaccess (NBMA) link, we'll need to manually configure our OSPF neighbors on the hub. Like area assignment, this is done under interface configuration. Each neighbor must be listed with its link-local address.
R3(config-if)# ipv6 ospf neighbor fe80::1 R3(config-if)# ipv6 ospf neighbor fe80::2Notice that the priority and neighbor configurations do not specify the OSPF process like the area assignments do; if multiple OSPFv3 processes are running, interface priority and neighbor configurations affect all of them.
Area configuration is still performed under the OSPF process. Here we'll configure area 2 as a stub since it has only one connection to the backbone. (This won't have any affect on our internal OSPF routes, but will cause the ABR R3 to inject a default route into the the area.) Be sure to apply the stub configuration to both routers 3 and 4.
R3(config)# ipv6 router ospf 1 R3(config-rtr)# area 2 stub
R4(config)# ipv6 router ospf 1 R4(config-rtr)# area 2 stub
Verification
If everything is configured properly, all routers should now have full reachability via IPv6. We can inspect a router's neighbor adjacencies with theshow ipv6 ospf neighbor command:R3# show ipv6 ospf neighbor Neighbor ID Pri State Dead Time Interface ID Interface 2.2.2.2 1 FULL/BDR 00:01:34 6 Serial1/0 1.1.1.1 1 FULL/DROTHER 00:01:44 6 Serial1/0 4.4.4.4 1 FULL/DR 00:00:33 4 FastEthernet0/0Similarly, we can inspect the IPv6 routing table of R4 to verify it has received all OSPF routes, including the default route (::/0) injected into area 2 from R3.
R4# show ipv6 route IPv6 Routing Table - 10 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP U - Per-user Static route I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2 ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 D - EIGRP, EX - EIGRP external OI ::/0 [110/11] via FE80::C003:48FF:FE10:0, FastEthernet0/0 OI 2001:DB8::/64 [110/74] via FE80::C003:48FF:FE10:0, FastEthernet0/0 O 2001:DB8:0:3::/64 [110/20] via FE80::C003:48FF:FE10:0, FastEthernet0/0 C 2001:DB8:0:4::/64 [0/0] via ::, FastEthernet0/1 L 2001:DB8:0:4:C004:48FF:FE10:1/128 [0/0] via ::, FastEthernet0/1 OI 2001:DB8:0:12::/64 [110/84] via FE80::C003:48FF:FE10:0, FastEthernet0/0 C 2001:DB8:0:34::/64 [0/0] via ::, FastEthernet0/0 L 2001:DB8:0:34:C004:48FF:FE10:0/128 [0/0] via ::, FastEthernet0/0 L FE80::/10 [0/0] via ::, Null0 L FF00::/8 [0/0] via ::, Null0Beyond what was demonstrated here, you'll find the majority of OSPFv3 configuration commands are nearly identical to those of its predecessor. If you've configured OSPFv2 routing in the past and have a solid grasp of IPv6, OSPFv3 shouldn't give you any trouble.
OSPFv3 Neighbor Authentication
Most IPv4 routing protocols support some form of neighbor authentication, provided by either a plaintext password or MD5 HMAC. However, OSPFv3 (OSPF for IPv6) doesn't include any authentication capabilities of its own; instead, it relies entirely on IPsec to secure communications between neighbors. This is beneficial in simplifying the OSPFv3 protocol and standardizing its authentication mechanism.
Continuing from our OSPFv3 configuration lab, we can identify several points in the network where adding authentication would be prudent. In the real world, of course, it's considered best practice to implement authentication for all adjacencies, regardless of the apparent need.
First, because end users may be present in the 2001:db8:0:12::/64 subnet connecting R1 and R2, adjacency authentication in this subnet is critical. Second, since a diligent network engineer never trusts his service provider, we'll also implement authentication across the frame relay network. The IPsec Authentication Header (AH) protocol will be used to preserve packet integrity. Unfortunately, IOS doesn't currently support IPsec payload encryption via Encapsulating Security Payload (ESP). ESP can be configured with null encryption, but this has the same affect as configuring AH.
The first parameter to specify is the Security Policy Index (SPI). The SPI functions similarly to key numbers in a key chain, but is communicated via AH and must match between both ends of the adjacency. The SPI number is arbitrary, but must be between 256 and 4,294,967,295 (the 32-bit ceiling). We'll use the SPI of 256 for our lab.
Next we must decide on the type of authentication and the key string to use. AH provides authentication via either MD5 or SHA1, with a string length of 128 or 160 bits, respectively. Since SHA1 is the stronger algorithm, we'll choose it, and specify a random bit string as our key. Note that the key lengths must be exact: 40 hex digits (or 32 for MD5). For reasons outlined in section 7 of RFC 4552, the same keying is used for the SA in each direction between two OSPFv3 neighbors; this is in contrast to normal IPsec implementations, in which each unidirectional SA is built from its own unique keying via IKE.
Continuing from our OSPFv3 configuration lab, we can identify several points in the network where adding authentication would be prudent. In the real world, of course, it's considered best practice to implement authentication for all adjacencies, regardless of the apparent need.
First, because end users may be present in the 2001:db8:0:12::/64 subnet connecting R1 and R2, adjacency authentication in this subnet is critical. Second, since a diligent network engineer never trusts his service provider, we'll also implement authentication across the frame relay network. The IPsec Authentication Header (AH) protocol will be used to preserve packet integrity. Unfortunately, IOS doesn't currently support IPsec payload encryption via Encapsulating Security Payload (ESP). ESP can be configured with null encryption, but this has the same affect as configuring AH.
Enabling Authentication on the Interface
Currently, IOS requires IPsec for OSPFv3 be configured separate from the normal configuration of an IPsec policy; fortunately the entire configuration is accomplished with one line. As with legacy authentication, IPsec authentication can be configured either per-interface or per-area. We'll configure per-interface authentication between R1 and R2.The first parameter to specify is the Security Policy Index (SPI). The SPI functions similarly to key numbers in a key chain, but is communicated via AH and must match between both ends of the adjacency. The SPI number is arbitrary, but must be between 256 and 4,294,967,295 (the 32-bit ceiling). We'll use the SPI of 256 for our lab.
Next we must decide on the type of authentication and the key string to use. AH provides authentication via either MD5 or SHA1, with a string length of 128 or 160 bits, respectively. Since SHA1 is the stronger algorithm, we'll choose it, and specify a random bit string as our key. Note that the key lengths must be exact: 40 hex digits (or 32 for MD5). For reasons outlined in section 7 of RFC 4552, the same keying is used for the SA in each direction between two OSPFv3 neighbors; this is in contrast to normal IPsec implementations, in which each unidirectional SA is built from its own unique keying via IKE.
R1(config-if)# ipv6 ospf authentication ipsec spi 256 sha1 24e692732d80fac4f6dc2b9abfb73678ef660babIf you're feeling especially lazy, you can generate an SHA1 hash from random data with
dd and sha1sum on a Linux or UNIX box:LinuxBox$ dd if=/dev/urandom count=1024 | sha1sum 954644a966d69bc14f6148b0be865b803f3bc9c9 - 1024+0 records in 1024+0 records out 524288 bytes (524 kB) copied, 0.0940048 s, 5.6 MB/sAfter configuring authentication on FastEthernet0/1 at both routers, you may notice the OSPFv3 adjacency drop and reform. The OSPFv3 interface display verifies that SHA1 authentication is in use:
R1# show ipv6 ospf interface f0/1 FastEthernet0/1 is up, line protocol is up Link Local Address FE80::1, Interface ID 5 Area 1, Process ID 1, Instance ID 0, Router ID 1.1.1.1 Network Type BROADCAST, Cost: 10 SHA1 authentication SPI 256, secure socket UP (errors: 0) Transmit Delay is 1 sec, State BDR, Priority 1 Designated Router (ID) 2.2.2.2, local address FE80::2 Backup Designated router (ID) 1.1.1.1, local address FE80::1 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:03 Index 1/1/1, flood queue length 0 Next 0x0(0)/0x0(0)/0x0(0) Last flood scan length is 6, maximum is 6 Last flood scan time is 4 msec, maximum is 4 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 2.2.2.2 (Designated Router) Suppress hello for 0 neighbor(s)Incidentally, we can also verify the state of the IPsec AH security associations in use:
R1# show crypto ipsec sa
interface: FastEthernet0/1
Crypto map tag: (none), local addr FE80::1
IPsecv6 policy name: OSPFv3-1-256
IPsecv6-created ACL name: FastEthernet0/1-ipsecv6-ACL
...
inbound ah sas:
spi: 0x100(256)
transform: ah-sha-hmac ,
in use settings ={Transport, }
conn id: 1, flow_id: SW:1, crypto map: (none)
no sa timing
replay detection support: N
Status: ACTIVE
...
outbound ah sas:
spi: 0x100(256)
transform: ah-sha-hmac ,
in use settings ={Transport, }
conn id: 2, flow_id: SW:2, crypto map: (none)
no sa timing
replay detection support: N
Status: ACTIVE
Enabling Authentication for the Area
Configuring authentication for an area follows the same logic as for an interface. First we enter OSFPv3 router configuration, then specify the authentication parameters for the area:R1(config)# ipv6 router ospf 1 R1(config-rtr)# area 0 authentication ipsec spi 500 sha1 954644a966d69bc14f6148b0be865b803f3bc9c9Again, the SPI is an arbitrary value, and the key string must be the appropriate length for whichever hashing method (MD5 or SHA1) is chosen. The above configuration enables IPsec authentication for all of R1's interfaces in area 0 (which in our case is just Serial1/0). We can use the
show ipv6 ospf interface and show crypto ipsec sa commands as we did in the first section to verify OSPFv3 authentication is in use. The show crypto ipsec policy also provides a convenient overview of the authentication policies in use:R1# show crypto ipsec policy Crypto IPsec client security policy data Policy name: OSPFv3-1-256 Policy refcount: 1 Inbound AH SPI: 256 (0x100) Outbound AH SPI: 256 (0x100) Inbound AH Key: 24E692732D80FAC4F6DC2B9ABFB73678EF660BAB Outbound AH Key: 24E692732D80FAC4F6DC2B9ABFB73678EF660BAB Transform set: ah-sha-hmac Crypto IPsec client security policy data Policy name: OSPFv3-1-500 Policy refcount: 1 Inbound AH SPI: 500 (0x1F4) Outbound AH SPI: 500 (0x1F4) Inbound AH Key: 954644A966D69BC14F6148B0BE865B803F3BC9C9 Outbound AH Key: 954644A966D69BC14F6148B0BE865B803F3BC9C9 Transform set: ah-sha-hmac
Friday, January 18, 2013
Friday, March 2, 2012
FRAME RELAY
Frame Relay is a high-performance wide-area network (WAN) protocol that operates at the physical and data link layers of the Open System Interconnection (OSI) reference model.
Frame Relay was originally designed for use across Integrated Services Digital Network (ISDN) interfaces. Today, it is used over a variety of other network interfaces as well.
Frame Relay Features :
Frames Relay provides a data communications interface between user devices and network devices. This interface forms the basis for communication between user devices across a WAN.
Typical communication speeds for Frame Relay are between 56 Kbps and 2 Mbps (although lower and higher speeds are supported).
Frame Relay is considerably more efficient than X.25, the protocol for which it is often considered a replacement. Because it supports technological advances such as fibre-optic cabling and digital transmission, Frame Relay can eliminate time-consuming processes (such as error correction and flow control) that are necessary when using older, less reliable WAN media and protocols.
Frame Relay Standardisation
Internationally, Frame Relay was standardised by the International Telecommunications Union - Telecommunications Sector (ITU-T). In the United States, Frame Relay is an American National Standards Institute (ANSI) standard.
The Local Management Interface (LMI) specification, developed in 1990, further extends the functionality of Frame Relay.
Frame Relay Devices
Devices attached to a Frame Relay WAN fall into two general categories:
Data terminal equipment (DTE) -- DTE are customer-owned end node and internetworking devices. Examples of DTE devices are terminals, personal computers, routers, and bridges.
Data circuit-terminating equipment (DCE) -- DCE are carrier-owned internetworking devices. In most cases, these are packet switches (although routers or other devices can be configured as DCE as well).
DTE and DCE devices are logical entities. That is, DTE devices initiate a communications exchange, and DCE devices respond.
The following figure shows the relationship between the two categories of devices:
Frame Relay Virtual Circuits
Frame Relay provides connection-oriented data link layer communication. This service is implemented using virtual circuits.
A Frame Relay virtual circuit is a logical connection created between two data terminal equipment (DTE) devices across a Frame Relay packet-switched network (PSN).
Virtual circuits provide a bi-directional communications path from one DTE device to another. They are uniquely identified by a data link connection identifier (DLCI).
A virtual circuit can pass through any number of intermediate data circuit-terminating equipment (DCE) devices (switches) located within the Frame Relay PSN. A number of virtual circuits can be multiplexed into a single physical circuit for transmission across the network.
Frame Relay virtual circuits fall into two categories:
• Switched virtual circuit (SVC)
• Permanent virtual circuit (PVC)
Frame Relay Switched Virtual Circuits (SVCs)
A switched virtual circuit (SVC) is one of the two types of virtual circuits used in Frame Relay implementations. SVCs are temporary connections that are used when there is only sporadic data transfer between DTE devices across the Frame Relay network.
A communication session across an SVC consists of four operational states:
Call setup -- In this state, the virtual circuit between two Frame Relay DTE devices are established.
Data transfer -- In this state, data is being transmitted between the DTE devices over the virtual circuit.
Idle -- In this state, the connection between DTE devices is still active, but no data is being transferred.
Call termination -- In this state, the virtual circuit between DTE devices is terminated.
After the virtual circuit is terminated, the DTE devices must establish a new SVC if there is additional data to be exchanged.
Frame Relay Permanent Virtual Circuits (PVCs)
A permanent virtual circuit (PVC) is one of two types of virtual circuits used in Frame Relay implementations. PVCs are permanently established connections that are used when there is frequent and consistent data transfer between DTE devices across the Frame Relay network.
Communication across a PVC does not require the call setup and termination states that are used with SVCs.
PVCs are always in one of the following two operational states:
Data transfer -- In this state, data is being transmitted between the DTE devices over the virtual circuit.
Idle -- In this state, the connection between DTE devices is active, but no data is being transferred.
DTE devices can begin transferring data whenever they are ready because the circuit is permanently established.
Frame Relay Data Link Connection Identifier (DLCI)
Frame Relay virtual circuits are identified by data link connection identifiers (DLCIs). DLCI values are typically assigned by the Frame Relay service provider (for example, the Telephone Company).
Frame Relay DLCIs have local significance. That is, the values themselves are not unique in the Frame Relay WAN. Two DTE devices connected by a virtual circuit might use a different DLCI value to refer to the same connection.
The following figure shows how a single virtual circuit might be assigned a different DLCI value on each end of the connection:
Frame Relay was originally designed for use across Integrated Services Digital Network (ISDN) interfaces. Today, it is used over a variety of other network interfaces as well.
Frame Relay Features :
Frames Relay provides a data communications interface between user devices and network devices. This interface forms the basis for communication between user devices across a WAN.
Typical communication speeds for Frame Relay are between 56 Kbps and 2 Mbps (although lower and higher speeds are supported).
Frame Relay is considerably more efficient than X.25, the protocol for which it is often considered a replacement. Because it supports technological advances such as fibre-optic cabling and digital transmission, Frame Relay can eliminate time-consuming processes (such as error correction and flow control) that are necessary when using older, less reliable WAN media and protocols.
Frame Relay Standardisation
Internationally, Frame Relay was standardised by the International Telecommunications Union - Telecommunications Sector (ITU-T). In the United States, Frame Relay is an American National Standards Institute (ANSI) standard.
The Local Management Interface (LMI) specification, developed in 1990, further extends the functionality of Frame Relay.
Frame Relay Devices
Devices attached to a Frame Relay WAN fall into two general categories:
Data terminal equipment (DTE) -- DTE are customer-owned end node and internetworking devices. Examples of DTE devices are terminals, personal computers, routers, and bridges.
Data circuit-terminating equipment (DCE) -- DCE are carrier-owned internetworking devices. In most cases, these are packet switches (although routers or other devices can be configured as DCE as well).
DTE and DCE devices are logical entities. That is, DTE devices initiate a communications exchange, and DCE devices respond.
The following figure shows the relationship between the two categories of devices:
Frame Relay Virtual Circuits
Frame Relay provides connection-oriented data link layer communication. This service is implemented using virtual circuits.
A Frame Relay virtual circuit is a logical connection created between two data terminal equipment (DTE) devices across a Frame Relay packet-switched network (PSN).
Virtual circuits provide a bi-directional communications path from one DTE device to another. They are uniquely identified by a data link connection identifier (DLCI).
A virtual circuit can pass through any number of intermediate data circuit-terminating equipment (DCE) devices (switches) located within the Frame Relay PSN. A number of virtual circuits can be multiplexed into a single physical circuit for transmission across the network.
Frame Relay virtual circuits fall into two categories:
• Switched virtual circuit (SVC)
• Permanent virtual circuit (PVC)
Frame Relay Switched Virtual Circuits (SVCs)
A switched virtual circuit (SVC) is one of the two types of virtual circuits used in Frame Relay implementations. SVCs are temporary connections that are used when there is only sporadic data transfer between DTE devices across the Frame Relay network.
A communication session across an SVC consists of four operational states:
Call setup -- In this state, the virtual circuit between two Frame Relay DTE devices are established.
Data transfer -- In this state, data is being transmitted between the DTE devices over the virtual circuit.
Idle -- In this state, the connection between DTE devices is still active, but no data is being transferred.
Call termination -- In this state, the virtual circuit between DTE devices is terminated.
After the virtual circuit is terminated, the DTE devices must establish a new SVC if there is additional data to be exchanged.
Frame Relay Permanent Virtual Circuits (PVCs)
A permanent virtual circuit (PVC) is one of two types of virtual circuits used in Frame Relay implementations. PVCs are permanently established connections that are used when there is frequent and consistent data transfer between DTE devices across the Frame Relay network.
Communication across a PVC does not require the call setup and termination states that are used with SVCs.
PVCs are always in one of the following two operational states:
Data transfer -- In this state, data is being transmitted between the DTE devices over the virtual circuit.
Idle -- In this state, the connection between DTE devices is active, but no data is being transferred.
DTE devices can begin transferring data whenever they are ready because the circuit is permanently established.
Frame Relay Data Link Connection Identifier (DLCI)
Frame Relay virtual circuits are identified by data link connection identifiers (DLCIs). DLCI values are typically assigned by the Frame Relay service provider (for example, the Telephone Company).
Frame Relay DLCIs have local significance. That is, the values themselves are not unique in the Frame Relay WAN. Two DTE devices connected by a virtual circuit might use a different DLCI value to refer to the same connection.
The following figure shows how a single virtual circuit might be assigned a different DLCI value on each end of the connection:
Thursday, January 12, 2012
Access Control Lists (ACLs)
Access Control Lists (ACLs)
Access Control List (ACL) are filters that enable you to control which routing updates or packets are permitted or denied in or out of a network. They are specifically used by network administrators to filter traffic and to provide extra security for their networks. This can be applied on routers (Cisco).
ACLs provide a powerful way to control traffic into and out of your network; this control can be as simple as permitting or denying network hosts or addresses. You can configure ACLs for all routed network protocols.
The most important reason to configure ACLs is to provide security for your network. However, ACLs can also be configured to control network traffic based on the TCP port being used.
How ACLs work
A router acts as a packet filter when it forwards or denies packets according to filtering rules. As a Layer 3 device, a packet-filtering router uses rules to determine whether to permit or deny traffic based on source and destination IP addresses, source port and destination port, and the protocol of the packet. These rules are defined using access control lists or ACLs.
To simplify how ACL or a router uses packet filtering work, imagine a guard stationed at a locked door. The guard's instruction is to allow only people whose names appear on a quest list to pass through the door. The guard is filtering people based on the condition of having their names on the authorized list.
When a packet arrives at the router, the router extracts certain information from the packet header and makes decisions according to the filter rules as to whether the packet can pass through or be dropped. Packet filtering process works at the Network layer of the Open Systems Interconnection (OSI) model, or the Internet layer of TCP/IP.
Why use ACLs
* Limits network traffic to increase network performance.
* ACLs provides traffic flow control by restricting the delivery of routing updates.
* It can be used as additional security.
* Controls which type of traffic are forwarded or blocked by the router.
* Ability to control which areas a client access.
Types of Access Control Lists
Standard access-list
Standard access lists create filters based on source addresses and are used for server based filtering. Address based access lists distinguish routes on a network you want to control by using network address number (IP). Address-based access lists consist of a list of addresses or address ranges and a statement as to whether access to or from that address is permitted or denied.
Example of the command syntax for configuring a standard numbered IP ACL:
R1(config)# access-list {1-99} {permit | deny} source-addr [source-wildcard]
i. The first value {1-99} specifies the standard ACL number range.
ii. The second value specifies whether to permit or deny the configured source IP address traffic.
iii. The third value is the source IP address that must be matched.
iv. The fourth value is the wildcard mask to be applied to the previously configured IP address to indicate the range.
Extended access lists
Extended access lists create filters based on source addresses, destination addresses, protocol, port number and other features and are used for packet based filtering for packets that traverse the network.
Example of the command syntax for configuring an extended numbered IP ACL:
Router(config)# access-list {100-199} {permit | deny} protocol source-addr [source-wildcard] [operator operand] destination-addr [destination-wildcard] [operator operand] [established]
i. Like the standard ACLs, the first value {100-199 or 2000 - 2699} specifies the ACL number range.
ii. The next value specifies whether to permit or deny according to the criteria that follows.
iii. The third value specifies protocol type ( IP, TCP, UDP, or other specific IP sub-protocols). The source IP address and wildcard mask determine traffic source. The destination IP address and its wildcard mask are used to indicate the final destination of the network traffic. When the destination IP address and mask are configured, the port number must be specified to match, either by number or by a well-known port name, otherwise all traffic to that destination will be dropped.
Standard and Extended access lists can be applied base on the use of ip access-list command.
Access lists use the deny or permit statement to define which packet is allowed or denied entry into a server or network.
Masks
Masks are used with IP addresses in IP ACLs to specify what should be permitted and denied. Masks in order to configure IP addresses on interfaces start with 255 and have the large values on the left side, for example, IP address 172.16.2.14 with a 255.255.255.0 mask. Masks for IP ACLs are the reverse, for example, mask 0.0.0.255. This is sometimes called an inverse mask or a wildcard mask. When the value of the mask is broken down into binary (0s and 1s), the results determine which address bits are to be considered in processing the traffic. A 0 indicates that the address bits must be considered (exact match); a 1 in the mask is a "no".
Note these ACL equivalents.
· The source/source-wildcard of 0.0.0.0/255.255.255.255 means "any".
· The source/wildcard of 10.1.1.2/0.0.0.0 is the same as "host 10.1.1.2".
If you subtract 255.255.255.0 (normal mask) from 255.255.255.255, it yields 0.0.0.255.
Wildcards
The command below defines an ACL that permits this network 192.168.1.0 0.0.0.255.
access-list acl_permit permit ip 192.168.1.0 0.0.0.255
Inbound traffic to the router is compared to access lists entries based on the order that the entries occur in the router. The router looks through the entries until it has a match. If the router found no match when it reaches the end of the list, the traffic is denied. For this reason, you should have the frequently hit entries at the top of the list. There is an implied deny for traffic that is not permitted. Single-entry access lists with only one deny entry has the effect of denying all traffic. You must have at least one permit statement in an ACL or all traffic is blocked.
Access lists implicitly deny all access that is not expressly permitted. The following line is auto-appended to all access-lists:
deny ip any any
If it is desirable to over-ride this implicit denial statement, enter a permit ip any any statement as the last entry in the access-list.
Access Control List (ACL) are filters that enable you to control which routing updates or packets are permitted or denied in or out of a network. They are specifically used by network administrators to filter traffic and to provide extra security for their networks. This can be applied on routers (Cisco).
ACLs provide a powerful way to control traffic into and out of your network; this control can be as simple as permitting or denying network hosts or addresses. You can configure ACLs for all routed network protocols.
The most important reason to configure ACLs is to provide security for your network. However, ACLs can also be configured to control network traffic based on the TCP port being used.
How ACLs work
A router acts as a packet filter when it forwards or denies packets according to filtering rules. As a Layer 3 device, a packet-filtering router uses rules to determine whether to permit or deny traffic based on source and destination IP addresses, source port and destination port, and the protocol of the packet. These rules are defined using access control lists or ACLs.
To simplify how ACL or a router uses packet filtering work, imagine a guard stationed at a locked door. The guard's instruction is to allow only people whose names appear on a quest list to pass through the door. The guard is filtering people based on the condition of having their names on the authorized list.
When a packet arrives at the router, the router extracts certain information from the packet header and makes decisions according to the filter rules as to whether the packet can pass through or be dropped. Packet filtering process works at the Network layer of the Open Systems Interconnection (OSI) model, or the Internet layer of TCP/IP.
Why use ACLs
* Limits network traffic to increase network performance.
* ACLs provides traffic flow control by restricting the delivery of routing updates.
* It can be used as additional security.
* Controls which type of traffic are forwarded or blocked by the router.
* Ability to control which areas a client access.
Types of Access Control Lists
Standard access-list
Standard access lists create filters based on source addresses and are used for server based filtering. Address based access lists distinguish routes on a network you want to control by using network address number (IP). Address-based access lists consist of a list of addresses or address ranges and a statement as to whether access to or from that address is permitted or denied.
Example of the command syntax for configuring a standard numbered IP ACL:
R1(config)# access-list {1-99} {permit | deny} source-addr [source-wildcard]
i. The first value {1-99} specifies the standard ACL number range.
ii. The second value specifies whether to permit or deny the configured source IP address traffic.
iii. The third value is the source IP address that must be matched.
iv. The fourth value is the wildcard mask to be applied to the previously configured IP address to indicate the range.
Extended access lists
Extended access lists create filters based on source addresses, destination addresses, protocol, port number and other features and are used for packet based filtering for packets that traverse the network.
Example of the command syntax for configuring an extended numbered IP ACL:
Router(config)# access-list {100-199} {permit | deny} protocol source-addr [source-wildcard] [operator operand] destination-addr [destination-wildcard] [operator operand] [established]
i. Like the standard ACLs, the first value {100-199 or 2000 - 2699} specifies the ACL number range.
ii. The next value specifies whether to permit or deny according to the criteria that follows.
iii. The third value specifies protocol type ( IP, TCP, UDP, or other specific IP sub-protocols). The source IP address and wildcard mask determine traffic source. The destination IP address and its wildcard mask are used to indicate the final destination of the network traffic. When the destination IP address and mask are configured, the port number must be specified to match, either by number or by a well-known port name, otherwise all traffic to that destination will be dropped.
Standard and Extended access lists can be applied base on the use of ip access-list command.
Access lists use the deny or permit statement to define which packet is allowed or denied entry into a server or network.
Masks
Masks are used with IP addresses in IP ACLs to specify what should be permitted and denied. Masks in order to configure IP addresses on interfaces start with 255 and have the large values on the left side, for example, IP address 172.16.2.14 with a 255.255.255.0 mask. Masks for IP ACLs are the reverse, for example, mask 0.0.0.255. This is sometimes called an inverse mask or a wildcard mask. When the value of the mask is broken down into binary (0s and 1s), the results determine which address bits are to be considered in processing the traffic. A 0 indicates that the address bits must be considered (exact match); a 1 in the mask is a "no".
Note these ACL equivalents.
· The source/source-wildcard of 0.0.0.0/255.255.255.255 means "any".
· The source/wildcard of 10.1.1.2/0.0.0.0 is the same as "host 10.1.1.2".
If you subtract 255.255.255.0 (normal mask) from 255.255.255.255, it yields 0.0.0.255.
Wildcards
The command below defines an ACL that permits this network 192.168.1.0 0.0.0.255.
access-list acl_permit permit ip 192.168.1.0 0.0.0.255
Inbound traffic to the router is compared to access lists entries based on the order that the entries occur in the router. The router looks through the entries until it has a match. If the router found no match when it reaches the end of the list, the traffic is denied. For this reason, you should have the frequently hit entries at the top of the list. There is an implied deny for traffic that is not permitted. Single-entry access lists with only one deny entry has the effect of denying all traffic. You must have at least one permit statement in an ACL or all traffic is blocked.
Access lists implicitly deny all access that is not expressly permitted. The following line is auto-appended to all access-lists:
deny ip any any
If it is desirable to over-ride this implicit denial statement, enter a permit ip any any statement as the last entry in the access-list.
Subscribe to:
Posts (Atom)