RIPv2

1. RIP v1 &2 has a maximum datagram size (with an eight-byte UDP header) of 512 octets. So it is up to 25 route entries (each is 20 bytes).

2. RIP v2 support authentication.

Simple password authentication: it will use the first route entry. So it leaves only 24.

MD5 authentication: it will use the first and last one. So it leaves only 23.

You need to configure the authentication under interface.

3. Unicast update.

By default RIP uses broadcast(v1) or multicast(v2) to send updates. To use unicast update, you need to enable the interface to be part of the network, then mark it as passive interface and finally configure neighbor.

Passive interface just makes the interface no sending out broadcast or multicast updates. But it will still listen to the updates.

AD and EIGRP

1. When receiving a new EIGRP update, Will it compare inside the EIGRP topology firstly and then AD?

Let's look at the sample.

10.1.0.0 learn from BGP and then redistributed into EIGRP on R1.

default-metric 10000 10 1 255 1500
distance 200 0.0.0.0 255.255.255.255 10
access-list 10 permit 10.1.0.0

Then R1 receives an new update from its neighbor R2 with 10000 1200 1 255 1500.

So from the eigrp topology perspective, the one redistributed from BGP has better metrci than the one from R2. But the AD for R2 is 170, and 200 for BGP. Which one is prefer????

Answer, it prefers the AD first. So in R1's routing table, 10.1.0.0 is from EIGRP instead of R2.

ip alias

1. show ip alias

It will should all the IP address, it is better than using show ip int bri.

2. ip alias can be use for un-exist host.
Sample configuration:
R1#(config)int fa 1/0
R1#(config-inf) ip add 192.168.1.2 255.255.255.0
R1#(config)ip alias 192.168.1.10 23

when you ping 192.168.1.10, the arp will resolve from 192.168.1.2. When you telnet 192.168.1.10, it will actually telnet to 192.168.1.2.

Usually, it will be used in reverse telnet.
ip alias 172.16.1.10 2001
ip alias 172.16.1.11 2002

So you can just "telnet 172.16.1.10" than it will reverse telnet to one of the serial ports.

PVST+

Cisco switches run different types of STP protocol, depending on whether the connected port is access, ISL trunk or 802.1q trunk. Natively, a Cisco switch runs a separate STP instance for each configured and active VLAN (this is called Per-VLAN Spanning Tree or PVST) and standard IEEE compliant switches run just one instance of STP protocol shared by all VLANs. Due to that, a group of switches running IEEE compatible STP protocol is called MST (Mono Spanning Tree) region.

Access Ports. Cisco switches run classic version of IEEE STP protocol on the access ports. The IEEE STP BPDUs are sent to IEEE reserved multicast MAC address “0180.C200.0000” using IEEE 802.2 LLC SAP encapsulation with both SSAP and DSAP fields equal to “0×42”. (By the way, for the purpose of Layer2 filtering, IEEE BPDUs could be matched using a MAC ACL with LSAP value of ”0×4242”). Note that you can plug any standard IEEE compliant switch into a Cisco switch access port and they will interoperate perfectly, joining the respective access VLAN STP instance with the IEEE STP instance (MST).

ISL Trunks. Across ISL trunks, Cisco switches run PVST (Per-VLAN Spanning Tree). (Note that PVST feature is limited to ISL trunks only). The same IEEE STP BPDUs are sent for each VLAN, encapsulated in additional ISL header (which also carries the VLAN number). The magic part is that ISL header has special flag to distinguish frames carrying STP BPDUs and this is how PVST can re-use the regular IEEE BPDUs to simulate multiple spanning trees. Since PVST BPDUs have the same format as IEEE BPDUs (that is IEEE 802.2 LLC SAP) they can be matched using the same SSAP/DSAP values of “0×42” for the purpose of Layer 2 filtering.The group of Cisco switches connected using ISL trunks only is called PVST region.

802.1q Trunks. Across 802.1q trunks, Cisco switches run PVST+ (Per VLAN Spanning Tree Plus). Now this is where things are getting complicated. The goal of PVST+ is to interoperate with standard IEEE STP (MST) and allow transparent tunneling of PVST instance BPDUs across MST region (to potentially connect to other Cisco switches across the MST region). For further consideration, we call a group of Cisco switches connected using 802.1q trunks as PVST+ region. Note that PVST+ region may connect to a PVST region using an ISL trunk and connect to MST region using a 802.1q trunk. The STP instances in PVST and PVST+ regions maps directly to each other, so no special interoperability solution is required. However, on MST side only one STP instance exists, contrary to many STP instances of PVST+ region. The first question is: if we want to interoperate with MST, which PVST VLAN’s STP instance should be joined with MST? Cisco chooses VLAN 1 for this purpose. The joined together instances of Cisco VLAN 1 STP and MST are called “Common Spanning Tree” or CST (naturally, CST spans PVST, PVST+ and MST regions). As for the detailed PVST+ operations on 802.1q port, consider two following cases.

Lastly, for the purpose of layer 2 filtering, remember that you can match SSTP BPDUs using an ethertype value “0×010B”.This works with multilayer switches even though SSTP BPDUs are SNAP encapsulated, and the actual field is not “ethertype” but rather a SNAP Protocol ID.

mac access-list extended IEEE_STP&PVST&MIST
permit any any lsap 0x4242 0x0
mac access-list extended PVST+
permit any any 0x10B 0x0

VLAN ACL

1. Tips
ARP are not IP packet, so you must be enabled it using mac ACL.
STP/PVST, PVST+ are something need to be enable too.


2. IP ACL
The CAT 3550 and 3560 switches process IP Packets in a different way than the non-IP Packets. So it is Mandatory to use IP access-list.

We cannot use a MAC access-list to allow IP Packets.

3. Sample
So, we have two different requirements there...
Forward all "non-IP" frames sourced from those two specific MAC Addresses; That requires a MAC Access-List.
Permit only ICMP, denying everyting else. That requires an IP Access-List (the one we´re all used to).

Ok, so let´s create our MAC Access-List:

mac access-list extended Allow Those
permit 000b.dc24.ca47 any
permit 000b.dc25.cb51 any

That will handle the first requirement.
Now the second one IP Access-List allowing ICMP and denying everything else:
access-list 101 permit icmp any any

Ok! Now, we need to create the VACL (or VLAN Maps, which one you prefer to call it) applying those rules:
vlan access-map Filter-VL7 10
action forward
match mac address AllowThose
!
vlan access-map Filter-VL7 20
action forward
match ip address 101
!
vlan access-map Filter-VL7 30
action drop

Now it looks ok, right?! Time to apply it to VLAN7 ?! What do you think about?! Let´s try?!

vlan filter Filter-VL7 vlan-list 7

Now testing! See if you can ping! Not working?! Hmmm... interesting... but why?! Well... I told... The MAC Access-List would bring all the interesting issues to the table! And, in fact, it did! It´s allowing only those two MAC Address and nothing else! How about ARP?! Do we need it to make things work?! Of course we do! And that´s where we have most confusion! Just keep in mind, the end of an Access-List is always deny any any! So if there are no matching instances for ARP in the MAC Access-List, it´ll be dropped!
How to fix it?! Simple, allow it in the MAC Access-List:
permit any any 0x0806 0x0000 permit any any lsap 0xAAAA 0x0000
But wait a minute! What´s that 0x0806 and lsap 0xAAAA ?! That´s the Ethertypes we´re allowing in our MAC Access-List, first one (0x806) is ARP, and the second one (lsap 0xAAAA) is PVST+. You do not want your switch running unprotected from loops right?! So it´s better to allow it!
For the sake of simplicity, the full configuration would be this one:
mac access-list extended AllowThose
permit 000b.dc24.ca47 any
permit 000b.dc25.cb51 any
permit any any 0x0806 0x0000
permit any any lsap 0xAAAA 0x0000 (This is copy from Link. This matches all the snap packet. To be more specifical, use permit any any 0x010b 0x0000).
!
access-list 101 permit icmp any any
!
vlan access-map Filter-VL7 10
action forward
match mac address AllowThose
!
vlan access-map Filter-VL7 20
action forward
match ip address 101
!
vlan access-map Filter-VL7 30
action drop
!
vlan filter Filter-VL7 vlan-list 7



The most common Ethertypes are: (and probably the ones asked in the LAB)
0x0806 = ARP
0x0800 = IP
0x010b = PVST+ (actually is inside the snap packet, lsap 0xAAAA)
0x4242 = STP and PVST
0x86DD = IPv6

Again... we need to understand all the little pieces involved in a particular task, and remember about the basics, OSI Model, ARP, and so on! It´s not difficult, but it´s a little confusing at the first time! Just go ahead, drink some watter (I did it several times) come back again, read over, and try some scenarios yourself, don´t have equipment?! Try it on Notepad, just try some, compare with the example, and you´ll see how easy it can be! The best way to learn is trying it yourself! ;)
You can also find a nice explanation about that in the wonderful Arden Packeer´s Blog, just click here and it´ll direct you to the post.

RSVP

RSVP is one way. Typically RSVP is initialize by sender.

Typically, an RSVP-capable application running on an end system host on one side of a router network sends either unicast or multicast RSVP PATH (Set Up) messages to the destination end system or host on the other side of the router network with which it wishes to communicate. The initiating application is referred to as the sender; the target or destination application is called the receiver. In this example, the sender runs on the host upstream from Router A and the receiver runs on the host downstream from Router C. The router network delivers the RSVP PATH messages from the sender to the receiver. The receiver replies with RSVP RESV messages in an attempt to reserve across the network the requested resources that are required between itself and the sender. The RSVP RESV messages specify the parameters for the requisite QoS that the router network connecting the systems should attempt to offer.


In the example, the RSVP PATH messages flow in one direction: downstream from the sender, which in this example is Router A. (If the host were to initiate the RSVP PATH message, the message would flow from the host to Router A.) Router A sends the message downstream to Router B, and Router B sends it downstream to Router C. (If the downstream host were the actual receiver, Router C would send the RSVP PATH message downstream to the receiver host.) Each router in the router network must process the RSVP PATH message and route it to the next downstream hop.

The RSVP RESV messages flow in one direction: upstream from the receiver (in this example, Router C), upstream from Router C to Router B, and upstream from Router B to Router A. If the downstream host were the receiver, the message would originate with the host, which would send it to Router C. If the upstream host were the sender, the final destination of the RSVP RESV message would be the upstream host. At each hop, the router receiving the RSVP RESV message must determine whether it can honor the reservation request.

The ip rsvp bandwidth command both enables RSVP on an interface and specifies the amount of bandwidth on the interface that can be reserved (and the amount of bandwidth that can be allocated to a single flow). To ensure QoS for the RSVP reservation, WFQ is configured on the interfaces enabled for the reservation.

If the router network is capable of offering the specified (QoS) level of service, then an end-to-end reserved path is established. If not, the reservation attempt is rejected and a RESV ERROR message is sent to the receiver. The ability of each router in the network to honor the requested level of service is verified, link by link, as the RSVP RESV messages are sent across the router network to the sender. However, the data itself for which the bandwidth is reserved travels one way only: from the sender to receiver across an established PATH. Therefore, the QoS is effective in only one direction. This is the common case for one-to-many multicast data flows.


Weighted Fair Queuing (WFQ) needs to be enabled for RSVP. Although
WFQ is normally enabled by default on the Serial interfaces (2.048 Mbps and
below), once Frame Relay Traffic Shaping is enabled, WFQ is disabled.

1. Frame Relay

You need to enable the following step

1.1 Enable WFQ

If you do not use frame-relay traffic-shaping, make sure the interface is enabld for WFQ(Default). If you do use traffic-shaping, you need to enable WFQ in the map-class.

It is better to enable traffic shaping because that will be enfore queueing on the Per-VC.

1.2 Configure bandwidth under the both interface and sub-interface.
ip rsvp bandwidth 128(interface-max) 64 (per flow max)


it is important to note that when using subinterfaces that the ip rsvp bandwidth command will need to be applied to the physical along with the subinterface. If more than one subinterface is using RSVP, the physical interface’s ip rsvp bandwidth command will be the sum of all the subinterface’s ip rsvp bandwidth commands.

Example:

interface Serial3/0
no ip address
encapsulation frame-relay
no fair-queue
frame-relay traffic-shaping
ip rsvp bandwidth 500 64 //Interface-max 500=350+150, single flow max = max {subinterfaces}
!
interface Serial3/0.1 point-to-point
ip address 10.1.1.1 255.255.0.0
frame-relay interface-dlci 101
class fr-voip
ip rsvp bandwidth 350 64
!
interface Serial3/0.2 point-to-point
ip address 10.3.1.1 255.255.0.0
frame-relay interface-dlci 201
class fast-vcs
ip rsvp bandwidth 150 32
!
map-class frame-relay fr-voip
frame-relay cir 800000
frame-relay bc 8000
frame-relay mincir 128000
frame-relay fragment 280 //option
no frame-relay adaptive-shaping
frame-relay fair-queue //Enable WFQ
!
map-class frame-relay fast-vcs
frame-relay cir 200000
frame-relay bc 2000
frame-relay mincir 60000
frame-relay fragment 280
no frame-relay adaptive-shaping
frame-relay fair-queue //Enable WFQ


Rack1R5#show frame-relay pvc 101
PVC Statistics for interface Serial1/0 (Frame Relay DTE)
DLCI = 504, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial3/0.1

Queueing strategy: weighted fair
Current fair queue configuration:
Discard Dynamic Reserved
threshold queue count queue count
64 16 4
Output queue size 0/max total 600/drops 0


2. How about we disable WFQ

The reservation still will be successful. But the interface won't actually provide any queue.

Do a 'show ip rsvp install detail'

Rack1R1#show ip rsvp installed detail
RSVP: Serial1/0 has the following installed reservations
RSVP Reservation. Destination is 150.1.5.5. Source is 150.1.1.1,
Protocol is UDP, Destination port is 5000, Source port is 1000
Traffic Control ID handle: 81000404
Created: 23:02:48 UTC Sun Mar 3 2002
Admitted flowspec:
Reserved bandwidth: 32K bits/sec, Maximum burst: 4K bytes, Peak rate: 32K bits/sec
Min Policed Unit: 0 bytes, Max Pkt Size: 0 bytes
Resource provider for this flow: None
Conversation supports 1 reservations [0x1B000402]
Data given reserved service: 0 packets (0 bytes)
Data given best-effort service: 0 packets (0 bytes)
Reserved traffic classified for 28 seconds
Long-term average bitrate (bits/sec): 0 reserved, 0 best-effort
Policy: INSTALL. Policy source(s): Default

Here is the good one.
Rack1R1#show ip rsvp installed detail
RSVP: Serial1/0 has the following installed reservations
RSVP Reservation. Destination is 150.1.5.5. Source is 150.1.1.1,
Protocol is UDP, Destination port is 5000, Source port is 1000
Traffic Control ID handle: 81000404
Created: 23:02:48 UTC Sun Mar 3 2002
Admitted flowspec:
Reserved bandwidth: 32K bits/sec, Maximum burst: 4K bytes, Peak rate: 32K bits/sec
Min Policed Unit: 0 bytes, Max Pkt Size: 0 bytes
Resource provider for this flow:
WFQ on hw idb Se1/0: RESERVED queue 265. Weight: 6, BW 32 kbps
Conversation supports 1 reservations [0x1B000402]
Data given reserved service: 0 packets (0 bytes)
Data given best-effort service: 0 packets (0 bytes)
Reserved traffic classified for 28 seconds
Long-term average bitrate (bits/sec): 0 reserved, 0 best-effort
Policy: INSTALL. Policy source(s): Default

Redistribution

1. EIGRP.
Distance command only works for internal routes, not external routes.
You can only change AD for all prefix at one.