Just another Cisco blog
Weekly Open Ended Question #10
The answer to the ninth question has been added to the post.
Tenth question:
What are ISL and 802.1q, and how do they differ?
Please post answers in the comments (without Googling)!
Highlight for answer:
These are both VLAN trunking protocols. ISL is a Cisco proprietary protocol, while 802.1q is an IEEE standard. ISL encapsulates the entire frame and has no “Native VLAN”.
Related Posts:
| Print article | This entry was posted by Colby on April 9, 2010 at 12:31 pm, and is filed under Open Ended Questions. Follow any responses to this post through RSS 2.0. You can leave a response or trackback from your own site. |
No trackbacks yet.
OSPF Quiz
about 3 months ago - 6 comments
I had an interesting conversation the other day regarding OSPF. I don’t want to give too much away, so here we go. This is the topology:
Assume interfaces have correct bandwidth statements and no cost commands have been added. R1 and R2 are redistributing the 192.168.1.0/24 prefix as E2 with a cost of 100.
Which path does R4 take to the 192.168.1.0/24 network? Does it load balance? Explain.
I started a thread on Networking-Forum on this as well. Post your answer here in the comments or over there.
Update: Here’s another question. What happens if we change it to:
Everything is the same except R2 is now redistributing as E1. Which path and why?
Related Posts:
ASA Bridge Groups
about 5 months ago - 2 comments
Hello everyone. I know I’ve been neglecting this blog for too long. Can’t promise that things are going to change, but I have a good post for today.
I was recently exposed to some new technology while working with a customer. I had to learn it pretty quickly. This post is about a new feature in the Cisco ASA 8.4 code called Bridge Groups. This is essentially the addition of BVI interfaces, which have existed in IOS forever. This feature is useful when running an ASA transparently, but not physically inline. Running a firewall physically inline works well, but it can limit you to the number of available interfaces you have on each firewall. Adding physical interfaces to a firewall is expensive. This feature also saves you from using a context per firewalled VLAN on your ASA. Here we’ll use a 3750 for physical connectivity and use BVIs to force traffic through the firewall. Here is the physical topology:
I’m trying to convey quite a bit of information with this diagram. We have a layer 3 switch as the “core” and an ASA 5505 trunked to it. We have two hosts, PC1 and Server which are in VLAN 50 and VLAN 25, respectively. VLAN 26 is only for management of the ASA. VLAN 50 (and 2050) is where we’ll focus for this post. I’m going to start with the config here as I think it will make more sense when I try to explain.
3750 Config:
vlan 25 name Servers vlan 50 name L2_Firewalled_Vlan50 vlan 2050 name L3_Firewalled_Vlan50 interface GigabitEthernet1/0/5 description ASA Inside switchport trunk encapsulation dot1q switchport trunk allowed vlan 26,50 switchport mode trunk spanning-tree portfast interface GigabitEthernet1/0/7 description ASA Outside switchport trunk encapsulation dot1q switchport trunk allowed vlan 2050 switchport mode trunk spanning-tree portfast interface Vlan25 description Servers-Media ip address 192.168.25.1 255.255.255.0 interface Vlan2050 ip address 192.168.50.1 255.255.255.0 |
This config is pretty basic. We have created some VLANs, configured some trunks and SVIs, etc. The key thing to notice here is that there is no L3 for VLAN 50, the L3 for PC1 exists in VLAN 2050.
ASA Config:
firewall transparent interface Ethernet0/1 switchport trunk allowed vlan 26,50 switchport mode trunk interface Ethernet0/2 switchport trunk allowed vlan 2050 switchport mode trunk interface Vlan26 nameif management bridge-group 2 security-level 100 interface BVI2 ip address 192.168.26.5 255.255.255.0 interface Vlan50 nameif inside bridge-group 1 security-level 100 interface Vlan2050 nameif outside bridge-group 1 security-level 0 interface BVI1 ip address 1.1.1.1 255.255.255.0 access-list inside-in extended permit ip any any access-group inside-in in interface inside route management 0.0.0.0 0.0.0.0 192.168.26.1 |
This is where the magic happens. First, we configure the firewall in transparent mode, then we configure out interfaces and allow the necessary VLANs, 50 and 26 (management) on the e0/1, which is the “inside” interface, and 2050 on e0/2, which is the “outside” interface. We then configure VLAN 26 for management and add it to bridge group 2, which has an IP and default route configured at the bottom, again, this is for management only. Then we configure VLANs 50 and 2050 with 50 as inside and 2050 as outside. Both VLANs are in bridge group 1. In my testing it appears that the BVI interface REQUIRES an IP address to pass traffic, but which IP you pick seems irrelevant, so I’ve used 1.1.1.1/24 here. Finally we have our inside-in access-list allowing any to any and we’ve applied it to the inside interface inbound.
Hopefully this is beginning to make sense. Essentially, all PC1 traffic destined outside of its subnet will traverse the firewall. When PC1 initiates traffic outside of its subnet, it will ARP for its gateway, which will begin on VLAN 50, then be bridged through the firewall to VLAN 2050. The 3750 will reply on 2050 which will be sent back to 50. All L3 traffic should flow this way. I’ve tried to make a diagram to show the flow:
Let’s do some testing:
C:\Users\PC1>telnet 192.168.25.10 22 SSH-2.0-OpenSSH_5.2 Protocol mismatch. Connection to host lost. C:\Users\PC1> |
Here we see that SSH is open from PC1 to Server.
Now let’s break that connectivity:
ASA(config)# access-list inside-in extended deny tcp any host 192.168.25.10 eq ssh ASA(config)# no access-list inside-in extended permit ip any any ASA(config)# access-list inside-in extended permit ip any any ASA(config)# sh run access-list inside-in access-list inside-in extended deny tcp any host 192.168.25.10 eq ssh access-list inside-in extended permit ip any any |
We added a deny statement for anything originating from the inside destined to TCP port 22 on Server and we allow everything else. We have verified that the ACL is correct.
Let’s test again:
C:\Users\PC1>telnet 192.168.25.10 22 Connecting To 192.168.25.10...Could not open connection to the host, on port 22: Connect failed C:\Users\PC1> |
The results are rather anti-climactic. The session just does not work.
It looks a bit more interesting on the ASA:
ASA# sh logg %ASA-4-106023: Deny tcp src inside:192.168.50.100/49198 dst outside:192.168.25.10/22 by access-group "inside-in" %ASA-4-106023: Deny tcp src inside:192.168.50.100/49198 dst outside:192.168.25.10/22 by access-group "inside-in" %ASA-4-106023: Deny tcp src inside:192.168.50.100/49198 dst outside:192.168.25.10/22 by access-group "inside-in" |
We see the session being denied on the ASA as expected.
That’s about it for this one. We can now run our transparent firewalls through an intermediate switch and we’re also able to run multiple VLANs through a transparent firewall without using up contexts. All we need to do to allow more VLANs to be firewalled is create the L2/L3 on the switch, add the VLANs to the trunks and configure the ASA with the appropriate SVIs and bridge groups (and ACLs). Hope this was useful.
Disclaimer: This is a very new feature to me. It’s working well in the lab, but please let me know if I have anything wrong or there is a better way to accomplish something.
Related Posts:
Free CCNA Practice Questions
about 11 months ago - No comments
Steve over at Networking Forum came up with another great idea. He’s offering free CCNA practice questions. He’s asked the members to assist with providing the questions and answers. So far, there are about 30 questions posted, with more to come. They’re all multiple choice, but we’ve included some drag and drop type questions and some troubleshooting/simulation type questions as well (as much as we could while keeping them multiple choice). I’ll post a couple sample question below.
Related Posts:
2960s Can Route
about 11 months ago - 13 comments
I’ve been meaning to post this for some time. Awhile back there was a thread on Networking Forum where someone mentioned that 2960s can route now. The 2960 is now a layer 3 switch. I was skeptical, but then I was pointed to this link. I was very, very surprised. I’m not sure why Cisco decided to add this functionality to the 2960s, but I’m definitely grateful. As of 12.2(55)SE, 2960s are layer 3 switches (with some limitations which I’ll cover later). This knowledge came in handy shortly after reading that thread. I was working on a circuit upgrade for a remote side at my previous company. The circuit was ordered incorrectly and I ended up in need of a layer 3 switch ASAP. The tech we’d sent was leaving the next day, so there was no time to ship him anything. Luckily, we had some 2960s on site.
Configuring 2960s to route is pretty simple. The Switch Database Management template (SDM) needs to be changed to “lanbase-routing”. A reboot is (always) needed after changing the SDM template. After reboot, it’s just like enabling routing on any other L3 switch with the command “ip routing” from global config.
First we’ll change the SDM template:
SwitchA(config)#sdm prefer lanbase-routing Changes to the running SDM preferences have been stored, but cannot take effect until the next reload. Use 'show sdm prefer' to see what SDM preference is currently active. SwitchA(config)#^Z SwitchA#reload System configuration has been modified. Save? [yes/no]: y Proceed with reload? [confirm] |
After changing the SDM template, we are reminded that we’ll need to reboot and also given a command to verify the change after the next boot.
Now we verify:
SwitchA#show sdm prefer The current template is "lanbase-routing" template. The selected template optimizes the resources in the switch to support this level of features for 8 routed interfaces and 255 VLANs. number of unicast mac addresses: 4K number of IPv4 IGMP groups + multicast routes: 0.25K number of IPv4 unicast routes: 4.25K number of directly-connected IPv4 hosts: 4K number of indirect IPv4 routes: 0.25K number of IPv4 policy based routing aces: 0 number of IPv4/MAC qos aces: 0.125k number of IPv4/MAC security aces: 0.375k |
The change was successful and we’re given the details about this SDM template.
Now seems like a good time to touch on the limitations of the layer 3 capabilities on 2960s. As we see in the output above, we’re limited to 8 routed interfaces. These will be SVIs. At this point, the 2960s don’t support routed physical interfaces (“no switchport”). Another important note is that we’re only allowed 16 static routes and there is no dynamic routing capability.
Now we’ll enable IP routing and configure a couple SVIs:
SwitchA#conf t SwitchA(config)#ip routing SwitchA(config)# SwitchA(config)#int vlan 15 SwitchA(config-if)#ip add 192.168.15.1 255.255.255.0 SwitchA(config-if)# SwitchA(config-if)#int vlan 25 SwitchA(config-if)#ip add 192.168.25.1 255.255.255.0 SwitchA(config)#^Z SwitchA#sh ip route ... C 192.168.15.0/24 is directly connected, Vlan15 C 192.168.25.0/24 is directly connected, Vlan25 |
Even now, I’m still amazed that we can do this with a 2960. As expected, it’s working. We have two SVIs and we can see the routing table reflect this.
As you can all see, I’m still pretty wowed. There are many scenarios where layer 3 2960s could be useful.
Related Posts:
Connecting Voice Gateways/CME to the PSTN
about 11 months ago - No comments
Today we’ll go over the process to connect an IOS voice gateway/CME (Call Manager Express) to the PSTN. I set this up last night and thought it would be a good post. I’ll briefly touch on using a SIP trunk as backup/failover too.
I’ve been running a SIP trunk to Flowroute for quite awhile, but I just recently got a “landline” from my ISP because they’re doing a promotion where it’s basically free. I’m keeping my SIP trunk, but I’ll be using it as backup since all US calling through the ISP is free. I’m using a 2811 with an NM-HD-2V and a VIC2-4FXO.
First we’ll verify that the card is recognized and working:
EDGE#sEDGE#sh voice port summ
IN OUT
PORT CH SIG-TYPE ADMIN OPER STATUS STATUS EC
=============== == ============ ===== ==== ======== ======== ==
1/1/0 -- fxo-ls up dorm idle on-hook y
1/1/1 -- fxo-ls up dorm idle on-hook y
1/1/2 -- fxo-ls up dorm idle on-hook y
1/1/3 -- fxo-ls up dorm idle on-hook y |
Everything looks good there, the router is recognizing the card and its ports. 1/1/0 is connected to the ISP’s MTA.
Now we’ll configure the dial peers:
dial-peer voice 1 pots preference 1 destination-pattern 1[2-9].[1-9]....... incoming called-number .T port 1/1/0 forward-digits all ! dial-peer voice 2 pots preference 1 destination-pattern 1800....... incoming called-number .T port 1/1/0 forward-digits all ! dial-peer voice 3 pots preference 1 destination-pattern 911 incoming called-number .T port 1/1/0 forward-digits all |
We’ve configured three dial peers here. First note that the dial peer type is “pots”, this is used when the destination is an analog port (like FXO). Next you see the “preference” command, lower is better, making these peers more preferred than my SIP peers (with a preference of 2). The “destination-pattern” command is matching the dialed string, sort of like a static route. For the first dial peer, We’re matching 11 digits including the 1, area code (digits 2 through 9, wildcard which matches 0 through 9, and then digits 1 through 9), then seven wildcards matching 0 through 9. This is my convoluted way of blocking 900 numbers. For the incoming call, we’re matching any digits. The “port” command tells the router where to send the call when it matches the patter, port 1/1/0 here. Then we tell the router to forward all digits. This is important because it will strip the explicitly defined digits, which we don’t want here, we want all digits sent to the PSTN.
Next we’ll configure incoming calling, using Private-line Automatic Ringdown (PLAR):
voice-port 1/1/0 connection plar 5001 caller-id enable |
Not much to that one. We go into the port config and use the “connection plar ” command. PLAR tells the router to automatically forward to an extension when the line goes off-hook. So when this port gets an incoming call from the PSTN (which takes it off-hook), it will instantly forward it to extension 5001. We’ve also used the “caller-id enable”, which is pretty self-explanatory; it enables incoming caller-id on this FXO port.
That’s all for this one. This could be the first(ish) of many voice-related posts. I’ll be moving through the voice exams (hopefully quickly) in the next few months and if there is interest, I can try to do some posts on things I’m learning/studying. Real voice (CUCM) can be tough blog about because it’s mostly GUI based, which requires (lots of) screenshots. Making 11ty screenshots for every post could get old quick. Post in the comments if you’d like to see voice topics, and if you have anything specific you’d like to read about.
Disclaimer: I am, by no means, a voice guy (yet?), so if you see any errors please let me know in the comments. I can say that this works, but I wouldn’t doubt if it’s not the “best” way.
Related Posts:
show ip ospf rib
about 11 months ago - 7 comments
Another quick one. Today I’m going to cover a simple, but very useful OSPF command: “show ip ospf rib”. This command is similar to “show ip route ospf”, but goes a bit deeper.
If you’ve ever done a routing protocol migration, you know how important it can be to see each protocol’s full routing table. Much of the time AD makes this difficult. Administrative Distance (AD) is the believability of a routing protocol on a Cisco device. The default AD values are:
Route Source |
Default Distance |
| Connected Interface | 0 |
| Static Route | 1 |
| EIGRP Summary | 5 |
| eBGP | 20 |
| Internal EIGRP | 90 |
| IGRP | 100 |
| OSPF | 110 |
| IS-IS | 115 |
| RIP | 120 |
| EGP | 140 |
| ODR | 160 |
| External EIGRP | 170 |
| iBGP | 200 |
| Unknown | 255 |
Lower is better. If a router has identical routes from RIP and OSPF, the OSPF routes will be added to the table. If it’s EIGRP versus OSPF, EIGRP will win.
Scenario:
Company ATN Solutions is migrating from EIGRP to OSPF. They’ve chosen to run both protocols simultaneously, while leaving the AD values at the default. This will allow both protocols to co-exist without affecting the routing domain. EIGRP routes will stay in the table due to EIGRP’s lower AD. I’m not going through the migrations steps or really any detail related to how this would be performed, just using this to demonstrate the command.
During this migration, we’ll need to verify that all existing EIGRP prefixes are also being learned by OSPF (we’ll use process number 200). If we were masochists, we could look at the LSDB to determine this, but that’s not really ideal. So we’ll use the “show ip ospf 200 rib”. First we’ll look at the existing RIB:
EDGE#sh ip route eigrp D 192.168.15.0/24 [90/28416] via 192.168.13.1, 00:00:12, FastEthernet0/0 D 192.168.25.0/24 [90/28416] via 192.168.13.1, 00:00:09, FastEthernet0/0 D 192.168.111.0/24 [90/28416] via 192.168.13.1, 00:00:04, FastEthernet0/0 D 192.168.10.0/24 [90/28416] via 192.168.13.1, 00:00:46, FastEthernet0/0 D 192.168.11.0/24 [90/28416] via 192.168.13.1, 00:00:19, FastEthernet0/0 EDGE#sh ip route ospf EDGE# |
We see five EIGRP routes and nothing for OSPF.
Now let’s try out the command:
EDGE#sh ip ospf 200 rib
OSPF local RIB for Process 200
Codes: * - Best, > - Installed in global RIB
* 192.168.10.0/24, Intra, cost 2, area 0
via 192.168.13.1, FastEthernet0/0
* 192.168.11.0/24, Intra, cost 2, area 0
via 192.168.13.1, FastEthernet0/0
* 192.168.15.0/24, Intra, cost 2, area 0
via 192.168.13.1, FastEthernet0/0
* 192.168.25.0/24, Intra, cost 2, area 0
via 192.168.13.1, FastEthernet0/0
* 192.168.111.0/24, Intra, cost 2, area 0
via 192.168.13.1, FastEthernet0/0 |
And there it is. We see that OSPF is learning the same prefixes as EIGRP. The output is similar to “show ip bgp” in that * = Best, and > = Installed. We could now, theoretically, feel comfortable in taking the next step on our migration path, maybe raising EIGRP’s AD to make OSPF more preferred.
That’s all for today. Another quick post to make up for my hiatus. Post any questions in the comments.
Related Posts:
Firewall Object Groups
about 11 months ago - No comments
Dropping in to do a quick post today. Sorry for the ridiculous lack of content lately. I’ve been busy with finding/changing jobs and new responsibilites and all that.
Today I’m going to cover “object groups” on ASAs. I was never a big fan of these, which I realized had a lot to do with using them behind others, not actually writing them myself. It takes awhile (for me, at least) to wrap your head around what the person before you was trying to accomplish. This is what put me off object groups. Though, I discovered that if I write them myself, I love them, lol. They can be hugely useful. They’re even available in IOS now (as of 12.4(20)T). Here’s an example of when they’d be used:
Scenario:
We need to allow several hosts (192.168.1.100-105) to access a group of servers (192.168.2.10-15) on multiple ports (21, 22, 25, 80, 443). Without object groups, this would produce a pretty lenghty ACL. First I’ll do the object group config, then I’ll show what it would look like with normal ACL entries.
object-group network OG_Hosts description host addresses network-object host 192.168.1.100 network-object host 192.168.1.101 network-object host 192.168.1.102 network-object host 192.168.1.103 network-object host 192.168.1.104 network-object host 192.168.1.105 ! object-group network OG_Servers description server addresses network-object host 192.168.2.10 network-object host 192.168.2.11 network-object host 192.168.2.12 network-object host 192.168.2.13 network-object host 192.168.2.14 network-object host 192.168.2.15 ! object-group service OG_Hosts-To-Server-Ports service-object icmp echo service-object icmp echo-reply service-object tcp eq 21 service-object tcp eq 22 service-object tcp eq 25 service-object tcp eq 80 service-object tcp eq 443 |
Pretty simple. We create some object groups matching IPs for the hosts and servers, then we match ICMP traffic and various TCP ports. Notice that there are two object group types used here, the first is “network”. This type allows us to specify IPs and subnets. The second type is “service”. This type allows us to match different ports and protocols.
Now let’s put it together in an ACL:
access-list ACL_Hosts-To-Servers extended permit object-group OG_Hosts-To-Server-Ports object-group OG_Hosts object-group OG_Servers |
Amazingly, we only need one line. We’ve configured an ACL line with three object groups. Notice that the ports actually come first, which threw me a bit when I first saw object groups in actions. Other than that, everything is relatively normal. We need to specify “object-group” before each one, and as usual, it’s source, then destination.
Now let’s look at part of the “show access-list” output. This will show us what the firewall sees and matches, and also what we were saved from typing manually:
Firewall# sh access-list ACL_Hosts-To-Servers access-list ACL_Hosts-To-Servers; 252 elements access-list ACL_Hosts-To-Servers line 1 extended permit object-group OG_Hosts-To-Server-Ports object-group OG_Hosts object-group OG_Servers 0xc08e86b0 access-list ACL_Hosts-To-Servers line 1 extended permit icmp host 192.168.1.100 host 192.168.2.10 echo (hitcnt=0) 0xb9c5e5bf access-list ACL_Hosts-To-Servers line 1 extended permit icmp host 192.168.1.101 host 192.168.2.10 echo (hitcnt=0) 0x946345e5 access-list ACL_Hosts-To-Servers line 1 extended permit icmp host 192.168.1.102 host 192.168.2.10 echo (hitcnt=0) 0xc233a45f access-list ACL_Hosts-To-Servers line 1 extended permit icmp host 192.168.1.103 host 192.168.2.10 echo (hitcnt=0) 0x509dadab access-list ACL_Hosts-To-Servers line 1 extended permit icmp host 192.168.1.104 host 192.168.2.10 echo (hitcnt=0) 0xfa1dbbd2 access-list ACL_Hosts-To-Servers line 1 extended permit icmp host 192.168.1.105 host 192.168.2.10 echo (hitcnt=0) 0xedc7eaea access-list ACL_Hosts-To-Servers line 1 extended permit icmp host 192.168.1.100 host 192.168.2.10 echo-reply (hitcnt=0) 0x77938723 access-list ACL_Hosts-To-Servers line 1 extended permit icmp host 192.168.1.101 host 192.168.2.10 echo-reply (hitcnt=0) 0x809068d5 access-list ACL_Hosts-To-Servers line 1 extended permit icmp host 192.168.1.102 host 192.168.2.10 echo-reply (hitcnt=0) 0x1730c200 access-list ACL_Hosts-To-Servers line 1 extended permit icmp host 192.168.1.103 host 192.168.2.10 echo-reply (hitcnt=0) 0xc555b262 access-list ACL_Hosts-To-Servers line 1 extended permit icmp host 192.168.1.104 host 192.168.2.10 echo-reply (hitcnt=0) 0xdd2ca47f access-list ACL_Hosts-To-Servers line 1 extended permit icmp host 192.168.1.105 host 192.168.2.10 echo-reply (hitcnt=0) 0xb5d1bc04 |
I’m not pasting all 252 lines, that would just be a waste of space. You get the idea though, the firewall is showing us what our single ACE actually does. All those rules come from our one line. That’s the power of object groups.
Just a short one today. Again, sorry for the lack of posts. Hopefully I can get back to posting regularly. I hope this all made sense. If you have any questions, please post in the comments.
Related Posts:
CCNA Scholarship
about 1 year ago - 2 comments
Steve is doing another generous offering over at Networking Forum. He’s planning to give away a “scholarship” for the CCNA. He will essentially pay someone’s way through the CCNA if this person agrees to log his or her progress on the forum. We, the staff and member base, are also offering our guidance and support throughout the process. Here’s a snippet from the forum:
What’s going on?
networking-forum.com is offering a scholarship to one person who would like to earn a Cisco Certified Network Associate (CCNA) certification. The scholarship will provide the CCNA Official Exam Certification Library, a separate forum specifically dedicated to the candidate for his or her use during their studies with feedback from the site’s members, and reimbursement of the exam fees after they pass their exam(s).
How is the recipient chosen?
To qualify for the scholarship, candidates will need to write an essay about why they want to earn their CCNA certification and why they make a good candidate for the scholarship. All essays must be received by October 8th, 2010 and posted in this thread. The essays will be judged by our crack(head) staff and a few prominent members. The recipient will be announced in this thread and notified via a site private message on October 15th, 2010.
I encourage everyone to check this out and apply for the scholarship or join in to help guide the chosen pursuer.
Click here for more details!
Related Posts:
Fiber Woes
about 1 year ago - 3 comments
I’m in the process of doing a very large hardware refresh for my company. We’re replacing 100+ old/EOL switches throughout the network/country. This shouldn’t be too big of a deal, but the latest generation of Cisco switches use SFPs. The older stuff is all GBIC. For most of our large sites, this isn’t major as we just run an ST to LC cable from the patch panel to the switch…
But of course, there are random sites without patch panels. The fiber runs directly from switch to switch. This presents a problem as we don’t have detailed information for most of our sites. So the options are re-terminating the ends of the fiber, buying a long enough patch cable (difficult to do) or having someone come out and pull new runs. That was until I came across these:
Tripp Lite N458-001-50 Duplex Multimode 50/125 Fiber Adapter, LC-M/SC-F – 1ft
These SC to LC adapters are a godsend. I wasn’t aware of their existence until last week. Not sure if they’re widely used and I’ve been living under a rock or what. We’re ordering a ton of these and will be shipping them out with the replacement switches, just in case.
Not a very meaty or informative post, but I’m thinking others may not know about these little adapters either. Hopefully some of you find this useful.
Related Posts:
%C4K_EBM-4-HOSTFLAPPING
about 1 year ago - 11 comments
This means loop!
A coworker came to me with an issue today. He asked if I’d ever seen this before and showed me:
.Aug 25 22:44:29 UTC: %C4K_EBM-4-HOSTFLAPPING: Host 00:00:85:DE:15:61 in vlan 54 is flapping between port Gi2/4 and port Gi2/2 .Aug 25 22:44:59 UTC: %C4K_EBM-4-HOSTFLAPPING: Host 00:00:85:DE:15:61 in vlan 54 is flapping between port Gi2/4 and port Gi2/2 .Aug 25 22:47:42 UTC: %C4K_EBM-4-HOSTFLAPPING: Host 00:00:85:DE:15:61 in vlan 54 is flapping between port Gi2/4 and port Gi2/2 |
I said “it means there’s a loop, give me the switch IP”. Then I began the mission of tracking down the loop. This was a pretty large site, but luckily I only had to go through a couple switches. Unfortunately this happened a couple hours ago and I didn’t save my work so we won’t be able to go through the real steps.
To track down a loop, you start with the “show mac-address-table address [flapping mac]” command:
SW1#sh mac-add add 0000.85de.1561
Unicast Entries
vlan mac address type protocols port
-------+---------------+--------+---------------------+--------------------
1 0000.85de.1561 dynamic ip GigabitEthernet2/2
54 0000.85de.1561 dynamic ip GigabitEthernet2/4 |
We see that the MAC is coming in on port gi2/2 and gi2/4. One port will lead us to where that MAC is plugged in and the other will lead us to the loop. Pick a port and start working through. This is where CDP comes in handy:
BLV0001S#sh cdp nei gi1/2
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID Local Intrfce Holdtme Capability Platform Port ID
SW2 Gig 2/2 160 S I WS-C3560-4Gig 0/1 |
Next we move to that switch and so on and so forth. Eventually we will come to the switch with the loop. In this case one of our switches had a little workgroup switch plugged into two ports, in two separate VLANs, which is why it wasn’t caught by STP.
This was a short one, just quickly posting up a scenario I ran into today. Let me know if it needs more information or I left anything out.
Update: I’m including the error %SW_MATM-4-MACFLAP_NOTIF in this post, which is essentially the same issue.
about 1 year ago
Both protocols are used to create Trunks an carry VLANS
ISL – Cisco Proprietary, uses 30 byte encapsulation and does not use native VLANs.
Dot1q – IEEE standard, insert 4byte tag and uses native VLANs
about 1 year ago
ISL = Cisco standard of marking vlans with lots of unused crap in the header. Marks every vlan. Being phased out by Cisco in favor of .1q. Tags on a vlan header at the beging and a new check-sum on the end
.1q = standard puts on a vlan header and re-calculates the check-sum at the end. Doesn’t do anything to the “native vlan” thus every untagged packet is in the native vlan (gotta watch this or you could have vlan packet leakage)
about 1 year ago
VLAN tagging protocols. ISL encapsulates the entire frame whereas dot1q does not…it just inserts a field in the frame. ISL is proprietary and dot1q is a standard. ISL just supports 1000 (I think) VLANs whereas dot1q supports up to 4096.
about 1 year ago
The are technologies used for trunking VLAN. ISL encapsulates the Ethernet frame with a 20byte header and CRC check compared to 802.1q which adds a 4 byte shim to the Ethernet header with VLAN Tag information.
about 1 year ago
Whoa! A celebrity has posted on my blog. This is good stuff.