This chapter is from the book Show
Exam Prep QuestionsQuestion 1Which of the following passwords can be applied on a Cisco router?
Answers: B, C, D. Passwords on a Cisco router cannot start with a number, and they ignore the leading spaces after the keyword secret. You can have a password from 1 to 25 characters in length. Question 2Which of the following commands resulted in the output that is bolded: line con 0 exec-timeout 0 0 password 7 104D000A061843595F50 logging synchronous
Answer: C. The service password-encryption command uses the Cisco- proprietary Vigenere cipher to encrypt all the other passwords on the router except the enable secret password (which uses MD5). A, B, and D are incorrect because they have the wrong syntax. Question 3Which command can you use to ensure that all administrative interfaces stay active for a period of 5 minutes and 45 seconds only after the last session activity?
Answer: B. The exec-timeout in line configuration mode ensures that the administrative interface stays up for the specified duration after the last session activity. A is incorrect because the correct command is exec-timeout and not simply timeout. C and D are incorrect because you have to be in line configuration mode to execute the exec-timeout command. Question 4Which of the following commands on a Cisco router can you use to prevent a hacker from finding out which users are logged into the network device?
Answers: C, D. You can use the no ip finger and no service finger commands to prevent a hacker from finding out which users are logged into the network device. The no service finger command is a legacy command and works just the same as no ip finger. Question 5You have just configured the following access list and would like only these hosts to have Telnet access to the Central router. Which of the following commands will you use to make sure this implementation works? Central(config)#access-list 1 permit host 10.10.0.1 Central(config)#access-list 1 permit host 10.10.0.2
Answer: D. You use the access-class command in line configuration mode in an inbound direction to ensure that only hosts 10.10.0.1 and 10.10.0.2 are allowed to Telnet to the router. By default, all access lists have an implicit deny in the end, and because of that rule, only two hosts will be allowed Telnet access to the Central router. Eric Knipp, ... Edgar DanielyanTechnical Editor, in
Managing Cisco Network Security (Second Edition), 2002 Although there are times when we only need
to filter traffic based on the source address, more often than not we will need to match traffic with a higher level of detail. An option for more precise traffic-filtering control would be an extended IP access list. Here, both the source and destination address are checked. In addition, you also have the ability to specify the protocol and optional TCP or UDP port number to filter more precisely. In the following example, any field represented by {} is mandatory for the access list, while any
field represented by [] is optional. The format of an extended IP access list is: access-list access-list-number {permit | deny} protocol source source-wildcard [operator source-port] destination destination-wildcard [operator destination-port] [precedence
precedence-number] [tos tos] [established] [log | log-input] Bold items represent keywords that are part of the access list syntax. Table 4.4 lists the configuration for a standard IP access list. Table 4.4. Extended IP Access List Configuration
In the following access list, we get very specific about what host we want to access a particular network or host on a network. In the first three lines, we are permitting or allowing packets from individual hosts on subnet 172.16.130.0 to any host on network 10.0.0.0. In line 4, we are denying packets with the source address that belongs to subnet 172.16.130.0 to the destination of host 192.168.10.118. Line 5 tells us that we are permitting all IP packets with no concern of a source or destination address. The implicit deny all at the end of the list will never be matched against a packet because the previous permit statement will match all packets. In Figure 4.3, we would apply this access list on the serial 0 interface in the outbound direction as follows:  Figure 4.3. An Example Network Router(conflg)# interface serial 0 Router(config-if)# ip access-group 141 out An example of an extended access list is as follows: access-list 141 permit icmp host 172.16.130.88 10.0.0.0 0.255.255.255 access-list 141 permit tcp host 172.16.130.89 eq 734 10.0.0.0 0. 255.255.255 range 10000 10010 access-list 141 permit udp host 172.16.130.90 10.0.0.0 0.255.255.255 eq tftp access-list 141 deny ip 172.16.130.0 0.0.0.255 host 192.168.10.118 access-list 141 permit ip any any Table 4.5 describes the extended access list commands. Table 4.5. A Description of Access List Commands
Just as in our standard access list, the extended access list will require a hyphen between the words access and list. Next is the list number. Since we are referencing an extended IP access list, the numbers would range from 100 to 199. The access list number serves the same dual purpose here as we looked at earlier with the standard access list. The router must have a way to distinguish between access lists. The number performs this purpose along with tying the lines of an access list together and designates which access list the filter is part of The number also tells the router the type of access list. Desinging & Planning…Placement of Access ListsOften you have a few options about how to apply your access lists and stili achieve the same affect on the traffic flowing through the router, in the case of the previous example, access list 141 was applied outbound on the serial 0 interface. Because access list 141 was designed to only filter traffic originating from the 172.16.130.0 network, and not traffic from 172.17.0.0, this list could have been applied in the inbound direction on Ethernet 0. Both approaches will have the same affect on the traffic flowing through the router. There is a minor difference between these two approaches, though. When the ACL is applied outbound on the Serial0 interface, the traffic enters the Ethernet0 interface and is processed against the routing table. The packet is then passed to the outbound interface, where it is checked against any outbound ACLs. If the outbound interface is Serial 0, it checks packets against access list 141 and will permit or deny the traffic based on the rules defined in that list. When the ACL is applied inbound on the Ethernet0 interface, the traffic is permitted or denied before it is processed against the routing table. On a router under heavy traffic loads, this could make a considerable difference in the delay that is introduced because the router does not have to process packets that will be dropped by the outbound interface. Although inbound filtering has the advantage with respect to route processing, that does not necessarily make it the better way to apply access lists. Under different circumstances, you may want to prevent access to an external subnet from both Ethernet interfaces. In this case, it may be easier to apply the access lists in the outbound direction of Serial0 because packets from both Ethernet interfaces will have to pass through Serial0 to get to the external subnet. In other words, you are applying the access list to the bottleneck in traffic. Otherwise, you will have to keep two separate access lists, one specific for Ethernet0 and the other specific for Ethernet1. If the router is under light traffic loads, it may be easier to maintain a single access list. There is disagreement among network and security professionals about which approach is better, but neither approach should be considered better than the other in all cases. It is up to you to decide which is best for your situation. Keywords permit or denyA keyword permit or deny specifies to the router the action to be performed. For example, the keyword permit would allow the packet to exit or enter the interface, depending on whether you specify the filtering to be performed in or out. Again, this option provides the same function as in our standard access list. The last line of our extended access list example could have read as follows: access-list 141 permit ip any any ProtocolYou have the option of filtering several different protocols using the extended access list. The protocol field in the IP header is an 8-bit number that defines what protocol is used inside the IP packet. TCP and UDP are only two of the possible protocols that can be filtered on, although they are most common. Other protocols, such as ICMP and EIGRP, have their own protocol numbers because they are not encapsulated inside TCP or UDP. If we use a question mark when defining an access list, we can see the protocol numbers that have been defined by name inside the router. Router (config)#access-list 191 permit ? <0-255> An IP protocol number ahp Authentication Header Protocol eigrp Cisco's EIGRP routing protocol esp Encapsulation Security Payload gre Cisco's GRE tunneling icmp Internet Control Message Protocol igmp Internet Gateway Message Protocol igrp Cisco's IGRP routing protocol ip Any Internet Protocol ipinip IP in IP tunneling nos KA9Q NOS compatible IP over IP tunneling ospf OSPF routing protocol pcp Payload Compression Protocol pim Protocol Independent Multicast tcp Transmission Control Protocol udp User Datagram Protocol Protocols not on the preceding list may also be filtered with extended access lists, but they must be referenced by their protocol number. A full list of assigned IP protocol numbers can be found at www.iana.org/assignments/protocol-numbers. It is important to remember that the IP keyword in the protocol field matches all protocol numbers.You must use a systematic approach here when designing your access list. For example, if your first line in the access list permits IP for a specific address, and the second line denies UDP for the same address, the second statement would have no effect. The first line would permit IP, including all the above layers. An option here may be to reverse the order of the statements. With the statements reversed, UDP would be denied from that address and all other protocols would be permitted. Source Address and Wildcard-maskThe source address and source wildcard-mask perform the same function here as in a standard IP access list. So, in the preceding example we could have used the wildcard mask instead of the host and any keywords. The access list would then look as follows: access-list 141 permit ip 172.16.130.88 0.0.0.0 i0.0.0.0 0.255.255.255 access-list 141 permit ip 172.16.130.89 0.0.0.0 i0.0.0.0 0.255.255.255 access-list 141 permit ip 172.16.130.90 0.0.0.0 i0.0.0.0 0.255.255.255 access-list 141 permit ip 172.16.130.0 0.0.0.255 192.168.10.118 0.0.0.0 access-list 141 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 In the first three lines, we are permitting or allowing packets from individual hosts on subnet 172.16.130.0 to any host on network 10.0.0.0. In line 4, we are permitting packets with the source address that belongs to subnet 172.16.130.0 to the destination of host 192.168.10.118. Line 5 tells us that we are permitting all packets regardless of the source or destination address. Remember that standard IP access lists have a default mask of 0.0.0.0. This does not apply to extended access lists so we must specify one. Destination Address and Wildcard-maskThe destination address and wildcard-mask have the same effect and structure as the source address and wildcard-mask. So, here the keywords host and any are also available. You can utilize these keywords to specify any destination address as well as a specific destination without using the wildcard mask. Remember that extended access lists try a match on both source and destination. A common mistake here is trying to build an extended access list with the idea of only filtering the source address, and forgetting to specify the destination address. Source and Destination Port NumberMany times, we don’t want to deny all access to a particular server. When you put a Web server out on the Internet, you want everyone to be able to access it on port 80 (WWW), but you don’t want to allow access to any other ports, because it gives hackers the opportunity to exploit other services you may not be aware of (although you should know of them in the first place). Restricting access to this level of detail is another benefit of extended ACLs. We have the option of specifying a source and destination port number in the access list. Let’s look at a simple example: Router(config)# interface Serial 0 Router(config-if)# ip access-group 111 in Router(config)#access-list 111 permit tcp any host 172.17.11.19 eq 25 Router(config)#access-list 111 permit tcp any host 172.17.11.19 eq 23 These commands are explained in Table 4.6. Table 4.6. Router Commands
In line 1, we are permitting TCP packets from any source to the destination of host 172.22.11.19 if the destination port is 25 (SMTP). In line 2, we are permitting TCP packets from any source to the destination of host 172.22.11.19 if the destination port is 23 (Telnet). The implicit deny statement at the end of this access list will prevent all other traffic from making it into our network. Let’s take a look at filtering with TCP and UDP. When using TCP, for example, the access list will examine the source and destination port numbers inside the TCP segment header. So, when using an extended access list, you have the capability to filter to and from a network address and also to and from a particular port number. You have several options when deciding which operator to use, such as: ■eq equal to ■neq not equal to ■gt greater than ■lt less than ■range specifies an inclusive range or ports (Here, two port numbers are specified.) Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9781931836562500088 Configuring Cisco IDS BlockingIn Cisco Security Professional's Guide to Secure Intrusion Detection Systems, 2003 Step 2: Extended Access-ListsThese ACLs give us much more depth in how to control network traffic. Extended access-lists can be configured to check port number, protocol, and the destination address as well as the source address. The number assigned to an extended access-list is in the range of 100–199, and an expanded range of 2000–2699. Here is the basic format of an extended access-list: access-list access-list-number [permit|deny] protocol source ip address source-wildcard destination destination-wildcard [operator] Here is an example: access-list 190 deny TCP 172.16.1.0 0.0.0.255 172.16.2.0 0.0.0.255 neq 23 The extended access-list is different than the standard ACL in the following ways: ▪access-list-number This is a number within the range previously specified for the type of access-list being created. In this case, it is an extended access-list, as indicated by the 190. ▪protocol This allows us to filter based on a particular protocol—typically, IP for filtering by IP address or TCP for filtering by protocol. ▪destination This is the destination IP address a particular packet is trying to reach. In the example, it is the network address of 172.16.2.0. ▪destination-wildcard This works as the source-wildcard to indicate the host IP address or range of IP addresses trying to be reached. This saves the time of having to type lines for each IP address within a particular subnet. ▪Operator This can be used to indicate a port number when filtering by protocol, such as TCP or UDP. There are four options that can be used with this feature. ▪eq Equals—when we know exactly what port needs to be monitored ▪gt Greater than—allows us to specify a particular range over a particular port number ▪It Less than—allows us to specify a particular range lower than a particular port number ▪neq Not equal—allows us to assert the access-list to all but on port Let’s now see how this works on a network. Refer to Figure 8.3. Figure 8.3. Implementing an Extended Access-List Looking at this network example, imagine that all the clients need access to the e-mail server and only Client3 needs Telnet access to the payroll server. Our configuration would look similar to this: Router1 ! interface Ethernetl ip address 172.16.2.1 255.255.255.0 ip access-group 110 out ! access-list 110 permit tcp 172.16.1.30 any eq telnet access-list 110 deny tcp any 172.16.2.10 access-list 110 permit tcp 172.16.1.0 0.0.0.255 any ! This access-list configuration first allows Client3 to access to the Demilitarized Zone (DMZ) and specifically access the payroll server using Telnet (indicated by eq). The next line in the access-list is to deny anyone to access the payroll server. Notice this comes after the line that allows Client3 access to the same server. Remember, when the router finds the first match, it will stop reading and take action. The third line allows anyone from the internal network 172.16.1.0 to access any resource and any protocol, and so on, not already denied, on the DMZ. If a match is still not found, the implicit deny will drop all remaining network traffic trying to access the DMZ. One condition we used in the preceding configuration had to do with whether we applied the access-list to an internal or external interface and the particular direction of the traffic flow. In the last example, we can see the ACL was applied to an external interface, in relation to the internal network. We also have the command “out” used. This means that traffic trying to leave the router on the Ethernet1 interface will be checked. The first example, Figure 8.1, used an ACL on the Serial0 interface, applying the in command. This prevents the network traffic specified in the ACL from entering the router. The traffic is then dropped right at the front door. NOTEOnly one access-list can be applied to an interface/direction at a time. If another ACL is applied to the same interface/direction, the original ACL will be nullified. IP blocking relies on a system that will compare inbound and/or outbound IP datagrams on a particular interface to a list of signatures and trigger an alarm if a match is made. The alarm will indicate to the governing sensor that there is a threat. At this point, the sensor will create a new ACL and distribute that ACL to the network device providing access to the network in jeopardy. When the new ACL reaches the network device, it will replace the resident ACL with the newly arrived one, thus dynamically updating the network device. This process is referred to as Device Management. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9781932266696500288 RoutingBrad Woodberg, ... Ralph Bonnell, in Configuring Juniper Networks NetScreen & SSG Firewalls, 2007 Extended Access ListsThe access list is the core component which actually matches the traffic based upon the settings you configure. The access list used for PBR is called an extended access list because you can match upon more than just an IP address—for instance, several other attributes, and in any combination, as mentioned earlier. Remember that, like other types of access lists, these access lists are evaluated from the top down, until a match is found. Extended Access List PropertiesThe following list describes the different options you can configure to match traffic within the extended access list. ▪Virtual Router Access lists are configured at the VR level or below, so you must define what VR it will be a part of. ▪Sequence Number This allows you to define the placement of this statement within the access list you are creating. Since the access lists are evaluated top down, order is important. ▪Source IP Address / Netmask If you wish to match traffic on the source IP address, you can configure this component to match a host, or an entire subnet, depending on the subnet mask you specify. ▪Source Port This allows you to define a specific source port or range to match the traffic on. ▪Destination IP Address / Netmask This option allows you to match traffic based upon the destination IP address of the traffic. Depending on the subnet mask defined, you can match on a single host, or an entire subnet. ▪Destination Port You can configure a single destination port, or a range of destination ports to match upon. ▪Protocol This will match upon the actual protocol of the traffic since, technically, a port does not actually define which protocol travels over it. Without specifying which protocol you want to match, port 80 of TCP would be the same as port 80 UDP. For protocol, you can select TCP, UDP, ICMP, Any, or NULL. ▪IP-TOS You can define the traffic to match upon a predetermined IP-TOS value (1 to 255) of the traffic. The access list will check the packet to see if the bits are set, and then act accordingly. Tip Remember that you do not have to use all of the attributes in an access list. You can select to match on some attributes of a packet, and not on others. Also, since order is important within an access list, it is usually best to go from most specific to most general when ordering the statements. Configuring an Extended Access ListBefore you can begin to do policy-based routing, you must first configure the Extended Access List which will be used to match the traffic. In this example, we will match traffic that is from the source subnet 192.168.1.0/24, a destination subnet of 10.0.0.0/8, and a destination port 80 protocol TCP. To configure this example via the Juniper WebUI: 1.Select Network | Routing | PBR | Access List Ext. 2.In the upper right-hand corner, select the VR you want to create this Access list for and click New. 3.Define an Extended ACL ID to reference the extended access list by. 4.Each statement in the access list must have a Sequence No. it can be identified by, which you must define. This sequence number is important because the access list gets evaluated from the top down. 5.If you want to match traffic based upon the source IP address, you can define the Source IP Address/Netmask. 6.You can match a single Source Port or a range by entering the values into the fields. If you would like to match a single port, enter it in both fields. If you would like to match a range, enter the low port in the first field, and the high port in the second field. 7.If you would like to match a destination host or subnet, you can do so by specifying the Destination IP Address/Netmask. 8.Just like the source port, you can match a single Destination Port, or a range or destination ports. Enter the same number in both fields to match a single port, or a low port number in the first field, and a high number in the second to match a range. 9.If you would like to specify what Protocol to match the port on, you may specify either TCP, UDP, ICMP, or Any. If you do not match the port based upon protocol, you can leave it at Null. 10.If you would like to specify an IP-TOS value to match on packets, you can do that by defining the appropriate value. 11.Click OK. In this example, we are using the following values:
To configure this example via the Juniper CLI: To add an additional statement via the WebUI, go into the Extended Access List and click the Add Seq No. option. To add an additional statement via the CLI, all you have to do is define the next position with the entry <position> command at the end of the access-list statement. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9781597491181500095 Access Control ListsDale Liu, ... Luigi DiGrande, in Cisco CCNA/CCENT Exam 640-802, 640-822, 640-816 Preparation Kit, 2009 ACL Details and Examples■ Standard Access lists match only based on the source IP address of the packet. Extended Access lists can match on source and destination address, in addition to port, protocol, and many other fields. ■With extended ACLs, each protocol (ip/tcp/udp/icmp) has a different set of criteria that can be used for matching packets. This means the ACE syntax is unique to each protocol. ■Numbered ACLs have several limitations including the inability to reorder ACEs or add/remove a single ACE. ■Sequence numbers on named ACLs are used to add and remove individual ACEs, which resolves the limitations of numbered ACLs. ■Comments can be added to both named and numbered ACLs, but they managed as other ACEs and aren't tied to a specific ACE. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9781597493062000130 Intrusion DetectionEric Knipp, ... Edgar DanielyanTechnical Editor, in Managing Cisco Network Security (Second Edition), 2002 TCP Intercept ConfigurationsThis section covers the TCP Intercept feature available on Cisco routers that have Cisco Secure IS (Firewall Feature Set) installed. Here’s how you configure it: 1.Make certain you have the necessary IOS Firewall Feature Set installed. 2.Create an extended access list where the source is “any” and designate internal networks to protect against SYN flooding attack. 3.In global configuration mode, enter the command: ip tcp intercept list < access-list number > 4.Choose what mode you want to operate in. If you don’t specify it, it will be in intercept mode. In watch mode, the router “watches” TCP connection requests, if they do not become established within 30 seconds, the router sends a TCP RST to the receiving station, thus allowing it to free its resources. When operating in intercept mode, the router acts as a “middle man” in the TCP handshake. It will keep the original SYN request, and respond back to the originator with a SYN/ACK pending the final ACK. Once this happens, the router sends the original SYN and performs a three-way handshake with the destination, it then drops out of the way allowing direct communications between source and destination. To choose the mode, enter the command: ip tcp intercept mode [intercept|watch ] TCP intercept will monitor for the number of incomplete connections. When this figure goes over 1100, or if a “surge” of over 1100 connections is received within 60 seconds, the router deletes the oldest connection request (like a conveyor belt) and reduces TCP retransmission time by 50 percent. This “aggressive” behavior can be adjusted to fit security policy. For further information on TCP SYN flooding, visit www.cert.org/advisories/CA-96.21.tcp_syn_flooding.html. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9781931836562500179 Introduction to IP Network SecurityEric Knipp, ... Edgar DanielyanTechnical Editor, in Managing Cisco Network Security (Second Edition), 2002 Internetwork Layer SecurityThe easiest place to enforce a technical control is at the Internetwork layer—since you can inspect and forbid information from passing between separate networks and machines. Controlling access to the network with firewalls, routers, switches, remote access servers, and authentication servers can reduce the traffic getting to critical hosts to just authorized users and services. Security considerations can have an effect on the physical design of the network. Networks can be segmented to provide separation of responsibility. Departments, such as finance, research, or engineering, can be restricted so only the people that need access to particular resources can enter a network. You need to know the specifications that will be used to purchase network equipment, software features or revision levels that need to be used, and any specialized devices used to provide encryption, quality of service, or access control. You need to determine the resources to protect, the origin of threats against them, and where your network security perimeters should be located. Install devices and configurations at the perimeter—the internetwork layer between networks—that meets your security requirements. Jon Postel, one of the godfathers of the Internet, wrote: “be conservative in what you do, be liberal in what you accept from others.” Unfortunately, this principle of robustness has lead to security problems, particularly at the application and internetwork layers. At the Internetwork layer, it is important to validate the information you receive before routing. Of special importance is preventing simple fraud: a particularly pernicious problem today is based upon the smurf attack. This is a variant of the real-world “pizza order” attack, where you call a dozen pizza delivery companies and have them all deliver a pizza to someone’s home at the same time. In a smurf attack, one computer makes requests for service from a large number of sites on the behalf of another host. There are details in terms of minimization of the bandwidth consumed by the attacker and maximization of the tidal wave of responses that hits the victim host, but it’s all based upon sending outgoing requests as if for another person. If the pizza company could use caller ID to not accept requests from places other than where the call originates, the “pizza order” attack would fail. Similarly, if end routers did not route packets that could not have originated locally, the smurf attack would never get off the ground. In a modern internetworking environment, be cautious in what you accept from others; if it doesn’t make sense, log it and drop it. Access Control ListsAccess Control Lists (ACLs) are an effective way to address the filtering problem mentioned earlier. ACLs are packet filters that can be implemented on routers and similar devices to control the source and destination IP addresses allowed to pass through the gateway. Standard access lists can filter on source address. Extended access lists can filter ICMP, IGMP, or IP protocols at the Network layer. ICMP can be filtered based on the specific message. IP filtering can include port numbers at the transport (TCP/UDP) layer to allow or disallow specific services between particular addresses. Access lists can also control other routed protocols such as AppleTalk or IPX, and they are your first and best way to eliminate inappropriate traffic. Configuring & Implementing…Martian FilteringThe router requirements of RFC 1812 talk about "martian filtering," and notes "A router SHOULD NOT forwardany packet that has an invalid IP source address or a source address on network 0." Large chunks of IP space—not just the RFC 1918's of the 10, 172.16, and 192.168 networks, are invalid addresses and should be dropped. An effective way of achieving this is to null route the logon, tike this: ip route 1.0,0.0 255.0.0.0 null0 ip route 2.0.0.0 255.0.0.0 null0 ip route 5.0.0.0 255.0.0.0 null0 ip route 7.0.0.0 255.0.0.0 null0 ip route 10.0.0.0 255.0.0.0 null0 ip route 23.0.0.0 255.0.0.0 null0 ip route 27.0.0.0 255.0.0.0 null0 ip route 31.0.0.0 255.0.0.0 null0 ip route 36.0.0.0 255.0.0.0 null0 ip route 37.0.0.0 255.0.0,0 null0 ip route 39.0.0.0 255.0.0.0 null0 ip route 41. 0. 0.0 25 5.0.0.0 null0 ip route 42.0.0.0 255.0.0.0 null0 An extremely useful consensus document on secure router templates for the Internet is Rob Thomas' Secure IOS Template, available at www.cymru.com/~robt/Docs/Articles/secure-ios-template.html. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9781931836562500052 Internet Multicast and Multicast VPNs Based on MDLP In-Band SignalingVinod Joseph, Srinivas Mulugu, in Deploying Next Generation Multicast-enabled Applications, 2011 5.2.7.2 Command DetailsThis section provides an in-depth view of all of the available IOS commands associated with MLDP configuration. 5.2.7.2.1 [no] mpls MLDPMLDP is enabled by default, and this command disables the MLDP process. The “no” form of the command will appear in the running-config. [no] mpls MLDP forwarding recursive MLDP has two ways to resolve the next-hop used for forwarding labeled packets. Without this command enabled MLDP resolves the outgoing interface based on the next-hop to the downstream LSR. If mpls MLDP forwarding recursive is configured, the outgoing interface is resolved by the MFI using P2P LSPs. Then MLDP uses recursive forwarding over a P2P LSP. That means a P2P LSP for the next-hop needs to be available in the MFI. This configuration needs to be enabled to make MLDP FRR back up over a TE tunnel when possible. Recursion will be enabled by default, and the no form of the command will appear in the running-config. 5.2.7.2.2 [no] mpls MLDP multipath upstreamIf there are multiple paths available to reach the root of an MP-LSP, we use an algorithm to select a path such that we are load balancing different LSPs over the available paths. The algorithm used to influence the paths selection calculates a 32-bit CRC of the total FEC length of the LSP, and then does a “crc32_value mod number_of_paths.” The result of this calculation identifies the path. If this command is disabled the path with the highest next-hop IP address is used to reach the root. 5.2.7.2.3 [no] mpls MLDP multipath downstreamIf there are multiple downstream paths to reach an LDP peer we load balance the branches of the LSPs over these paths. The assignment of the downstream paths to the LSPs is done in a circular way. If this command is disabled, the path with the highest next-hop IP address is used. 5.2.7.2.4 [no] ip(v6) multicast mpls MLDP range <acl>This command enables transit IPv4 or IPv6 multicast over an MLDP built P2MP LSP. Using the <acl>, an access-list can be configured to enable transit service for a specific set of multicast stream(s). The ACL is a named or extended access-list that can be filter based on source and/or group. This command needs to be configured on the egress PE as well as the ingress PE, but the ACL only has an effect on those sources for which this PE is the egress. 5.2.7.2.5 [no] IP Multicast mpls Traffic-eng [Range <acl>]This command enabled transit IP4 multicast over an RSVP-TE built P2MP LSP. Using the <acl>, an access-list can be configured to enable transit service for a specific set of multicast stream(s). The ACL is a named or extended access list that can filter based on source and/or group. This command needs to be configured only on the egress PE. 5.2.7.2.6 [no] IP Multicast vrf <vrf name> mpls MLDP Range <acl>This command enables transit VPNv4 multicast over a P2MP LSP. Using the <acl>, an access-list can be configured to enable transit service for a specific set of multicast stream(s). The ACL is a named or extended access list that can filter based on source and/or group. This command needs to be configured on the egress PE as well as the ingress PE, but the ACL only has an effect for which sources this PE is the egress. 5.2.7.2.7 [no] IP(v6) pim mpls Source <interface>For transit multicast service a virtual interface (LSP-VIF) is created as head- and tail-end of the tunnel to interact with PIM. This interface is created automatically on demand and is configured to be unnumbered with an interface on the router that is configured with an IPv4 or IPv6 address. This command is used to configure the interface that is used as an unnumbered interface for the virtual interface. Without this command a virtual interface will not be created. This command needs to be configured in combination with IP Multicast mpls MLDP and IP Multicast mpls traffic-eng. 5.2.7.2.8 [no] mdt Default mpls MLDP <ip-address-of-root>This command specifies that the Default MDT should be constructed using MLDP. By default MLDP uses an MP2MP LSP to build the default MDT. An IP address must be given that specifies the root of the MP2MP tree. Multiple commands such as these may be entered for the same VPN and FEC-ID but with different Root addresses. When multiple commands such as these are configured, MLDP automatically uses root node redundancy procedure for this MP2MP LSP. 5.2.7.2.9 [no] mdt Data mpls MLDP <# data-mdts> Threshold <kbps>The existing mdt data CLI is extended to take the mpls MLDP keyword. When specified it indicates that the Data MDTs for the VRF should be signaled via MLDP. In addition, by default Data MDTs are P2MP Trees rooted at the tree that initiates the MDT switchover. The user also configures the number of Data MDTs that he or she wants the VPN to use. The threshold keyword is used to supply a rate in kilobits per second. If the traffic rate for a given stream is above the threshold rate, it is switched over to use a Data MDT. 5.2.7.2.10 [no] mdt Preference [pim] [MLDP]For MVPN migration strategy we allow PIM MDTs to be configured parallel to MLDP MDTs. To influence the path selection in the mroute table we can use this command to give preference to a certain tree type. If this command is not configured then PIM is preferred over MLDP. The order in which the keywords “pim” and “MLDP” are entered gives the preference. The first keyword has the higher preference. 5.2.7.2.11 show mpls MLDP databaseThis command shows the MLDP database. It also shows the FEC, the opaque value of the FEC decoded (if the router understands it), and the replication clients associated with it. 5.2.7.2.12 show mpls MLDP database id <LSD ID>This command shows an entry in the MLDP database using the hexadecimal LSM system ID. 5.2.7.2.13 show mpls MLDP database id opaque_type <Type>This command shows an entry in the MLDP database using the opaque type, which can consist of multiple fields that can be used to refine the selection. Supported types include: •IPv4 <source> <group> •IPv6 <source> <group> •mdt <VPN ID> <MDT number> •VPNv4 <source> <group> <RD> •<Type number> 5.2.7.2.14 show mpls MLDP neighborsThis command displays the MLDP Peers known to the router. It displays the identity address, which is the address used to create the LDP TCP peering. It also displays information about next-hop, interface, LDP graceful restart status, and uptime. 5.2.7.2.15 show mpls MLDP label releaseThis command displays labels that are withdrawn and pending to be released to the system. 5.2.7.2.16 show mpls MLDP rootThis command displays the root data structure. The root is a common entry between multiple LSPs. 5.2.7.2.17 show IP Multicast mpls vifThis command shows the virtual interfaces that are created on the router. Interfaces are identified by an addrtype address. 5.2.7.2.18 show IP Multicast mpls mrib-client [ipv4] [ipv6] and show IP Multicast vrf <vrf-name> mrib-client [ipv4] [ipv6]These commands display the routes, which the MLDP PE function has learned from the IPv4 MRIBs. These are the routes for which MLDP Multipoint LSPs are set up. Also these routes are signaled via MLDP in-band signaling. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9780123849236000053 Class-of-Service Requirements for Quad-Play NetworksVinod Joseph, Brett Chapman, in Deploying QoS for Cisco IP and Next Generation Networks, 2009 3.11 Broadcast Video: Internet Protocol TelevisionThe Broadcast Video service class is to be used for inelastic (instantaneous rate) traffic flows, which are intended for broadcast TV service and for transport of live video and audio events. By definition, Internet Protocol Television (IPTV) is categorized as a Broadcast Video application. IPTV delivers television programming to households via a broadband connection using Internet protocols. It requires a subscription and IPTV set-top box. IPTV is typically bundled with other services such as Video on Demand (VoD), Voice over IP (VoIP) or digital phone, and Web access, collectively referred to as triple play. IPTV uses Internet protocols to provide two-way communication for interactive television. One application might be in game shows in which the studio audience is asked to participate by helping a contestant choose between answers. IPTV opens the door to real-time participation from people watching at home. Another application involves the ability to turn on multiple angles of a sporting event, such as a touchdown, and watch it from dual angles simultaneously using picture-in-picture viewing. SPs typically offer multiple broadcast video channels for end users or subscribers connected to the network. In IPTV deployments, each broadcast video channel has a separate multicast group address. Users are provided access to the broadcast video channels in MPEG2/MPEG4 codec/s in SD/HD format, with each channel consuming bandwidth dependent on the type of codec or format. IP Multicast technology is used to optimize the bandwidth requirements in the network. IP Multicast enables one-to-many communication in which multiple broadcast video clients (set-top boxes, or STBs) can receive the same stream from a video encoder/server. To receive a multicast stream, a client must have access to a multicast-enabled network. Hence the hardware and software in the network need to support the required features for transporting multicast packets. 3.11.1 IPTV Bandwidth RequirementsA standard-definition IP video stream that is carried as an MPEG4 SPTS stream uses about 2 to 2.75 Mbps of bandwidth. A high-definition IP video stream using the same type of compression and transport uses about 8 to 9 Mbps of bandwidth. These bandwidth requirements mean that the access infrastructure that is designed for real-time video transport must be capable of carrying significantly more bandwidth than what is needed for VoIP and Internet access services. For example, assuming that the access infrastructure is DSL based, the DSL line itself is typically constrained to carrying only one or two video streams simultaneously. The result is that video-over-DSL service offerings must limit the service to one or two simultaneous broadcast channels per household. Since broadcast video services use multicast, the amount of bandwidth required in the access and distribution networks scales with the number of channels offered. For example, a broadcast video service that uses MPEG4 compression and offers 100 channels of standard-definition content requires around 1 Gbps of capacity in the SP distribution network to handle worst-case usage patterns. Multicast Admission Control mechanisms can also be used to limit or control bandwidth usage, as discussed in the following section. IGMP LimitSPs can enforce a maximum broadcast bandwidth limit by limiting the number of Internet Group Management Protocol (IGMP) joins on the ranges of multicast addresses associated with broadcast video to a configured maximum on the aggregation links that the router controls. The ip igmp limit command can be used to configure a limit on the number of IGMP states resulting from IGMP membership reports on a per-system or per-interface basis. It controls the maximum number of IGMP states allowed on a router or interface. Membership reports sent after the configured limits have been exceeded are not entered in the IGMP cache, and traffic for the excess membership reports is not forwarded. Per-interface and per-system limits operate independently of each other and can enforce different configured limits. A membership state will be ignored if it exceeds either the per-interface limit or the global limit. If you do not configure the except access-list keyword and argument, all IGMP states resulting from IGMP are counted toward the configured cache limit on an interface. The except access-list keyword and argument exclude particular groups or channels from counting toward the IGMP cache limit. An IGMP membership report is counted against the per-interface limit if it is permitted by the extended access list specified by the except access-list keyword and argument. The command use is illustrated here. IGMP Limits ! ip igmp limit <number> [except access-list] (Enables per-system IGMP limit) ! interface GigE x/y (Enables per-interface IGMP limit. DSLAM-facing intf) ip igmp limit <number> [except access-list] ! 3.11.2 IPTV Latency Jitter and Loss RequirementsTo be considered optimal, IPTV (broadcast video) needs to achieve a latency of <150 ms one way. From a jitter standpoint, a value of <50 ms is required to provide consistent quality and a favorable user experience. Coming to packet loss, the packet-loss ratio (PLR) should be well within the <10−6 mark. To elaborate on this a little further, when broadcast and on-demand video (VoD, detailed in the next section) is carried over an IP network, there is an assumption that the video quality the subscriber experienced is comparable to that experienced by people watching MPEG4 video carried by cable and satellite networks today. To ensure that any degradation in video quality resulting from the IP transport network is negligible from a subscriber’s point of view, most SPs allow only one visible degradation in video quality roughly every two hours. Though this allowance is similar to what is allowed for VoIP services, the resulting allowed packet-drop requirement for an IP transport network designed for video services is much more stringent. There are two reasons for this: •Video is much more highly compressed, so losing a packet may result in the loss of more valuable encoded video information. If the network drops a single video packet, there is a visible degradation of video quality of anywhere from a single frame up to a loss of 1 second of video, depending on the kind of encoded information that is lost. •The receiving decoders, such as the STBs, generally do not have loss-concealment algorithms, whereas VoIP phones and gateways typically support algorithms that conceal dropouts in the voice signal caused by lost packets. In the VoIP case, the network can drop a single voice packet without the listener perceiving any degradation in voice quality—unlike the case for video. The DiffServ architecture needs to ensure that video flows meet the required 10−6 drop rate, even when links are congested. Packet drops due to bit errors on physical links must be addressed on a link-by-link basis. The link-layer technologies used in video networks employ cyclic redundancy check (CRC) algorithms to ensure that packets with errors are not delivered. This means that a single bit error in a video packet results in that packet being dropped when a CRC is performed. VoIP is typically carried in packets of approximately 1400 bytes. If bit errors are assumed to be distributed randomly, the resulting requirement for transport links is to ensure a bit-error rate (BER) less than 10−10. The BER on optical links can be engineered to 10−14 or less by ensuring a high signal-to-noise ratio (SNR) on those links. If optical connectivity is used in the access and distribution networks, degradation in video quality resulting from bit errors on these links should not be an issue. However, packet drops due to bit errors on links such as DSL can have a significant effect on video quality. The SNR on a DSL line varies as a result of many factors, including loop length, proximity to noise sources, and other factors. In addition, the SNR can vary over time because of factors such as corrosion at connection points, moisture, and so on. Consequently, it might be difficult to qualify a DSL line at the time of installation to ensure a BER of less than 10−10 over the life of the video service. 3.11.3 Classifying and Queuing Broadcast Video/IPTVBroadcast video uses DSCP class selector CS3 as the classification criterion, as per the Cisco modified RFC-4594 model. However, due to the fact that Cisco marks Call Signaling traffic to CS3, the Cisco modified RFC-4594 model swaps Call Signaling with broadcast video, as mentioned in the earlier sections. Hence IPTV traffic is classified using CS5 instead of CS3. Broadcast video needs to be assigned to a second EF queue (LLQ) on Cisco platforms that support dual-priority queues due to the strict latency, jitter, and packet-loss requirements. Alternately, on platforms that do not support dual-priority queues, broadcast video can be assigned to a dedicated class for video traffic. Some of the characteristics needed for this class are as follows: •The Broadcast Video queue should never be oversubscribed. Oversubscription has the potential to drop traffic during congestion, which would have a negative impact on many channels of video traffic. •Broadcast video traffic should not be combined with data traffic and hence needs a dedicated QoS queue. Other video applications such as Video on Demand (described in the next section) could optionally be combined with this traffic type. •WRED should not be configured for broadcast video traffic. 3.11.4 Configurations and RecommendationsFigure 3.14 illustrates a configuration for the Broadcast Video class. In this illustration, the traffic is assigned to a strict priority/LLQ, since the platform in this case supports dual-priority queues. Figure 3.14. Broadcast Video Traffic in LLQ Table 3.3 illustrates the recommended characteristics for broadcast video traffic. Table 3.3. Recommendations for Broadcast Video Traffic
In Figure 3.15, the traffic within the Broadcast Video class is assigned to a nonstrict-priority queue with adequate guarantees. Here we see that the queue has adequate bandwidth guarantees and does not have any WRED (early packet drop), which can impact IPTV and other types of broadcast video applications. Figure 3.15. Broadcast Video in Non-LLQ NOTE 3.4 Broadcast and Real-Time Interactive Video It is very common for SPs to combine both real-time interactive and broadcast video into a single VIDEO queue. In fact, this can be considered a recommended practice. Video on Demand, discussed in the following section, is also a potential candidate for this VIDEO queue, which helps in the consolidation of video applications with near to similar QoS requirements. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9780123744616000033 Overview of IP MulticastVinod Joseph, Srinivas Mulugu, in Deploying Next Generation Multicast-enabled Applications, 2011 1.1.5 Multicast Admission Control Mechanisms1.1.5.1 IGMP LimitA Service Provider can enforce a maximum broadcast bandwidth limit by limiting the number of IGMP joins on the ranges of multicast addresses associated with broadcast video to a configured maximum on the aggregation links that the router controls. Once again, we look at a Cisco IOS configuration for illustrative purposes. The ip igmp limit command can be used to configure a limit on the number of IGMP states resulting from IGMP membership reports on a per-system or per-interface basis. It controls the maximum number of IGMP states allowed on a router or interface. Membership reports sent after the configured limits have been exceeded are not entered in the IGMP cache, and traffic for the excess membership reports is not forwarded. Per-interface and per-system limits operate independently of each other and can enforce different configured limits. A membership state will be ignored if it exceeds either the per-interface limit or global limit. If you do not configure the except access-list keyword and argument, all IGMP states resulting from IGMP are counted toward the configured cache limit on an interface. The except access-list keyword and argument exclude particular groups or channels from counting toward the IGMP cache limit. An IGMP membership report is counted against the per-interface limit if it is permitted by the extended access list specified by the except access-list keyword and argument. ! ip igmp limit <number> [except access-list] (Enables per-system IGMP limit) ! interface GigE x/y (Enables per-interface IGMP limit. DSLAM-facing intf) ip igmp limit <number> [except access-list] ! 1.1.5.2 IP Mroute LimitThe per interface mroute state limit feature provides the ability to limit the number of mroute states on an interface for different ACL-classified sets of multicast traffic. This feature can be used to prevent DoS attacks, or to provide a multicast CAC mechanism when all of the multicast flows roughly utilize the same amount of bandwidth. The per interface mroute state limit feature essentially is a complete superset of the IGMP State Limit feature (except that it does not support a global limit). Moreover, it is more flexible and powerful (albeit more complex) than the IGMP State Limit feature, but it is not intended to be a replacement for it because there are applications that suit both features. The per interface mroute state limit feature can be used in conjunction with the IGMP State Limit feature. If both the per interface mroute state limit feature and IGMP State Limit feature are configured on an interface, routers generally enforce both limits. The main differences between the per interface mroute state limit feature and the IGMP Limit feature are •The per interface mroute state limit feature allows multiple limits to be configured on an interface, whereas the IGMP state limit feature allows only one limit to be configured on an interface. The per interface mroute state limit feature, thus, is more flexible than the IGMP State Limit feature because it allows multiple limits to be configured for different sets of multicast traffic on an interface. •The per interface mroute state limit feature can be used to limit both IGMP and PIM joins, whereas the IGMP State Limit feature can only be used to limit IGMP joins. The IGMP State Limit feature, thus, is more limited in application because it is best suited to be configured on an edge router to limit the number of groups that receivers can join on an outgoing interface. The per interface mroute state limit feature has a wider application because it can be configured to limit IGMP joins on an outgoing interface, to limit PIM joins (for ASM groups or SSM channels) on an outgoing interface connected to other routers, to limit sources behind an incoming interface from sending multicast traffic, or to limit sources directly connected to an incoming interface from sending multicast traffic. Although the PIM Interface Mroute State Limit feature allows you to limit both IGMP and PIM joins, it does not provide the ability to limit PIM or IGMP joins separately because it does not take into account whether a state is created as a result of an IGMP or PIM join. As such, the IGMP State Limit feature is more specific in application because it specifically limits IGMP joins. The per interface mroute state limit feature allows you to specify limits according to the direction of traffic; that is, it allows you to specify limits for outgoing interfaces, incoming interfaces, and for incoming interfaces having directly connected multicast sources. The IGMP State Limit feature, however, can only be used to limit outgoing interfaces. The Per Interface State Mroute State Limit feature, thus, is wider in scope because it can be used to limit mroute states for both incoming and outgoing interfaces from both sources and receivers. The IGMP State Limit feature is narrower in scope because it can only be used to limit mroute states for receivers on a LAN by limiting the number of IGMP joins on an outgoing interface. Both the IGMP State Limit and the per interface mroute state limit features provide a rudimentary multicast CAC mechanism that can be used to provision bandwidth utilization on an interface when all multicast flows roughly utilize the same amount of bandwidth. The Bandwidth-based CAC for IP Multicast feature, however, offers a more flexible and powerful alternative for providing multicast CAC in network environments where IP Multicast flows utilize different amounts of bandwidth. 1.1.5.3 Bandwidth-Based Multicast CACThe Bandwidth-based CAC for IP Multicast features enhances the per interface mroute state limit feature by implementing a way to count per interface mroute state limiters using cost multipliers. This feature can be used to provide Bandwidth-based multicast CAC on a per interface basis in network environments where the multicast flows utilize different amounts of bandwidth. Once again referring to a Cisco IOS-based implementation/configuration: Bandwidth-based CAC policies are configured using the ip multicast limit cost command in global configuration mode. The syntax of the ip multicast limit cost command is as follows: ! ip multicast limit cost access-list cost-multiplier ! ACLs are used with this command to define the IP Multicast traffic for which to apply a cost. Standard ACLs can be used to define the (*, G) state. Extended ACLs can be used to define the (S, G) state. Extended ACLs also can be used to define the (*, G) state by specifying 0.0.0.0 for the source address and source wildcard—referred to as (0, G)—in the permit or deny statements that compose the extended access list. 1.1.5.3.1 Mechanics of the Bandwidth-Based CAC for IP Multicast FeatureThe mechanics of the Bandwidth-based CAC for IP Multicast feature are as follows: •Once an mroute matches an ACL configured for an mroute state limiter, a router performs a top-down search from the global list of configured Bandwidth-based CAC policies to determine if a cost should be applied to the mroute. •A cost is applied to the first Bandwidth-based CAC policy that matches the mroute. A match is found when the ACL applied to the Bandwidth-based CAC policy permits the mroute state. •The counter for the mroute state limiter either adds or subtracts the cost configured for the cost-multiplier argument. If no costs are configured or if the mroute does not match any of the configured Bandwidth-based CAC polices, the default cost of 1 is used. 1.1.5.3.2 Case Study 1The following example shows how to configure mroute state limiters on interfaces to provide multicast CAC in a network environment where all the multicast flows roughly utilize the same amount of bandwidth. The case study uses a Cisco IOS configuration shown in Figure 1.21. In this example, a service provider is offering 300 Standard Definition (SD) TV channels. The SD channels are offered to customers in three service bundles (Basic, Premium, and Gold), which are available to customers on a subscription basis. Each bundle offers 100 channels to subscribers, and each channel utilizes approximately 4 Mbps of bandwidth. The service provider must provision the Gigabit Ethernet interfaces on the provider edge (PE) router connected to Digital Subscriber Line Access Multiplexers (DSLAMs) as follows: 50% of the link’s bandwidth (500 Mbps) must be available to subscribers of their Internet, voice, and video on demand (VoD) service offerings while the remaining 50% (500 Mbps) of the link’s bandwidth must be available to subscribers of their SD channel bundle service offerings. For the 500 Mbps of the link’s bandwidth that must always be available to (but must never be exceeded by) the subscribers of the SD channel bundles, the interface must be further provisioned as follows: Figure 1.21. •60% of the bandwidth must be available to subscribers of the basic service (300 Mbps). •20% of the bandwidth must be available to subscribers of the premium service (100 Mbps). •20% of the bandwidth must be available to subscribers of the gold service (100 Mbps). Because each SD channel utilizes the same amount of bandwidth (4 Mbps), the per interface mroute state limit feature can be used to provide the necessary CAC to provision the services offered by the service provider. To determine the required CAC needed per interface, the number of channels for each bundle is divided by 4 (because each channel utilizes 4 Mbps of bandwidth). The required CAC needed per interface, therefore, is as follows: •Basic Services: 300/4=75 •Premium Services: 100/4=25 •Gold Services: 100/4=25 Three ACLs are created for each of the mroute state limiters in the following way and applied to the interface (GigE in this case): •An mroute state limit of 75 for the SD channels that match acl-basic. •An mroute state limit of 25 for the SD channels that match acl-premium. •An mroute state limit of 25 for the SD channels that match acl-gold. ! interface GigabitEthernet X/y description — Interface towards the DSLAM— . . ip multicast limit out 75 acl-basic ip multicast limit out 25 acl-premium ip multicast limit out 25 acl-gold ! ! 1.1.5.3.3 Case Study 2The following example shows how to configure per interface mroute state limiters with Bandwidth-based CAC policies to provide multicast CAC in a network environment where the multicast flows utilize the different amounts of bandwidth. The case study uses a Cisco IOS configuration for illustrative purposes (see Figure 1.22). In this example, three content providers are providing TV services across a service provider core. The content providers are broadcasting TV channels that utilize different amounts of bandwidth: Figure 1.22. •MPEG-2 SDTV channels—4 Mbps per channel •MPEG-2 HDTV channels—18 Mbps per channel •MPEG-4 SDTV channels—1.6 Mbps per channel •MPEG-4 HDTV channels—6 Mbps per channel The Service Provider needs to provision the fair sharing of bandwidth between these three content providers to its subscribers across Gigabit Ethernet interfaces. The Service Provider, thus, determines that it needs to provision each Gigabit Ethernet interface on the PE router connected to the DSLAMs as follows: •250 Mbps per content provider •250 Mbps for Internet, voice, and VoD services The Service Provider then configures three ACLs: •acl-CP1-channels: Defines the channels being offered by the content provider CP1 •acl-CP2-channels: Defines the channels being offered by the content provider CP2 •acl-CP3-channels: Defines the channels being offered by the content provider CP3 Because the Content Providers are broadcasting TV channels that utilize different amounts of bandwidth, the Service Provider needs to determine the values that need to be configured for the mroute state limiters and Bandwidth-based CAC policies to provide the fair sharing of bandwidth required between the Content Providers. Prior to the introduction of the Bandwidth-Based CAC for IP Multicast feature, the mroute state limiters were based strictly on the number of flows. The introduction of cost multipliers by the Bandwidth-Based CAC for IP Multicast feature expands how mroute state limiters can be defined. Instead of defining the mroute state limiters based on the number of multicast flows, the service provider looks for a common unit of measure and decides to represent the mroute state limiters in Kbps. The service provider then configures three mroute states, one mroute state limiter per Content Provider. Because the link is a Gigabit, the service provider sets each limit to 250,000 (because 250,000 Kbps equals 250 Mbps, the number of bits that the service provider needs to provision per content provider). The service provider needs to further provision the fair sharing of bandwidth between the content providers, which can be achieved by configuring Bandwidth-based CAC policies. The Service Provider decides to create four Bandwidth-based CAC policies, one policy per channel based on bandwidth. For these policies, the Service Provider configures the following ACLs: •acl-MP2SD-channels: Defines all the MPEG-2 SD channels offered by the three Content Providers. •acl-MP2HD-channels: Defines all the MPEG-2 HD channels offered by the three Content Providers. •acl-MP4SD-channels: Defines all the MPEG-4 SD channels offered by the three Content Providers. •acl-MP4HD-channels: Defines all the MPEG-4 HD channels offered by the three Content Providers. For each policy, a cost multiplier (represented in Kbps) is defined for each ACL based on the bandwidth of the channels defined in the ACL: •4000—represents the 4 Mbps MPEG-2 SD channels •18000—represents the 18 Mbps MPEG-2 HD channels •1600—represents the 1.6 Mbps MPEG-4 SD channels •6000—Represents the 6 Mbps MPEG-4 HD channels The following configuration example shows how the Service Provider used mroute state limiters with Bandwidth-based CAC policies to provision Gigabit Ethernet interface for the fair sharing of bandwidth required between the three content providers: ! ip multicast limit cost acl-MP2SD-channels 4000 ip multicast limit cost acl-MP2HD-channels 18000 ip multicast limit cost acl-MP4SD-channels 1600 ip multicast limit cost acl-MP4HD-channels 6000 ! . ! interface GigabitEthernet X/y ip multicast limit out acl-CP1-channels 250000 ip multicast limit out acl-CP2-channels 250000 ip multicast limit out acl-CP3-channels 250000 ! Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9780123849236000016 Cisco IOS Router BasicsDale Liu, in Cisco Router and Switch Forensics, 2009 TelnetTelnet is a remote login tool that also has its uses on Cisco routers. I am a big fan of using command-line entry to check status and make configuration changes, because you never face “supported hardware issues” when it comes to making changes this way, and making changes using the CLI is fast and efficient. So, your passport to this approach is to use a Telnet-compatible session. This brings me to a point where I can tell you about getting around obstacles when it comes to configuring routers and switches. The other day I set out to configure two 2500 series routers that I had in my network devices collection. I pulled down an installer for Cisco Network Assistant (CNA), and connected the two routers to a lab subnet. However, after I directed the wizard to the routers’ Internet Protocol (IP) addresses, it told me these devices were unsupported! That makes sense, as up to that point I had used CNA only on newer Cisco devices, and this high-speed application didn't support this equipment. Fortunately, I was able to quickly rectify the problem by opening a Telnet session and making the changes I needed. I mention this so that you understand that as long as you can use the CLI, you will always have a way to access, view, and configure Cisco equipment. It is also important to remember that routers have five virtual terminals. This means you must set a login for each virtual terminal and set an enable password; otherwise, you might be disappointed. It also means you can connect to the same router in five different terminal sessions. You and four of your coworkers can all be connecting to the router under Telnet at the same time. But note that if you make a configuration change to the VTYs, you must ensure that all the VTYs are included. There is a good chance that if you apply only a login local setting to VTY 0, VTYs 1, 2, 3, and 4 will not stop and offer a login challenge! However, this is easy to spot when you look at the output of either show running-config or show startup-config, because you will see distinct blocks of settings for one group of VTYs and another set of configurations for the VTYs without the login local setting, which opens the device to easy exploitation. So, do it right and make the configuration under line VTY 0 4, and you can configure all five at the same time. Here is how you get started with using Telnet to configure your routers. You must have already set an IP address to the router, enabled an Ethernet interface by issuing a no shutdown command on the appropriate Ethernet subinterface, and allowed for login in the VTY. (If you have not done this so far, refer back to the part of this chapter that discusses HyperTerminal and the console port, and make the appropriate changes.) Router#configure terminal Router(config)#interface FastEthernet 0 Router(config-if)#ip address 192.168.1.46 255.255.255.0 Router(config-if)#no shutdown Router(config-line)#CTRL-Z Router# copy running-config startup-config If you choose to limit access to a small list of trusted IP addresses, you can set up an ACL on the terminal that will restrict anyone who does not possess the proper IP address from making a connection. We are applying an extended ACL here so that you see what one looks like. Later, I will show you some basics about ACLs, including both standard and extended ACLs. To ensure sanity in detailed analysis scenarios, try to use a consistent system when numbering your ACLs. For instance, try to use 23 (standard ACL) or 123 (extended ACL) for Telnet, and 80 (standard ACL) or 180 (extended ACL) for Web access. Have a system and try to stick with it. Here is an example: Router#configure terminal Router(config)#access-list 123 permit tcp host 192.168.1.45 host 0.0.0.0 eq telnet log-input Router(config)#access-list 123 deny ip any any log-input Router(config)#login on-failure log every 3 Router(config)#login on-success log every 1 Router(config)#login block-for 300 attempts within 60 Router(config)#line vty 0 4 Router(config-line)#access-class 123 in Router(config-line)#CTRL-Z Router#copy running-config startup-config Be very careful with your logging, as one misplaced log or log-input command will log every packet into or out of an interface, and that may not work well. Here we just want to see when the ACL fires as a result of an attempt to Telnet from any host other than 192.168.1.45. To recap, we entered configuration mode through the terminal; for security purposes, we set up logging to occur every third time a login failure occurs and logging turned on for successful logins. Logging successful VTY challenges is essential to having accurate accounting of access to your router. Then we set up a lockdown on the router to prevent someone from logging in after three failed attempts in a space of 60 seconds. This lockdown goes on for five minutes. Next, we dropped into VTY subconfiguration mode so that we could institute login access to the router, and set the access class to the VTY. We then saved it and copied it to the startup configuration on the router's flash memory. But we are not finished yet. We still have to discuss a couple of special points concerning security. If you have been paying attention, I showed you an example of an extended access list which is very specific. While I was writing this chapter, the lead author and I had many discussions on these points and we agreed to show an example of a standard and an extended list so that you can become proficient in recognizing the differences between them. The following code snippet displays a standard access list which inspects only the IP address of the packet to determine whether it matches the rule: Router#configure terminal Router(config)#access-list 23 permit 172.16.1.1 log Router(config)#access-list 23 deny any log Router(config)#line vty 0 4 Router(config-line)#access-class 23 in Router(config)#CTRL-Z This example sets an ACL that looks only at the IP address. If it matches 172.16.1.1, the ACL lets it through, while logging it. If it fails to match, it drops the packet and logs it. This is applied to the Telnet VTYs in an inward direction with the access-class directive, matching the ACL rule number we set (in this case, 23). (Keep in mind that access-class and access-group are two different commands, so use them appropriately.) In the next example, you see an extended ACL that does a far more precise job of packet inspection, as it delves deeper into the packet to determine whether a rule will match: Router(config)#access-list 123 permit tcp host 172.16.1.1 any eq 23 log-input Router(config)#access-list 123 deny ip any any log-input Router(config)#line vty 0 4 Router(config-line)#access-class 123 in Router(config-line)#CTRL-Z This extended ACL is constructed to inspect packets from an IP address, as well as to specify what type of packet is inspected for matching. In this example, we've selected to look at TCP packets that have a destination port of 23, the one used for Telnet. We've still opted for logging, but the option is slightly different. At this point, you should understand the key differences between standard and extended ACLs. If you still have questions and want to learn more, visit http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml for more information. If you want to prevent all Telnet connections to the router, you can disable the router altogether. At that point, you will be stuck with dialing in to the modem on the secured AUX port you set up earlier in the chapter as an out-of-band administration solution. Consider the following code, as it should look familiar but has specific elements that are germane to the VTYs we talked about: Router#configure terminal Router(config)#line vty 0 4 Router(config-line)#login local Router(config-line)#no exec Router(config-line)#exec-timeout 0 1 Router(config-line)#tranport input none Router(config-line)#CTRL-Z Router# copy running-config startup-config Tools & Traps… SSH on Cisco Network DevicesMany of the clients for whom I have conducted computer network assessments have given me reasons for not using SSH to remotely log in to their routers and switches. I can understand not using SSH when the client plans to upgrade their equipment to support the IOS feature set. Along those lines, many times I have indicated to folks that they will reap the benefits of network defense by purchasing and adding an IOS feature set to their arsenal of equipment. And I have never been able to understand it when these users still do not make an attempt to use SSH to configure their routers or switches. If you're one of these people, I will now demonstrate how easy SSH is to set up. The first step involves making sure your router platform supports SSH for logins. (Not all of them do. The 2524 router depicted in this chapter cannot use SSH or other secure management systems.) To set a router to do exclusive SSH without any Telnet access and to set a two-minute timeout, use the following code: Router#configure terminal Router(config)#hostname ACMERTR ACMERTR(config)#ip domin-name mycorp.com ACMERTR(config)#crypto key generate rsa The name for the keys will be: ACMERTR Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes How many bits in the modulus [512] 2048 Generating RSA keys … [OK] ACMERTR(config)#ip ssh time-out 120 ACMERTR(config)#ip ssh authentication-retires 2 ACMERTR(config)#service tcp-keepalives-in ACMERTR(config)#line vty 0 4 ACMERTR(config-line)#transport input ssh ACMERTR(config-line)#CTRL-Z ACMERTR# copy running-config startup-config To configure the router to handle both SSH and Telnet through the virtual terminal lines, use the following command: ACMERTR(config-line)# transport input ssh telnet What's behind the transport command tells IOS where to expect interactive command data and in what form or protocol. A number of protocols can be used, such as rlogin or PAD, but the most common ones you can expect to see are the SSH (port 22) and Telnet protocols (using port 23). When you specify a transport input statement in the config-line subcommand, you are telling the router how to handle the input and what port should be used to communicate. In this day and age, legacy routers that don't support SSH should be replaced, but in a pinch where replacement is impractical, you can use ACLs to help secure Telnet access, especially if you log both successful and unsuccessful login attempts. Before we move on to the next section of the chapter, we need to discuss how to set banners on Cisco devices. You can use banners to warn people what their login means, along with any privacy limitations that result. The banners should be explicit in their intent, but also enforceable. There are some pitfalls in writing a banner message that you should be aware of. Banners used to be referred to as “welcome” messages for anyone who logged in. This is no longer the case, because far too many network attackers have prepared their legal defense on the grounds that they were “… invited in by the ‘welcome’ message on the login page.…” Please, please, please consult the legal resources available to the client organization or to your company as you develop your warning messages to make sure they contain the appropriate language and do not inadvertently give an “out” to criminals and their slick legal defense teams. Here is how you can add a login banner message to your Cisco router. Try not to include identifying features or locations, as that may give someone with mischief on his mind a few extra clues regarding the makeup and defenses of your network device. The banner should be simple and quick to read, as it will appear each time a user attempts to log in to the router. ACMERTR#configure terminal ACMERTR(config)#banner login $ Enter TEXT message. End with the character ‘$’. **************************************************************************** Warning - this device is private property. Unauthorized use prohibited under state and federal law. All access to this device is subject to monitoring, logging, tracking and investigation. Inappropriate use may be punished to the fullest extent allowed under the law. ******************************************************************************** . $ ACMERTR(config)#CTRL-Z Router#copy running-config startup-config You should also be able to track when people log in to your router or fail to log in, and have those events reported to a syslog server. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9781597494182000065 Which command will show only the ip access lists on a router?Access List Commands. Which command is used to display the access lists?To display the contents of current access lists, use the show access-lists privileged EXEC command. To display the contents of all current IP access lists, use the show ip access-list EXEC command.
What is the types of access list that can be configured on a Cisco router?Cisco IoT offers. Indoor access points.. Outdoor and industrial access points.. Wireless LAN controllers.. Services for mobility and wireless.. 5G/Mobility for service providers.. Wi-Fi 6/6E solutions.. Cisco DNA Spaces.. Which command would you use to apply an access list to a router interface?Explanation: To apply an access list, the proper command is ip access-group 101 in.
|
Which of the following commands will show only the ip access lists configured on the router?
zusammenhängende Posts
Urheberrechte © © 2024 WIKIFI Inc.
