This can also be done after you configure all of your VLANs. Now that we have our VRFs setup I like to go ahead and configure MP-BGP. As we begin importing an exporting routing to/from MP-BGP 6 it will definitely help you keep things straight! In this scenario we are using an private ASN since we are not performing any external peering. I like to match the RD 4 to the BGP ASN 5 and VLAN number whenever possible. The first thing we did was configure the VRFs individually: ip vrf WAN The router we are using in the lab is a Cisco 2821 running IOS 15.1.4M7 Advanced Enterprise Services. The router is where the real work takes place. Since the switches are strictly layer 2 they will not be concerned with any of the VRF specific information. The switches will be stacked and the VLANs will be configured for each tenant, voice, and management. We will begin with the switches since they are the most basic. Remember: VRFs are case sensitive! Switch Configuration Overview: # Here is how we broke down the VLANs/VRFs for the PoC 3 lab: VRF/VLAN Breakdown: # VRF Name Here is a small, basic, diagram of what we will be building: I will leave the management VLAN in the global routing table. Each VRF will reside in a VLAN that will be trounced to the stack of switches via a port-channel. This will allow for strict separation of tenants while still allowing the sharing of voice and Internet services. There will be a VRF for each tenant, a VRF for the voice service, a VRF for the WAN/Internet circuit. Since the switches are strictly layer two devices and there will be zero tenant-to-tenant communications at the LAN level I proposed a VRF 2 solution utilizing the ISR as a router-on-a-stick. There will be a reasonable amount of commercial grade Internet access and the tenants will be allowed to host some services locally (e-mail, collaboration software, etc.). There will be no LAN-to-LAN communications between the tenants. The client also has an existing Cisco Unified Communications System that they will be configuring to provide voice services to all of the tenants. During the initial meeting it came out that they already had equipment and would like to use this equipment without purchasing much more. If the IP datagram does not receive all of the fragments within the specified time, the timer will expire and the IP datagram (and all of its fragments) will be dropped.I was approached by a client who wanted me to build their multi tenant network for a small office building. In addition to configuring the maximum threshold values, each IP datagram is associated with a managed timer. When the maximum number of fragments per datagram is reached, subsequent fragments will be dropped, and an alert message such as the following is logged to the syslog server: "VFR-4_TOO_MANY_FRAGMENTS." When the maximum number of datagrams that can be reassembled at any given time is reached, all subsequent fragments are dropped, and an alert message such as the following is logged to the syslog server: "VFR-4_FRAG_TABLE_OVERFLOW." (Both of these parameters can be specified via the ip virtual-reassembly command.) To avoid buffer overflow and control memory usage, configure a maximum threshold for the number of IP datagrams that are being reassembled and the number of fragments per datagram. ≛uffer Overflow AttackIn this type of denial-of-service (DoS) attack, the attacker can continuously send a large number of incomplete IP fragments, causing the firewall to lose time and memory while trying to reassemble the fake packets. VFR drops all fragments within a fragment chain if an overlap fragment is detected, and an alert message such as follows is logged to the syslog server: "VFR-3-OVERLAP_FRAGMENT." When the firewall reassembles the IP fragments, it might create wrong IP packets, causing the memory to overflow or your system to crash. Overlapping Fragment AttackIn this type of attack, the attacker can overwrite the fragment offset in the noninitial IP fragment packets. VFR drops all tiny fragments, and an alert message such as follows is logged to the syslog server: "VFR-3-TINY_FRAGMENTS." Thus, the ACL rules that have been configured for those fields will not match. Tiny Fragment AttackIn this type of attack, the attacker makes the fragment size small enough to force Layer 4 (TCP and User Datagram Protocol (UDP)) header fields into the second fragment. VFR is responsible for detecting and preventing the following types of fragment attacks:
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |