comp.dcom.sys.cisco - Info on Cisco routers and bridges.
I'm making ethernet cables which don't quite work and it's drivign me crazy. I can't quite explain under what conditions they work and don't work. It seems that they do work with almost all (or juts all) 10 mbit boards but don't work with the newer 100mbit boards. I've used two different sources of cat 5e cable, in one case it's not clerly labeled for speed, in the other it says that it was tested for Gigabit networks. Results are the same. So it must be the heads I'm using? Is this even possible? Or could it be the crimper? Because I've tried heads from two different sources -- doesn't seem to make a difference. When I plug such cable between a 100mbit Linksys router and a 100mbit PCMCIA card the light on the switch goes on for couple of seconds, blinking very-very fast and then disappears. If I replace the PCMCIA card with an old one 10mbit card it works fine. Please help, I'm getting scared.
Dear All, I have a new fancy problem :) I want to do a vpn client connection from VpnClient-A to Router B. Router-A is a VPN gateway too. VPNClA--[RouterA eth1=126.96.36.199/NAT]--[eth1=188.8.131.52/NAT RouterB]-192.168.2.0/24 192.168.1.0/24 I can Connect from client-A to router B and build up the tunnel. But all the esp (or UDP 4500 when using NAT-T) packets are caught by router-A when eth1 has a crypto map assigned. When I remove the crypto map from router-A the connection from client-A to router-B works fine. How can I tell router A which UDP-4500/ESP packet to take and encrypt and which packet not? Why are the IKE packets nor caught by router-a? Thanks you. Christian ! version 12.2 no service slave-log no service pad service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname ABC ! ! username usernamex password usernamex aaa new-model ! ! aaa authentication login ALIST local aaa authorization network ALIST local aaa session-id common no ip subnet-zero ! ! crypto isakmp policy 10 encr 3des authentication pre-share group 2 crypto isakmp keepalive 30 ! crypto isakmp client configuration group WASSER key geheim dns 192.168.1.1 domain wasserturm.pk2 pool vpnpool acl 160 ! ! crypto ipsec transform-set SICHER esp-3des esp-sha-hmac ! crypto dynamic-map vpnclient 10 set transform-set SICHER ! ! crypto map vpn client authentication list ALIST crypto map vpn isakmp authorization list ALIST crypto map vpn client configuration address respond crypto map vpn 10 ipsec-isakmp dynamic vpnclient ! ! ! ! interface Ethernet0 ip address 192.168.2.252 255.255.255.0 ip accounting output-packets ip nat inside no cdp enable hold-queue 100 out ! interface Ethernet1 no ip address pppoe enable pppoe-client dial-pool-number 1 no cdp enable ! interface Dialer1 ip address negotiated ip mtu 1492 ip nat outside ip inspect FIREWALL out encapsulation ppp ip tcp adjust-mss 1452 dialer pool 1 dialer-group 1 ppp authentication chap pap callin ppp pap sent-username XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 1A175C4E57464A ppp ipcp dns request crypto map vpn ! ip local pool vpnpool 192.168.4.1 192.168.4.5 ip nat inside source list 130 interface Dialer1 overload ip classless ip route 0.0.0.0 0.0.0.0 Dialer1 no ip http server ! ! access-list 5 permit any access-list 10 permit 192.168.2.0 0.0.0.255 access-list 130 deny ip 192.168.2.0 0.0.0.255 192.168.4.0 0.0.0.255 access-list 130 permit ip 192.168.2.0 0.0.0.255 any access-list 160 permit ip 192.168.2.0 0.0.0.255 192.168.4.0 0.0.0.255 dialer-list 1 protocol ip permit ! line con 0 exec-timeout 120 0 no modem enable stopbits 1 line aux 0 stopbits 1 line vty 0 access-class 5 in exec-timeout 120 0 length 0 international transport preferred ssh line vty 1 4 ! scheduler max-task-time 5000 end
Say that i have 3 routers all connected via direct serial links, running RIP (version 1). Each of the serial interfaces can be pinged remotely and locally. None of the ethernet interfaces can be pinged remotely, but can be locally. Does this mean that rip is not advertising the networks properly? I will probably have some questions about ospf and eigrp soon. Thanks in advance Martin.