Don´t believe "only" in the show run (in my case, in the show conf) September 23, 2008
Posted by cauew in Layer 2 Protocols, Miscellaneous, Switching.2 comments
Hmm… buddy! Let me tell you something… don´t believe only in the show run, always check every parameter involved using other show commands…
Why do I say that?! Last weekend, during a new WS-3750 installation for user access, I faced a little problem… Two core´s, and my new access switch, with links to both Core Switches. Trunk was limitted only to the management vlan to avoid any problems during the intervation.
In order to avoid any other problems, I´ve increased to Spanning-Tree cost to 25 in both uplinks (1Gbps) from the access switch to the cores.
So far so good! Installation done with the first core, ok, let´s connect the second! Hmmm… lost access, let me try again, ok, accessing normal, so what happened?! Root Port from Core 1 changed to the Access Switch?! Why?!
That´s when I´ve found that one of the Core Switches had spanning-tree costs of 3004, 3019… WTH! Quick show conf (yes, it is CatOS), the Core was configured with UpLinkFast…
No biggie, changed spanning-tree cost, path went back to normal, and everything else was good! Customer will check how and when to remove the UpLinkFast configuration.
If at any time, I´ve checked the spanning-tree with show commands (not the show conf), I would see that, but… living and learning, right?!
Now I do know why some guys don´t like to do a show run, they preffer to check with other commands, I think they´re right… 
Storm-Control everything you need to know September 19, 2008
Posted by cauew in Layer 2 Protocols, Security, Switching, Video On Demand.2 comments
Another part of the IPExpert Security Video-on-Demand, Storm-Control!
Storm-Control can be used to limit, or to set thresholds for different types of traffic (Broadcast, Multicast and Unicast) on a specific interface you choose (or that you´re asked for).
You can set your threshold to whatever the top level that you want, and the traffic will be limit to that. Also, on 3560 Switches you can set falling thresholds too! Basically it is telling the switch how much traffic do I want (or don´t I want) through that interface.
Now… to the tricky part… just suppose you want to limit the broadcast/multicast traffic in a specific interface… how would you set?! Would you allow more Broadcast traffic than Multicast?!
Hmm… good question, let´s step back for a while… What´s a Layer 3 Broadcast?!
A Layer 3 Broadcast can be the "All Hosts" which is the 255.255.255.255, or it can be a "Subnet Brodcast", for example 172.168.10.255 is the broadcast IP of the /24 subnet; just keep in mind that if the actual subnet mask change, the Broadcast IP will also change too!
Now… how about Layer 3 Multicasts?! What those guys are?
Layer 3 Multicasts, known as Class D also, begin with the binary value of 1110 in the first octet. It goes from 224.x.x.x to 239.x.x.x. Also, at Class D we don´t have concept of subnetting of or broadcast reachability! So Broadcasts and Multicasts at "Layer 3" have nothing to do with each other.
Ok! With all that in mind, can you make a decision on how to configure the Storm-Control in one of your switch ports to limit the Broadcast / Multicast traffic?! Not that fast right?! There´s another wonderful world outside "Layer 3" it´s called "Layer 2" ! 
At Layer 2, Broadcasts are know as "All F´s" FF-FF-FF-FF-FF-FF, this address represents all devices in a Layer 2 network, we all know that since the CCNA days, so, no big deal!
Now… The Layer 2 representation of IP Multicasts all begin with 01-00-5E. And there´s one specific bit in the MAC Address that defines whether or not it´s a Multicast, the I/G bit!
Take a look at the MAC Address format:
So, like our friend Scott Morris likes to say, the least significant bit of the most significant byte is the I/G bit! And looking at our Multicast Address 01-00-5E (in binary 0000 0001-0000 0000-0101 1110) we can see that this I/G bit is set to 1 in EVERY Multicast!
In that case, the I/G bit defines a Multicast when it´s set to 1, but, how about the Broadcasts?! All bits in a Layer 2 Broadcast are set to 1 (including the I/G bit), so, Layer 2 Broadcasts, in fact, ARE a subset of Layer 2 Multicasts.
All Layer 2 Broadcasts are Multicasts.
All Layer 2 Multicasts are not Broadcasts.
With that in mind, when configuring Storm-Control in a switch port, and, if you´re setting limits to both Multicast and Broadcast, you should set Multicast limit HIGHER than the Broadcast limit (at least set they equal, but never set the Multicast level to be less than the Broadcast level, otherwise, either Broadcasts and Multicasts will be limited by the Multicast level, making pointless the Storm-Control configuration for the Broadcast!).
It´s configured on a per-interface basis, here´s the command list:
| (config-if)#storm-control broadcast level (#)[.(#)] (config-if)#storm-control multicast level (#)[.(#)] (config-if)#storm-control unicast level (#)[.(#)] Level is % of line as maximum threshold |
The following example will enable Unicast Storm-Control on a switch port with an 89% rising suppression level and a 67% falling suppression (remember, falling suppression can only be configured in 3560). It´ll also enable Broadcast Storm-Control on a port to a level of 20%. When the Broadcast exceeds the configured level of 20% of the total available bandwidth of the port within the traffic-storm-control interval, the switch drops all broadcast traffic until the end of the traffic-storm-control interval:
|
interface gigabitethernet0/1 |
Just remember, Multicast levels (which includes more things) must be higher, or at least equal, to the Broadcast levels when configuring Storm-Control!
You can use the show storm-control command to verify the operation!
Nice!
More information available in do following Websites:
http://tcpmag.com/qanda/article.asp?EditorialsID=317
http://www.synapse.de/ban/HTML/P_LAYER2/Eng/P_lay207.html
http://www.faqs.org/rfcs/rfc1469.html
VACL, VLAN Maps & MAC ACL August 23, 2008
Posted by cauew in Layer 2 Protocols, Security, Switching.add a comment
A while back, more specific in July/14 we talked briefly about VACLs. That was when I took the IPExpert Volume 1 – Section 2: Quad Catalyst (PVST+) Switch Configuration. It´s not a very difficult task to be achieved, but TRICKY!
A friend from India (yeah Vipul, it´s you buddy!) asked me some things about it. So I´ll just elaborate it a while more. Also, at IPExpert CCIE R&S BLS you´ll find more info regarding that in the Security Section. It´s really well explained there! I would take sometime and review it with attention. The first time I watched it, I was like moving back and forward all the time to take notes, and to really stick the info in my head!
So, starting with the basics… In a L2/L3 switch (like the ones in the CCIE Lab), where we can implement security?! Well, we can do it at the:
-
Port Level – We can implement an Access-List in a particular port, and that will affect the traffic coming and going out of it (normally, it´ll affect only one host traffic). But imagine to implement that solution in many ports, over several equipment. Not very nice, right?!
-
SVI - We can also implement an Access-List at the SVI Port! It´ll work everytime your switch is routing traffic between this particular VLAN and some other! Essentially, it´ll filter the traffic passing through the SVI.
Ok! So… Port-Level filters only that particular port…. SVI the routed traffic… and how about the INTRA-VLAN Traffic?! None of them will filter that!
VLAN Access-Lists (or VACL) works exactly there! At the Intra-VLAN Traffic! So everytime you need to filter internal traffic for a particular VLAN, VACL is your choice!
Just a couple more things to have in mind before getting into an example.
-
IP Packets can only be processed by IP Access-Lists;
-
Non-IP Packets like ARP, MAC-Addresses, and others can only be processed by MAC Access-Lists.
The MAC Access-Lists will bring all the interesting issues to the table… just check it out!
Let´s suppose for example you have two computers one with MAC Address 000b.dc24.ca47 and the second with the MAC Address 000b.dc25.cb51, both connected to VLAN7, and you want to allow all "non-IP" frames sourced from those two MAC Addresses to be forward anywhere, and also allowing only ICMP for example, denying everything else!
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 AllowThose 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 preffer 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 0×0806 0×0000 permit any any lsap 0xAAAA 0×0000 |
But wait a minute! What´s that 0×0806 and lsap 0xAAAA ?! That´s the Ethertypes we´re allowing in our MAC Access-List, first one (0×806) 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 0×0806 0×0000 permit any any lsap 0xAAAA 0×0000 ! 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)
- 0×0806 = ARP
- lsap 0xAAAA = PVST+
- 0×4242 = STP and PVST
- 0×86DD = 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.
VACL, VLAN Maps & MAC ACL August 23, 2008
Posted by cauew in Layer 2 Protocols, Security, Switching.3 comments
A while back, more specific in July/14 we talked briefly about VACLs. That was when I took the IPExpert Volume 1 – Section 2: Quad Catalyst (PVST+) Switch Configuration. It´s not a very difficult task to be achieved, but TRICKY!
A friend from India (yeah Vipul, it´s you buddy!) asked me some things about it. So I´ll just elaborate it a while more. Also, at IPExpert CCIE R&S BLS you´ll find more info regarding that in the Security Section. It´s really well explained there! I would take sometime and review it with attention. The first time I watched it, I was like moving back and forward all the time to take notes, and to really stick the info in my head!
So, starting with the basics… In a L2/L3 switch (like the ones in the CCIE Lab), where we can implement security?! Well, we can do it at the:
-
Port Level – We can implement an Access-List in a particular port, and that will affect the traffic coming and going out of it (normally, it´ll affect only one host traffic). But imagine to implement that solution in many ports, over several equipment. Not very nice, right?!
-
SVI - We can also implement an Access-List at the SVI Port! It´ll work everytime your switch is routing traffic between this particular VLAN and some other! Essentially, it´ll filter the traffic passing through the SVI.
Ok! So… Port-Level filters only that particular port…. SVI the routed traffic… and how about the INTRA-VLAN Traffic?! None of them will filter that!
VLAN Access-Lists (or VACL) works exactly there! At the Intra-VLAN Traffic! So everytime you need to filter internal traffic for a particular VLAN, VACL is your choice!
Just a couple more things to have in mind before getting into an example.
-
IP Packets can only be processed by IP Access-Lists;
-
Non-IP Packets like ARP, MAC-Addresses, and others can only be processed by MAC Access-Lists.
The MAC Access-Lists will bring all the interesting issues to the table… just check it out!
Let´s suppose for example you have two computers one with MAC Address 000b.dc24.ca47 and the second with the MAC Address 000b.dc25.cb51, both connected to VLAN7, and you want to allow all "non-IP" frames sourced from those two MAC Addresses to be forward anywhere, and also allowing only ICMP for example, denying everything else!
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 AllowThose 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 preffer 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 0×0806 0×0000 permit any any lsap 0xAAAA 0×0000 |
But wait a minute! What´s that 0×0806 and lsap 0xAAAA ?! That´s the Ethertypes we´re allowing in our MAC Access-List, first one (0×806) 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 0×0806 0×0000 permit any any lsap 0xAAAA 0×0000 ! 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)
- 0×0806 = ARP
- lsap 0xAAAA = PVST+
- 0×4242 = STP and PVST
- 0×86DD = 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.
ARP, RARP, Proxy ARP, Gratuitous ARP and IP Redirect August 14, 2008
Posted by cauew in L3 Stuff, Layer 2 Protocols, Switching.2 comments
Well… after a while away from my computer (in fact, away from any computer) due to some medical issues I´m back! Don´t worry, nothing bad, it was scheduled already, and I had the company of my wife, and guess who?! Yeah! Him! Mr. Jeff Doyle, not in person, but in his book version!
Books like TCP/IP Vol. 1 and 2 MUST be read from cover to cover! Always a good thing to learn!
Some of you may think, ARP, too basic… Yeah, I think too, but there were more than 10, 20 times that people who were supposed to know this asked me HOW it works… so here (with mr. Doyle´s help) you´ll find ARP some variations of it.
ARP
Address Resolution Protocol (ARP) is used to map a known IP Address to a unkown data-link identifier (for example MAC Address). The ARP Request will contain:
-
Source IPv4 Address;
-
Source data-link identifier address (MAC Address for example);
-
Destination IPv4 Address;
-
Destination data-link identifier (MAC Address in our example) will be set to 00:00:00:00:00:00.
Check this ARP Request capture:
|
Ethernet II, Src: 00:30:b8:83:cb:40, Dst: ff:ff:ff:ff:ff:ff |
By default Cisco Routers holds the ARP entries for 4 hours. You can change this value per interface basis with the command: arp timeout <value in seconds>. Example:
| interface fastethernet 0/0 arp timeout 3600 |
RARP
RARP is the opposite of ARP, it maps an IPv4 Address to a know MAC Address, for example, old workstations (dumb terminals) could have it´s firmware programmed to send a RARP request as soon as it was powered up, and a RARP Server would answer this RARP request with the workstation´s IP Address (Airline Companies used it ALOT in the past). Hmmm.. looks like DHCP right?! Yeah.. it looks, but it ISN´T ok?!
RARP Request will contain:
-
Source and Destination data-link identifier (MAC Address in this example) will be the local host MAC Address;
-
Source and Destination IP Address will be set to 0.0.0.0.
Check this example capture of a RARP Traffic:
|
Ethernet II, Src: Marquett_12:dd:88, Dst: ff:ff:ff:ff:ff:ff
—> EXAMPLE TOOK FROM Wireshark Wiki <— |
Proxy ARP
A Proxy ARP enabled Router answers ARP requests intended for another machine, it does that by making the local host believe that the Router is the "owner" of that IP Address, local host will forward the traffic to the Router and the Router will be responsible to "route" the packets to the real destination.
For example, a Host in Subnet A wants to send traffic to Host in Subnet B, Host A and Host B are in the same subnet, but in different broadcast domains. Host A will send an ARP Request with Host B IP Address, the Router connected to both subnets will answer to Host A request using it´s own MAC Address instead of Host B MAC Address.
Now when Host A wants to transmit traffic to Host B, it´ll send to the Router MAC Address and the Router will just forward the traffic to Host B. That´s why "Proxy ARP".
It´s used on networks where the hosts are not configured with a default-gateway.
Oh yeah… it´s enabled by default in the Cisco IOS, and you can disable it on a per-interface basis with the command: no ip proxy- arp
Gratuitous ARP
In some circunstances a Host (Router, Switch, Computer, etc) might send an ARP Request with it´s own address as the target address… But, to his own address?! Why a host would do that!?
Well… there are some reasons… for example:
-
It´s use to update other devices ARP Table (when a device receives an ARP Request with an IP that it´s already in it´s cache, the cache will be updated with the new information;
-
HSRP Routers that takes over the control will send Gratuitous ARP out the network to update the cache table of other devices ;
-
To check for duplicate addresses (if the host receives a response, it´ll know that somebody is using the same IP Address).
You can check this Gratuitous ARP traffic captured with Wireshark (the best opensource sniffer out there):
|
Ethernet II, Src: 02:02:02:02:02:02, Dst: ff:ff:ff:ff:ff:ff
—> EXAMPLE TOOK FROM Wireshark Wiki <— |
IP Redirect:
IP Redirect is used by routers to notify hosts of another router on the data link that should be used for a particular destination.
For example, Router A and Router B are connected to the same Ethernet Segment, so as Host C. Host C has Router A set as default-gateway, Host C will send the packets to Router A, and Router A sees that the destination address of the packet is reachable via Router B, so Router A must forward the packets out the same interface it has received to Router B. Router A does that, and also, sends an ICMP Redirect to Host C informing to use Router B to reach this particular destination next time.
IP Redirect is enable by default in IOS Routers and can be disabled on a per interface basis with the command: no ip redirects.
That´s it! I´ll lie down a while, my head is a little fuzzy right now!
L2-Tunnels August 4, 2008
Posted by cauew in Layer 2 Protocols.3 comments
This weekend was a bit more productive than last one! I was able to finish Day 1 of IPExpert CCIE R&S Blended Learning Solutions, plus, I got time to do some reading through Doyle´s TCP/IP Book! That was cool! I just need to keep my notes all together, and made that "understandable" to blog it!
Let´s start with L2-Tunnels, I still having some Switching notes I want to blog about, but, I´ll work a little more on them before it! In the mean time, L2-Tunneling, that was kind of "unknown" topic for me, seens quite simple now, as usual, there are some tricks to be aware about (like looping in our topology) and everything else like that!
Let say you want (or even better, your lab task want) you to have R1 and R2 showing each other as neighbors in CDP, without any action, using our topology above, if I type show cdp neighbors in R1, it´ll show me SW1 as a neighbor, same goes to R2, that will show SW2 as neighbor…
So, how to accomplish?! Using L2-Tunnels. L2-Tunnels are used to get the switches in the middle (in our case SW1 and SW2) to tunnel L2 information and passes it to the other device (R1 and R2), even if we know the normal behavior of a switch is to process CDP, PaGP, STP packets locally, they´ll tunnel it (according to what we actually configure in the switch), and just forward to the other end.
Keep in mind that switch ports cannot be in "dynamic" mode, they must be in "access" or "dot1q-tunnel". Otherwise our L2-Tunnel will not work.
Configuration to complete this task is really straight-forward (those commands apply to both switches SW1 and SW2 edge ports – connected to the routers R1 and R2 in this case):
| int f0/5 switchport mode access switchport access vlan 12 no cdp enable L2protocol-tunnel cdp |
Now, VLAN 12 is "trunked" through switches! All switches in the middle are just "L2 Trunks" that will carry information normally from one side to another.
Another thing to keep in mind is: Multicast (and broadcasts) are flooded to all available ports, so make sure VLAN 12 (in our case) used for carrying L2 Tunnel does not come back to original end switches, because Loopguard will disable ports if so. Use switchport trunk allowed to filter it. This is very important!!!!
If, you want that R1 shows SW1 and R2 as CDP Neighbors, just enable CDP in the switch fastethernet port (cdp enable), and that´s it!
Integrated Routing and Bridging Example July 22, 2008
Posted by cauew in Layer 2 Protocols.3 comments
Here follows an example of IRB, that will probably make our understanding about this topic a bit easier. This scenario was based in the Video on Demand from IPExpert CCIE R&S Blended Learning Solutions. A full video dedicated just to it is available in there, and I recommend you to check it out! It rocks!
Take a look at the topology:
Those VLANs (VLAN2 and VLAN3) will be bridged through our serial link.
In order to do that, we need to:
-
Create the Bridge-Group;
-
Assign this Bridge-Group to our Interfaces;
-
Create the BVI Interface and assigns an IP Address to it;
-
Create our rules (specifically tell this particular Bridge- Group to Route IP) .
First… what is the function of a "Bridge-Group" ?! Well "Bridge-Group" job is to take packets to an unknow destination and flood them out any available ports, or more important, to learn were those available ports are for each them.
The catch is, the router can do routing, can do bridging, but in other to do both, like some interfaces to route, some interfaces to bridge we need to use IRB (Integrated Routing and Bridging).
Take a look in the configuration for all devices involved, interfaces FastEthernet0/0 and Serial1/1 in our routers R2 and R3 were assigned to Bridge-Group 1, all interfaces between the origin and destination will be "bridged", the IP Address will be assigned to the BVI Interface, take a look:
|
R2: int f0/0 R3: int f0/0 SW2 int f1/2 SW3 int f1/3 |
To make double-sure about our IP assignment, we can use the show ip int brief command:
|
R2#sh ip int brief R3#sh ip int brief |
Everything looks good, BVI interface has it´s IP Addresses, and both FastEthernet and Serial interfaces don´t!
Using the command show bridge 1 verbose we can check which interfaces belongs to this specific Bridge-Group:
|
R2#sh bridge 1 verbose Flood ports (BG 1) RX count TX count |
Seens fine too! So, what next?! Testing! How?! Ping!!!
|
R2#ping 111.111.111.22 Type escape sequence to abort. Type escape sequence to abort. Type escape sequence to abort. ————— R3#ping 111.111.111.2 Type escape sequence to abort. Type escape sequence to abort. Type escape sequence to abort. ————— SW2#ping 111.111.111.2 Type escape sequence to abort. Type escape sequence to abort. Type escape sequence to abort. ————— SW3#ping 111.111.111.3 Type escape sequence to abort. SW3#ping 111.111.111.2 Type escape sequence to abort. SW3#ping 111.111.111.22 Type escape sequence to abort. |
Now we have reachability between the two vlans! We can use the command show bridge 1 verbose again to check the counters and the interfaces involved in this particular bridge group:
|
R2#sh bridge 1 verbose Total of 300 station blocks, 297 free BG Hash Address Action Interface VC Age RX count TX count Flood ports (BG 1) RX count TX count R3#sh bridge 1 verbose Total of 300 station blocks, 297 free BG Hash Address Action Interface VC Age RX count TX count Flood ports (BG 1) RX count TX count |
Just for curiosity, show arp at R3…
|
R3#sh arp |
…and show arp at SW2:
|
SW2#sh arp |
As you can see, everything is working fine! I do recommend you to check IPExpert Bridging Videos, and also Cisco DocCD for more information!
Follows some usefull links:
http://www.cisco.com/en/US/tech/tk389/tk815/technologies_tech_note09186a0080094663.shtml
Bridging & Integrated Routing and Bridging July 21, 2008
Posted by cauew in Layer 2 Protocols.1 comment so far
Everything went wrong this last weekend, I was a bit sick with fever and all this kind of stuff, and spent more time in bed, than actually doing anything else… That delayed me a little, I had plans to complete Workbook Volume 1 labs 3 and 4 this weekend but that wasn´t possible!
Today I´m better, really better, and in my lunch time I reviewed IPExpert CCIE R&S BLS Bridging Video. Nice topic, this is something we don´t get to see every day! In fact… I´ve never saw anything actually "bridged" in a network, and even it´s not on blueprint anymore we can still having some IRB Bridging. So I´ll spent more time on that for sure!
Couple quick notes I was able to get from the Video:
Basic job of a bridge is to bring things together, transparent bridging does that using the same media type, same MTU size, nothing changes!
Bridging on Routers:
Setup the basic bridge function:
-
Bridge 1 protocol ieee
Then bind to interfaces:
-
Bridge-group 1
If Frame-Relay is in the middle:
-
Frame-relay map bridge <DLCI>
Integrated Routing & Bridging:
Allows selective routing some protocols while bridging others:
Enable Bridge IRB in a router:
-
Bridge irb
Configure a BVI (Bridging Virtual Interface):
-
Interface bvi 1
-
ip address <address> <mask>
Create our "rules", in other words tell bridge-group 1 to route IP.
-
Bridge 1 route ip
Interfaces in middle simply have bridging.
A cool command to verify if everything is working (AFTER ping testing):
-
Show bridge 1 verbose
It seens a little confuse, but with the example showed in the Video on Demand you´re able to get it! I´ll try to create a Dynamips topology to simulate a bridging scenario and post back later, to clarify things a bit better either for you reading this, and for me!
PPP Video on Demand (IPExpert CCIE R&S BLS) July 15, 2008
Posted by cauew in Layer 2 Protocols, Video On Demand.add a comment
Today I was watching the PPP Video-on-Demand from IPExpert´s CCIE R&S Blended Learning Solutions, and learned some new tricks! AWESOME!
PPP is fair simple, configuring it is not that difficult, BUT, as always, there are a couple tricks we can be asked in the exam, and that´s exactly WHERE the Video-on-Demand comes to rescue!
The worse thing that they could ask in the exam about PPP is Authentication! Otherwise, we just set the encapsulation to ppp bring our interfaces up and that´s pretty much it!
In the PPP Video we get the chance to review some scenarios, not difficult ones, but trick!
First, let´s take a look at the topology used in our simulation (again, I was running it in Dynamips, if anybody wants the .NET files, just let me know):
First scenario: R2 should initiate a secure authentication request to R3.
So, how to complete this task?!
Secure means the password cannot be sent in Clear-Text, so PAP is out, we can use CHAP! CHAP sends a MD5 hash, so it´s good!
But, how can we make sure R2 will initiate the authentication, and not R3?! Well… in fact it´s very simple (I didn´t knew about that so far), use the command ppp authentication chap only in R2. The ppp authentication command only specifies what you´re going to send out as an authentication requirement not what you´re going to respond to, you always responding to stuff.
So, our configuration will look pretty much like this one:
| R2: username R3 password 0 cisco ! interface Serial1/1 R3: username R2 password 0 cisco |
To BE SURE that R2 is initiating the request, we can run a debug ppp authentication in both routers and check the Outgoing (O) and Incoming (I) requests, take a look yourself:
|
R2(config-if)#do debug ppp authentication R3(config-if)#do debug ppp authentication Se1/1 CHAP: I CHALLENGE id 1 len 23 from "R2" |
So what´s next?! Just try to ping from both sides, and you should be ok at your exam! Nothing more to worry about!
Second scenario: R2 and R3 should be configured to PPP Authentication using DIFFERENT secure authentication protocols.
Hmmm… is that possible?! Yeah, it is! We´ll be using CHAP in R2, and EAP in R3, and everything will be good!
Check the configuration of both routers:
| R2:
username R3 password 0 cisco R3: username R2 password 0 cisco interface Serial1/1 |
Seens pretty straight-forward! Just a quick overview of this configuration:
In R2 the command ppp eap password cisco needs to be used, because the password in EAP doesn´t need to be symmetric, so we MUST configure it in the CHAP side of the link.
Regarding the ppp eap local configured in R3, this command means, use the LOCAL database (that means username R2 password cisco) for authentication, instead of a Radius Server. If you do not use this command, EAP will expect to have a Radius Server to authenticate the connection, and we do not have it!
Doing that, R2 and R3 will be configured with two different secure authentication protocols! We´re good! That´s what we were asked for!
Take a look at this Debug Output:
|
R2(config-if)#do debug ppp authentication R3(config-if)#do debug ppp authentication |
Again, a ping test will not hurt (it worked for me in my Dynamips simulation).
Those are the kind of situations we may encounter during the exam, and for sure, after watching this PPP Video that will not cause me any problems! Cool!
There are a lot more tips and advices like that in the Video (not only for PPP, but for everything), you have to check it out! 
PPP over Frame-Relay Example July 11, 2008
Posted by cauew in Layer 2 Protocols.add a comment
Until few days ago, PPP over Frame-Relay was a bit confusing to me, not that I knew it or not, but I´d never configured it so far, just saw it on theory…
This week, after checking the VoD from IPExpert, things became much easier!
To clear things out, PPP over Frame-Relay is used to bundle PVCs together (or also for authentication over Frame-Relay links).
Frame-Relay multilink is used to bundle LINKs together.
So, in this example, we´ll be checking the PPP over Frame-Relay option, take a look at the topology used:
Ok! First things first, the drawing is not showing the PVCs that we´re supposed to be using, so… how can we check this information?! Well… in fact it´s pretty easy… We can just configure the Serial Link with Frame-Relay encapsulation and check the PVCs (sh frame-relay pvc) configured in our Frame-Relay Switch (not in the diagram):
|
R1, R2, R3 int s1/0 |
After the sh frame-relay pvc command, we can see that we have a FULL-MESH network, but, we´re not going to use them all!
According to the drawing, we need two PVCs between R1 and R3 (103, 113 and 301, 311), as far as the task is not asking for anything specific, we can use any PVC that we want to achieve the goal. Also, we need only one PVC between R1 and R2 (102 and 201). How about the others?! Well… leave them for now, they´re not going to be used in this task!
|
R1(config-if)#do sh frame pvc | in ACT R2(config-if)#do sh frame pvc | in ACT R3(config-if)#do sh frame pvc | in ACT |
Now… in order to configure PPP over Frame-Relay, we need to create a virtual-template interface, and point the DLCIs that we´re going to be using to this virtual-template interface that we just created, take a look on how all three routers were configured (in this specific case, R1 and R3 are the only ones using PPP over Frame-Relay):
|
R1 int virtual-template 1 R2 int s1/0.201 point-to-point R3 int virtual-template 1 |
So, time for a quick test?! Yeah! It is! Let´s try to ping R2 and R3 from R1:
|
R1(config-fr-dlci)#do ping 200.200.220.2 Type escape sequence to abort. R1(config-fr-dlci)#do ping 200.200.230.3 Type escape sequence to abort. |
It worked! Things seens good, don´t you think?! If we check the interfaces at R1 (show ip int brief), we can see our Virtual-Template1 interface down and what in the world are those Virtual-Access interfaces?! We never configured those!
In fact, the Virtual-Template will remain down, and each time the PPP connection gets reseted (up, down, up again, shut, or anything else) a new Virtual-Access interface (one for each DLCI) will be created and those are the interfaces that will remain up/up for our connection. So the Virtual-Access interfaces are created everytime the PPP connection gets up!
|
R1(config-if)#do sh ip int brief |
A good thing to do also is to check the Routing Table…
|
R1(config-fr-dlci)#do sh ip route Gateway of last resort is not set C 200.200.220.0/24 is directly connected, Serial1/0.102 |
The /32 entry was created by the PPP, and both Virtual-Access2 and Virtual-Access3 interfaces are there also, so what does the routing protocols will do?! They will load balance, and that´s not what we want in first place!
To solve it, we just go into the Virtual-Template interface and "multilink" them together, using the command ppp multilink, this will create another Virtual-Access interface that will bundle to two others!
|
R1, R3 int virtual-temp 1 |
To check if the interfaces are bundled together, we can use the following show command: show ppp multilink.
|
R1#sh ppp multilink Virtual-Access4, bundle name is R3 R3(config-if)#do sh ppp multilink Virtual-Access4, bundle name is R1 |
And finally, we can check our routing table, and we see just the newly created Virtual-Access interface over there! Much better for our Routing Protocols!
|
R1(config-fr-dlci)#do sh ip route Gateway of last resort is not set C 200.200.220.0/24 is directly connected, Serial1/0.102 |
These little notes about PPP over Frame-Relay were based on the Frame-Relay VoD from IPExpert CCIE R&S BLS, an extremelly helpfull resource for me so far!
Also, I´ve simulated this on Dynamips, so, if anyone wants the .NET file, just let me know, and I can forward it to your email!