CAn anyone tell me how to get the SERIAL MACS on a 1721?

[bigblock454]

Please, I have a huge phone system problem, and I have the ethernet MACs, I desparately need the SERIAL MACs!! HELP!!

 

[burtsbees]

Post a sh int

Just a sh int

Burt

 

[ADB100]

Yep, show int will list all the interfaces on the router and will include the MAC addresses. Use 'show int | inc address is' and this will get you just a list of MAC addresses.
As to how a list of router MAC addresses will help you fix a 'huge' phone system problem I have no idea......

Andy

 

[jneiberger]

Serial interfaces do not use MAC addresses. Why do you want to see what they are?

 

[bigblock454]

I need to know because the phone system regularly drops callers and the vendor who sold us the system seems to think something in my netowrk is wrong, despite low latency, virtually no congestion, and virtually no packet loss. They recommended managed Avaya switches, and there are numerous MAC addresses shown that I cannot identify, generally on the same ports as the ethernet MACs (multiple MACs on the same port). I am working on assigning priority to those specific ports, and getting an accurate mapping of the overall system.

In case anyone here has any idea on this, I might add that I have 4 locations, connected by 3 PTP T1s, 2 of which are B8ZS/ESF and one of which is AMI/SF. The vast majority of dropped calls are transfers from an AMI connected location to a B8ZS location, and that they drop in little clusters of the SAME caller, i.e if Jack and Jill call in at the same time, and Jack gets dropped, Jill stays connected. Jack calls back and is dropped again, but Jill is still connected. Joe calls in while Jill is connected, and Jack calls back. Jack gets dropped while Joe & Jill stay connected. No one can explain it, and no one can fix it. And yes, I spend ALOT of time on the Avaya IPO threads.

Not to get too into that on a Cisco thread, I am at my wits end with this, it's been going on for nearly a year, my vendor is virtually no help, and if it were up to me I would go back to all POTS and never, ever, use IPO again. Unfortunately, it isn't up to me...Here is a sho int

highway#sho int
FastEthernet0 is up, line protocol is up
Hardware is PQUICC_FEC, address is 000d.bdb0.0938 (bia 000d.bdb0.0938)
Internet address is 10.10.1.1/8
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 2d19h
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 777000 bits/sec, 184 packets/sec
5 minute output rate 52000 bits/sec, 99 packets/sec
17682566 packets input, 253125987 bytes
Received 130111 broadcasts, 0 runts, 0 giants, 0 throttles
2 input errors, 0 CRC, 0 frame, 2 overrun, 0 ignored
0 watchdog
0 input packets with dribble condition detected
10462455 packets output, 1100611416 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Serial0 is up, line protocol is up
Hardware is PQUICC with Fractional T1 CSU/DSU
Internet address is 192.168.254.2/30
MTU 1500 bytes, BW 1344 Kbit, DLY 20000 usec,
reliability 255/255, txload 142/255, rxload 7/255
Encapsulation HDLC, loopback not set
Keepalive set (10 sec)
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 2d19h
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 120
Queueing strategy: Class-based queueing
Output queue: 8/1000/64/120 (size/max total/threshold/drops)
Conversations 1/9/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
Available Bandwidth 336 kilobits/sec
5 minute input rate 42000 bits/sec, 97 packets/sec
5 minute output rate 753000 bits/sec, 182 packets/sec
10472670 packets input, 1000193766 bytes, 0 no buffer
Received 498728 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
17699844 packets output, 77930984 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
DCD=up DSR=up DTR=up RTS=up CTS=up

highway#

 

[jneiberger]

Are these IP calls over AMI or TDM calls? Unless you're running inverted HDLC, I wouldn't try running data over AMI.

Forget about the serial interface thing. As I said before, serial interfaces don't have MAC addresses. If you want to know what those strange MAC addresses are, remember that the first six bytes are the vendor OUI and you can look it up here:

http://standards.ieee.org/regauth/oui/index.shtml

That might help you figure out what those MAC addresses are.

 

[jneiberger]

Also, if you already have perfectly good Cisco switches and your vendor, who doesn't even know what's wrong, wants to sell you Avaya switches just the heck of it, get a different vendor.

1. Can you give us a better idea of the design of your network?

2. Are these full T1s or fractional?

3. What switches are you using?

4. Have you upgraded to the most recent stable code on all devices, including the Avaya gear?

5. Are you seeing late collisions on any Ethernet interfaces related to your IP Office equipment?

 

[burtsbees]

I'd like to see the QoS...

Burt

 

[jneiberger]

Yes, it would also be nice to see the QoS config. You should definitely have it on those T1s.

 

[bigblock454]

Hi Burtsbees, I think you gave me the QoS, but here it is

class-map match-all VoIP
match IP dscp 46 (a couple of them use ef here, depending on IOS)
match IP dscp 34 (a couple of them use af41 here, depending on IOS)
Policy-Map voipQos
class VoIP
priority percent 50
class class-default
fair-queue
random-detect dscp-based

 

[bigblock454]

jnieberger, we had unmanaged switches, various mfgrs, and we still have them in place. The Avaya switches we have are 4 P133GT2s that we bought on ebay (I know, but I work with what I'm allowed). They are older, discontinued, but they were "new", had never been unboxed. If I could switch vendors, I would have done so already, LOL! To a man, everyone I talk to on these threads thinks we should get rid of them, but my boss thinks that will just be more cost, and we're in a budget crunch.

The network is a little strange, we have 192.168.0.0, 192.168.2.0, 192.168.3.0, and 10.10.1.0, one for each location. 1721s connect offices over the PTPs. Maybe this will help:

As of 3/6/2008
Circuits
Location Circuit ID Line Type Framing
To 21mm 42-DHXS-001050 B8ZS ESF
To Hwy 41-HGCS-404379 AMI SF <Ordered switched from AMI/SF to B8ZS/ESF on 030508
To 1mm 41-HCGS-404984 B8ZS ESF <Switched from AMI/SF on 030508
PRI 42-DCJD-5739643400T0001 B8ZS ESF
Routers
Name IP Model IOS ROM Release FA MAC Serial MAC
to1mm 192.168.0.175 1721 12.2(8)T5 12.2(7r)XM1 fc1/fc1 000cce6d0fd7
to21mm 192.168.0.199 1721 12.4(5a) 12.2(7r)XM2 fc3/fc1 0012dac3a96b
lake (to Hwy) 192.168.0.200 1720 12.4(5a) 12.2(7r)XM1 fc3/fc1 000821db0de6
to3mm (21) 192.168.3.199 1721 12.4(5a) 12.2(7r)XM1 fc3/fc1 0009430946d0
1mmto3mm 192.168.2.1 1721 12.2(4)YA2 12.2(7r)XM1 fc1/fc1 000bfdcf12a9
highway 10.10.1.1 1721 12.4(5a) 12.2(7r)XM1 fc3/fc1 000dbdb00938
CLEARED ALL COUNTERS 2:20-2:25pm 03/05/08
Switches
Name IP Image Ver
3mm 192.168.0.198 2.11.3
1mm 192.168.2.198 2.11.3
21mm 192.168.3.198 2.11.3
Hwy 10.10.1.198 2.11.3
I do have the latest software on the Avaya Phone equipment, but probably not the switches.

As far as collisions, I am not sure, can you define a "late collision" please?

The T1s are all full, depsite the routers showing fractional. As I mentioned, only one is AMI, and I am working towards getting that one switched to B8ZS, but the circuit is out of contract so new contracts have to be done

Meanwhile, thanks for the link, I will look up the "unknown" MACs.

It has been a nightmare overall. I have narrowed down what switch ports are connected to Cisco and Avaya equipment and given those ports the highest priority and value, as of today.

Thanks to you guys, I'm sorry if I sound frustrated. As I imagine you have experienced in your careers, I was thrown into this phone thing with no experience and no training. The vendor configured it wrong from the get fo and never bothered with the mandatory network assessment required by Avaya. Yours truly, with the invaluable assistance of the people on this forum, has had to take the ball and run with it.

 

[brianinms]

Unmanaged switches have no place in a VOIP network.

 

[jneiberger]

I agree with Brian on that point. You really shouldn't be running VoIP over unmanaged devices. You can get some Dell or HP switches fairly inexpensively. If you're on a tight budget, look at them instead of Cisco. You really need to get rid of those unmanaged switches.

 

[bigblock454]

currently the unmanaged switches are only connected to PCs and managed switches. Are your recommendations to eliminate ALL unmanaged switches?

 

[jneiberger]

The unmanaged switches are fine if you're not connecting VoIP devices to them.

 

[bigblock454]

Thanks. Originally the VoIP was on unmanaged, we switched to managed after all kinds of problems manifested, but the drop issue has never been resolved.

 

[burtsbees]

sh mac-address-table from the switches will give you the macs that are connected...
As far as collisions, I am not sure, can you define a "late collision" please?

"To allow collision detection to work properly, the period in which collisions are detected is restricted (512 bit-times). For Ethernet, this is 51.2us (microseconds), and for Fast Ethernet, 5.12us. For Ethernet stations, collisions can be detected up to 51.2 microseconds after transmission begins, or in other words up to the 512th bit of the frame.

When a collision is detected by a station after it has sent the 512th bit of its frame, it is counted as a late collision. "

sh int on the switch to which the trouble phones are will show this. You have none on fa0 on "highway".

Burt

 

[jneiberger]

Late collisions are a sure sign of a duplex mismatch, which will make an interface behave very, very poorly. Check to make sure your Avaya IPO stuff isn't suffering from some sort of connection issue. I doubt that's the issue, but you should check it.

 

[BuckWeet]

Question about your IP Office system.. Are you using digital handsets or IP? Are the drops always from IP to IP, digital to digital or a mix?

Honestly this sounds like a firmware issue on the Avaya side, I've had issues such as this with Definity's. You say this has been going on for year now, has your vendor upgraded the software on the IP handsets and the system software?


BuckWeet

 

[bigblock454]

Hi BuckWeet, The system relies on digital handsets (mostly 5410s, 4 5420s); the majority of the drops are transfers from the HWY location to the 21MM location, neither of which are the main location, but one of which is an AMI/SF coded circuit. We are up to date on the software as far as I know, but then again I was given no training at all, so I need to check in on Avaya's site (hat tip to all Avaya IPO folks for linking that).