Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
- Cisco Community
- :
- About gene.uhl
08-18-2017
Stats
Member since
05-15-2009
68
Posts
5
Helpful
1
Solution
12-08-2014
09:01 AM
Gordon, Thank you. You are correct. It was not when I entered the call a month ago with cisco, but now it does. Strange. I couldnt get it to work. Now I need to find out why it is working now.. Go figure. I guess I should have tried it again before I posted...sorry. Thanks again Gene
... View more
Created by
gene.uhl
in IP Telephony and Phones
in IP Telephony and Phones
12-08-2014
07:59 AM
12-08-2014
07:59 AM
Currently have Call Manager 8.6.2.21900-5. I usually get a report using a SQL query that allows me to see calls to and from and extension along with when the call was placed. Unfortunately it only gives me the calls going out and coming into the switch (external calls) I also want to see the log of internal 4 digit calls and date/time. I have looked at the graphical logging but it does not give you time/date unless you open each one and that would take forever. The SQL output is all right there. Here is the SQL query I use for example ext. 4516: admin:run sql car select callingpartynumber, originalcalledpartynumber, finalcalledpartynumber, datetimestamporigination from car:tbl_billing_data where callingpartynumber = '4516' OR originalCalledPartyNumber = '4516' Any help would be great on how to have a sql like this that gives me calls to and from extension, both internal and external, along with time and date as Cisco support isn't helping Much appreciated, Gene
... View more
Labels:
06-26-2014
06:05 AM
Carl Did you ever resolve this as we are experiencing the exact same issue and the 187's are our only SIP device. We have been battling with TAC for a month now and getting no where. Any response would be greatly appreciated.... Thanks Gene
... View more
08-21-2013
08:46 AM
Thank you. Completely understand. I set up my old network like that at each route point I defined a vlan 255 that trunked to all the access/edge switches on the far side of that distribution layer, essentially setting up a flat management network to all those edge switches. Then on another corresponding L3 route point, I created VLAN255 again but with a diffent subnet trunked to all those access switches which had Mgmt IP addresses in that defined subnet. So VLAN 255 was my management subnet for the entire network, but different subnets so it was not entirely flat, just at the L3 route points. Problem is doing that now would be a lot of work I can't get to, so if you are telling me that this is not best practice, but is really NOT causing any actually network issues, just looks klugey, I can deal with that :-)) Thanks Gene
... View more
08-21-2013
06:20 AM
Hello, I have a typical Access-Distribution-Core. Access is all L2 switches (3560,3750 running IP Basic) Distribution are L3 (3560E, 3750, 3750X running IP Services) then the Core is a Nexus. Each Access switch has multiple VLANs trunked to the Distribution Layer which handles all the routing between the VLANS, unless it needs to go farther up the chain, where it is routed through the core. Each Access Switch VLAN has an SVI with an IP address assigned to it AND each instance of the VLAN on the Distribution switch has an IP address assigned to it as this is the default gateway for the VLAN. (ie each vlan on the access switch would have an IP address like 10.10.X.253/24 and the IP address on the VLAN at the Distribution Switch where L3 is conducted would be 10.10.X.254/24 where teh X=subnet) With that said, I can SSH to the access or distribution switches on any number of IP addresses obvioulsy. This is the way it was set up when I got here and I just propegated the design as opposes to creating a single management VLAN or multiple routed vlans, but one on each switch as the dedicated Management VLAN) SO the million dollar question is this really bad practice? Can this cause bad things to happen? Would I be experiencing problems that I don't know about in my network? Someone told me when I mix vlans with VLAN based routing there can be unpredictablility so I should restrict the switch IP to one VLAN by using the NOMGT option (I have no idea what this means and is this statement true????) I have not noticed any issues with this design in years and my network is rather large. Any insight is welcome... Thank you Gene
... View more
Labels:
03-04-2013
08:26 AM
Guiseppe, Thank you!! I had a hunch that was it. Now one last question on the basics, which I think I may know. A packet not desinted for the local VLAN will have a source IP on the local VLAN, but a desination NOT on the local VLAN. So is the ACL IN blocking packets based on the non-local destination IP address, or is it blocking the ARP of the local machine attempting to get the IP address of the default gateway?? In your explanation, does that mean whenever you add an ACL IN to a VLAN you would need to add access to the default gateway to let packets off the VLAN? And if you do, does that not mean that packets will then be able to get inside your network? Thanks Gene
... View more
03-04-2013
07:18 AM
Hello, I posted the info as you requested which took some time to create. A favor or a reply would be appreciated. Thanks Gene
... View more
03-04-2013
07:18 AM
Thank you but this does not answer my original question. This statement is already in line 60 of my ACL and I don't see how moving it to line 5 has any bearing. Thank you Gene
... View more
03-01-2013
08:51 AM
I have pulled relavant configs from running. Let me know if you need more. I also encolsed a quick and dirty diagram to help. Line 60 is the one I had to add to get it working as this is the access to the default gateway line. Thanks. Gene Configs on Switch 3 In Diagram Vlan990 172.16.253.14 YES manual up up interface Vlan990 ip address 172.16.253.14 255.255.255.248 ip access-group TRAVELLER_WIFI_VLAN990 in Extended IP access list TRAVELLER_WIFI_VLAN990 10 permit icmp 172.16.253.8 0.0.0.7 host 172.16.254.250 log (27 matches) 20 permit icmp 172.16.253.8 0.0.0.7 host 172.16.254.249 log 30 permit ip host 172.16.253.9 host 172.16.254.250 log (386674 matches) 40 permit ip host 172.16.253.10 host 172.16.254.250 log (1555143 matches) 60 permit ip 172.16.253.8 0.0.0.7 host 172.16.253.14 log (91256 matches) 1000 deny ip any any (45 matches)
... View more
02-28-2013
01:44 PM
I'll try and simplifyI create an ACL inbound to a VLAN at an edge switch. The vlan is trunked to a distribution L3 switch that handles the routing of all the trunked VLANS. For example, the users can get to an ip subnet prior to access-group application. When I apply the ACL they can not. The ACL lets them get to that subnet by definition, but it does not allow them access to the default gateway. When I allow IP ANY to default gateway, they can get to that subnet again. So, with an ACL oIN n the VLAN, must I allow access to the default gateway even though their destination IP address is somewhere else in the network? If so WHY? Is it so the ACL will allow the service of the ARP for its default gateway?? Any insight would be great. Thanks Gene
... View more
Labels:
01-17-2013
12:12 PM
In the accompaynying picture some of the vlans/subnets changed from previous post, so I will restate. Laptop connects to WiFI which is on the private side of the VPN device. This traffic is tunneled via the VPN device on the 10.x network to go to the VPN Concentrator (10.1.3.1) which then dumps the traffic on the ISP network so they can get to the Internet. This is a simplified diagram. I set up an Extended ACL on port 24 of the L2 switch that looked like this: Extended IP access list WIFI_FILTER 10 permit icmp any host 10.1.3.1 20 permit ip host 10.1.1.1 host 10.1.3.1 30 permit ip host 10.1.3.1 host 10.1.1.1 40 deny ip any any (14 matches) on port 24 it has this: ip access-group WIFI_FILTER in I figured line 30 in the acl is useless but put it in anyway as the acl only works on traffic IN for the port. As I stated, this worked and the laptop got to the Interner for weeks, then it stopped. I took the ACL off, and it worked fine. When I turned the ACL on again, it works for about 20 seconds, then stops. I then added to the extended acl: 35 permit ip host 10.1.1.1 host 10.1.1.254 and it started working again with no issues. Don't understand why? Do you always need to add the gateway address to the ACL? Is it because I defined my acl on the port that is L2 and I should move the ACL to the L3 switch trunk port or add it to the L3 Vlan on the L3 switch? I am trying to make sure that the 192.168.1.x traffic that is encapsulated in the VPN device and tunneled to the VPN concentrator will ONLY go there and no where else on the internal network. So traffic coming from 10.1.1.1 will only be allowed to go to 10.1.3.1 and vice-versa. Thanks Gene
... View more
01-17-2013
07:11 AM
Have someting strange happening. Have a VLAN, we will call this subnet 1 VLAN1. Have a remote network that a device on subnet 1 needs to get to. The device on subnet 1 is a NAT'd VPN box. On one side is a private network, we will say 192.168.x.x. So the public side of the NATd VPN box has an IP address on VLAN1 Subnet 1. It tunnels the traffic to the remote network via EIGRP published routes. Lets call the remote network 10.1.1.0/24 So on the port that the NATd VPN box plugs into on VLAN1 Subnet 1 (the entire swith is configured at VLAN1 Subnet1) which has a trunk port to a Layer 3 switch that handles the routing) I add an extended IP ACL that Allows the static IP address assigned to the NATd VPN box to ping the far side VPN box on the 10.1.1.0/24 network and allow any packet it sends to go to there also (so host VLAN1 IP address host remote network IP address ANY) Inherint block on all other traffic. The issue is the VPN tunnel between the VLAN1 box and the 10.1.1.0 network VPN box comes up for about 20 seconds, then dies. I remove the ACL and it works fine. I put it back on, same 20 seconds, then dies. So, in the ACL I put a permit from host VLAN 1 IP address (the NATd VPN box) to host IP address of VLAN1 default gateway ANY and the tunnel comes up for good, no issues. The funny thing is, that the original setup was up and working for days, then decided to stop and nothing was changed. I had to add the default gateway of the VLAN1 IP to the ACL to get it working again and it has been up for a few days. Does not make sense to me so any insight? I don't know why as the arp for the remote IP address would return the layer 2 mac of the default gateway, whihc is layer 2 and the acl should not affect this traffic. Can't see it being a proxy arp issue either. Any insight?? So bottom line, does the default gateway need to be allowed in an ACL or the clients on the subnet can't route out??? Thanks Gene
... View more
Labels:
12-08-2014
Gordon, Thank you. You are correct. It was not when I entered the call a
month ago with cisco, but n...
Created by
gene.uhl
in IP Telephony and Phones
12-08-2014
12-08-2014
Currently have Call Manager 8.6.2.21900-5. I usually get a report using
a SQL query that allows me t...
06-26-2014
Carl Did you ever resolve this as we are experiencing the exact same
issue and the 187's are our onl...
03-04-2013
Guiseppe,Thank you!! I had a hunch that was it. Now one last question on
the basics, which I think I...
03-04-2013
Hello,I posted the info as you requested which took some time to create.
A favor or a reply would be...
03-04-2013
Thank you but this does not answer my original question. This statement
is already in line 60 of my ...
03-01-2013
I have pulled relavant configs from running. Let me know if you need
more. I also encolsed a quick a...
02-28-2013
I'll try and simplifyI create an ACL inbound to a VLAN at an edge
switch. The vlan is trunked to a d...
Public Statistics
| Date Registered | 05-15-2009 04:42 AM |
| Date Last Visited | 08-18-2017 03:54 AM |
| Total Messages Posted | 68 |
| Total Helpful Votes Received | 5 |
Helpful Votes Given To
.jpg "Hall of Fame Master"){kind=icon}
