Re: OSPF Demand Circuit - About to go crazy! :-)
Well, that nailed up the ISDN connection for good, but OSPF adjacencies still did not form I had to change my dialer map statements to dialer string statements... dialer string on R1 dialer string on R3 ...and it magically worked.now, why? Why did it have a problem with the dialer map ip statements? I will try to figure that out, but at least I know now what I need to do in this scenario. ""Aaron K. Dixon"" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Try using the broadcast command in your dialer map commands. > > ie. > > dialer map ip 10.36.19.6 broadcast > > Regards, > Aaron K. Dixon > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > Ryan Moffett > Sent: Saturday, July 29, 2000 8:51 PM > To: [EMAIL PROTECTED] > Subject: Re: OSPF Demand Circuit - About to go crazy! :-) > > > I apologize, the ip ospf network statements in my routers are correct: > > network 10.36.18.6 0.0.0.0 area 0 > network 10.36.19.6 0.0.0.0 area 0 > ! > > I attempted to write down the config from memory and my previous post was > erraneous. > > In any case, sh ip ospf int on both routers shows that OSPF is running on > both the Frame Relay and ISDN interfaces and on R1 the ISDN interface shows > that it is running as a demand circuit. The problem is that it will never > establish an adjacency over the frame-relay link, nor attempt to. If I > shut the Frame Relay interface down, the ISDN interface doesn't come up, and > even if I attempt to "nail-up" the ISDN connection so that it is always up, > adjacencies will not form. I debug ip ospf adjacency, and nothing happens. > Both routers can ping each other over the ISDN link, I can make RIP, IGRP, > EIGRP and BGP talk over the ISDN connection, however OSPF still fails... > > Ryan > > ""Aaron K. Dixon"" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > It looks like you mistyped the ospf statements in router 2. Under the > ospf > > process you specify addresses that have the 2nd octet of .39 when the > > interfaces have a second octet of .36. A good way to verify that your > > interfaces coincide with your ospf configuration is to do a 'sh ip ospf > > int'. This will allow you to verify that the interfaces are configured > for > > opsf and then you can go into troubleshooting neighbor relationships. > > > > Regards, > > Aaron K. Dixon > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > > Ryan Moffett > > Sent: Saturday, July 29, 2000 8:06 PM > > To: [EMAIL PROTECTED] > > Subject: OSPF Demand Circuit - About to go crazy! :-) > > > > > > I am beating myself to death with the following: > > > > I am working through the following scenario in which R1 has a Frame Relay > > connection to R2 via Frame-Relay and ISDN. R1 is configured with ip ospf > > demand-circuit on the ISDN interface as well as OSPF on the Frame Relay > > interface. R1 forms an ajacency with R2 over the Frame Relay link, and > > they sucessfully exchange databases. R2 is configured the same as R1 > with > > the exception of the ip ospf demand-circuit, it does not have that > > configured.R1 does not show 2 entries in the show ip ospf neighbor > > output. R1 and R2 are not forming adjacencies over the OSPF > > demand-circuit.I can ping between R1 and R2's BRI interfaces to bring > up > > the ISDN link, and it works properly, however, if I shut the Frame Relay > > interface down, shouldn't the ISDN link come up as both links are in area > 0? > > > > R1 has the following relavent configuration: > > > > ! > > int s0.102 point-to-point > > encapsulation frame-relay > > ip address 10.36.18.5 255.255.255.252 > > frame-relay interface-dlci 102 > > ! > > int bri0 > > encapsulation ppp > > dialer map ip 10.36.19.5 > > ip ospf demand-circuit > > dialer-group 1 > > ! > > router ospf 100 > > network 10.36.18.5 0.0.0.0 area 0 > > network 10.36.19.5 0.0.0.0 area 0 > > ! > > dialer-list 1 protocol ip permit > > > > > > R2 has the following relavent configuration > > > > ! > > int S0.201 point-to-point > > encapsulation frame-relay > > ip address 10.36.18.6 255.255.255.252 > > frame-relay interface-dlci 201 > > ! > > int bri0 > > encapsulation ppp > > dialer map ip 10.36.19.6 > >
Re: OSPF Demand Circuit - About to go crazy! :-)
I apologize, the ip ospf network statements in my routers are correct: network 10.36.18.6 0.0.0.0 area 0 network 10.36.19.6 0.0.0.0 area 0 ! I attempted to write down the config from memory and my previous post was erraneous. In any case, sh ip ospf int on both routers shows that OSPF is running on both the Frame Relay and ISDN interfaces and on R1 the ISDN interface shows that it is running as a demand circuit. The problem is that it will never establish an adjacency over the frame-relay link, nor attempt to. If I shut the Frame Relay interface down, the ISDN interface doesn't come up, and even if I attempt to "nail-up" the ISDN connection so that it is always up, adjacencies will not form. I debug ip ospf adjacency, and nothing happens. Both routers can ping each other over the ISDN link, I can make RIP, IGRP, EIGRP and BGP talk over the ISDN connection, however OSPF still fails... Ryan ""Aaron K. Dixon"" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > It looks like you mistyped the ospf statements in router 2. Under the ospf > process you specify addresses that have the 2nd octet of .39 when the > interfaces have a second octet of .36. A good way to verify that your > interfaces coincide with your ospf configuration is to do a 'sh ip ospf > int'. This will allow you to verify that the interfaces are configured for > opsf and then you can go into troubleshooting neighbor relationships. > > Regards, > Aaron K. Dixon > > -----Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > Ryan Moffett > Sent: Saturday, July 29, 2000 8:06 PM > To: [EMAIL PROTECTED] > Subject: OSPF Demand Circuit - About to go crazy! :-) > > > I am beating myself to death with the following: > > I am working through the following scenario in which R1 has a Frame Relay > connection to R2 via Frame-Relay and ISDN. R1 is configured with ip ospf > demand-circuit on the ISDN interface as well as OSPF on the Frame Relay > interface. R1 forms an ajacency with R2 over the Frame Relay link, and > they sucessfully exchange databases. R2 is configured the same as R1 with > the exception of the ip ospf demand-circuit, it does not have that > configured.R1 does not show 2 entries in the show ip ospf neighbor > output. R1 and R2 are not forming adjacencies over the OSPF > demand-circuit.I can ping between R1 and R2's BRI interfaces to bring up > the ISDN link, and it works properly, however, if I shut the Frame Relay > interface down, shouldn't the ISDN link come up as both links are in area 0? > > R1 has the following relavent configuration: > > ! > int s0.102 point-to-point > encapsulation frame-relay > ip address 10.36.18.5 255.255.255.252 > frame-relay interface-dlci 102 > ! > int bri0 > encapsulation ppp > dialer map ip 10.36.19.5 > ip ospf demand-circuit > dialer-group 1 > ! > router ospf 100 > network 10.36.18.5 0.0.0.0 area 0 > network 10.36.19.5 0.0.0.0 area 0 > ! > dialer-list 1 protocol ip permit > > > R2 has the following relavent configuration > > ! > int S0.201 point-to-point > encapsulation frame-relay > ip address 10.36.18.6 255.255.255.252 > frame-relay interface-dlci 201 > ! > int bri0 > encapsulation ppp > dialer map ip 10.36.19.6 > ip ospf demand-circuit > dialer-group 1 > ! > router ospf 100 > network 10.39.18.6 0.0.0.0 area 0 > network 10.39.19.6 0.0.0.0 area 0 > ! > dialer-list 1 protocol ip permit > > Thanks, > Ryan Moffett > > > ___ > UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html > FAQ, list archives, and subscription info: http://www.groupstudy.com > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > > ___ > UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html > FAQ, list archives, and subscription info: http://www.groupstudy.com > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > --- ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
OSPF Demand Circuit - About to go crazy! :-)
I am beating myself to death with the following: I am working through the following scenario in which R1 has a Frame Relay connection to R2 via Frame-Relay and ISDN. R1 is configured with ip ospf demand-circuit on the ISDN interface as well as OSPF on the Frame Relay interface. R1 forms an ajacency with R2 over the Frame Relay link, and they sucessfully exchange databases. R2 is configured the same as R1 with the exception of the ip ospf demand-circuit, it does not have that configured.R1 does not show 2 entries in the show ip ospf neighbor output. R1 and R2 are not forming adjacencies over the OSPF demand-circuit.I can ping between R1 and R2's BRI interfaces to bring up the ISDN link, and it works properly, however, if I shut the Frame Relay interface down, shouldn't the ISDN link come up as both links are in area 0? R1 has the following relavent configuration: ! int s0.102 point-to-point encapsulation frame-relay ip address 10.36.18.5 255.255.255.252 frame-relay interface-dlci 102 ! int bri0 encapsulation ppp dialer map ip 10.36.19.5 ip ospf demand-circuit dialer-group 1 ! router ospf 100 network 10.36.18.5 0.0.0.0 area 0 network 10.36.19.5 0.0.0.0 area 0 ! dialer-list 1 protocol ip permit R2 has the following relavent configuration ! int S0.201 point-to-point encapsulation frame-relay ip address 10.36.18.6 255.255.255.252 frame-relay interface-dlci 201 ! int bri0 encapsulation ppp dialer map ip 10.36.19.6 ip ospf demand-circuit dialer-group 1 ! router ospf 100 network 10.39.18.6 0.0.0.0 area 0 network 10.39.19.6 0.0.0.0 area 0 ! dialer-list 1 protocol ip permit Thanks, Ryan Moffett ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: OSPF adjacency question
In your example, router C cannot form an adjacency to router A. It must form an adjacency with router B. The adjacency process will not even occur as router C and router A will never become neighbors. They cannot become neighbors because they do not share the same IP segment. Since the HELLO packets are sent as multicast, router B will most likely not forward the multicast to router C. If router C were to somehow receive this HELLO packet the network portion of the source address would not match that of router C and the neighbor relationship will fail. Ryan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Daniel Ma Sent: Thursday, June 08, 2000 9:30 PM To: [EMAIL PROTECTED] Subject: OSPF adjacency question We all know that in an area (multi-access media), all routers must form adjacency with DR and BDR. But how it is done if the router is not directly linked to DR? For example, Router A is the DR. Router B is between the Router A and Router C. Now Router C must form adjacency with Router A. Am I right to say that Router C multicast to 224.0.0.6, then Router B will forward this packet to Router A? So actually it's a virtual adjacency between Router A and Router C, they are not neighbor. I really hope you would clear the concept for me, as I could not find the answer in books, even in "Routing TCP/IP". Thanks, Daniel ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Stopping Ping
I would imagine logging out of the router would do the sameping is run in exec mode... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Albert Ip Sent: Thursday, June 08, 2000 10:27 PM To: 'Lawrence Dwyer'; 'Groupstudy' Subject: RE: Stopping Ping You got the answer there. "Ctr Shft 6" same time, than "x" Albert -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Lawrence Dwyer Sent: Thursday, June 08, 2000 6:27 PM To: Groupstudy Subject: Stopping Ping Is there any way to stop a long ping on a router? I set a hundred packets or more some times to get to other routers and see what I am getting, but if I wish to terminate a routers pining before the number I set is finished, is there a way? Ctr Shft 6 x, break, pause, etc etc I havne't found the magic keys yet. Larry -- Lawrence Dwyer, MCSE CCNA Sherikon, Inc 301-619-7946 ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: L3 keepalives without routing protocol?
Well, BGP can be used as a measurement of L3 connectivity. I have seen BGP used on several occasions to bring up ISDN dial backup in the event that a Frame-Relay interface went into an Up/Down status and thus would not trigger the backup interface to be used. When the BGP neighbor session on the preferred path (local-preference) failed, the lower preference kicked in. The only other possibility that I haven't tried might be to use NTPI don't know if you can get a trap if an NTP client fails to sync with the master. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Andy HardingSent: Thursday, June 08, 2000 6:47 PMTo: [EMAIL PROTECTED]Subject: L3 keepalives without routing protocol? Hi all, strange problem for y'all... I have a problem whereby a down circuit does not necessarily "down" an interface (via ATM switch - am using OAM but not foolproof). Is there some way that I can enable a L3 keepalive without running a global IGP (bear in mind that this is between my core routers and several thousand 25XX/26XX clients, and I don't want to give them a routing table, just a default route). We run a NOCOL-type daemon that alerts me if a machine has been unpingable for >15 minutes, but am looking for a sure-fire way to have a core router send the NMS a trap when a circuit becomes unreachable at L3. any help much appreciated as always Andy
RE: gre configs
Try the following: Apply the crypto-maps to the tunnel interfaces in addition to the serial interfaces, and disable fast-switching on the tunnel interface...in this case: no ipx route-cache Ryan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of vr4drvr . Sent: Wednesday, June 07, 2000 7:41 PM To: [EMAIL PROTECTED] Subject: gre configs here is the config that doesn't work. all is fine with an ACL of access-list 132 per icmp any any, the ipx eigrp router see each other, but as soon as i change the access list to the one below the eigrp adjacency is lost and so is all ipx connectivity. what the... r3# r3#wr t Building configuration... Current configuration: ! version 12.0 service timestamps debug datetime service timestamps log datetime no service password-encryption ! hostname r3 ! no logging console ! username all ip subnet-zero no ip domain-lookup ip domain-name CISCO.COM appletalk routing eigrp 3 ipx routing 0003.0003.0003 vines routing 300A94D4:0001 ! ! crypto isakmp policy 100 hash md5 authentication pre-share crypto isakmp key cisco address 135.7.1.5 ! ! crypto ipsec transform-set TRANSFORM esp-des mode transport ! ! crypto map CRYPTO2 100 ipsec-isakmp set peer 135.7.1.5 set transform-set TRANSFORM match address 132 clock timezone CST -6 clock summer-time CDT recurring ! ! ! interface Tunnel100 no ip address no ip directed-broadcast ipx network 1000 tunnel source Serial0 tunnel destination 135.7.1.5 ! interface Ethernet0 ip address 135.7.2.3 255.255.255.0 no ip directed-broadcast ip ospf interface-retry 0 ip ospf priority 200 appletalk cable-range 300-300 300.3 appletalk zone r3r4r7ether appletalk protocol eigrp no appletalk protocol rtmp ipx network 300 vines metric 2 vines serverless ! interface Serial0 ip address 135.7.1.3 255.255.255.0 no ip directed-broadcast encapsulation frame-relay no ip route-cache ip ospf network broadcast ip ospf interface-retry 0 no ip mroute-cache frame-relay map ip 135.7.1.1 305 broadcast frame-relay map ip 135.7.1.5 305 broadcast no frame-relay inverse-arp frame-relay lmi-type ansi crypto map CRYPTO2 ! interface Serial1 no ip address no ip directed-broadcast shutdown ! router ospf 1 network 135.7.1.0 0.0.0.255 area 0 network 135.7.2.0 0.0.0.255 area 1 ! ip classless ! access-list 131 permit ip any 135.7.0.0 0.0.255.255 log access-list 132 permit gre any any access-list 133 deny gre any any access-list 133 permit ip any any access-list 601 deny nbp 1 type Network access-list 601 deny other-nbps access-list 601 deny other-access ! ! ! ipx router eigrp 1 network all ! ! ! alias exec c conf t ! line con 0 exec-timeout 0 0 privilege level 15 logging synchronous transport input none line aux 0 line vty 0 4 login ! end r3# r1#5 [Resuming connection 5 to r5 ... ] r5#w rt where rt ^ % Invalid input detected at '^' marker. r5#wr t Building configuration... Current configuration: ! version 12.0 service timestamps debug datetime service timestamps log datetime no service password-encryption ! hostname r5 ! no logging console ! username cisco password 0 cisco username cisco autocommand access-enable timeout 1 ip subnet-zero no ip domain-lookup ip domain-name CISCO.COM ipx routing 0005.0005.0005 ! ! crypto isakmp policy 100 hash md5 authentication pre-share crypto isakmp key cisco address 135.7.1.3 ! ! crypto ipsec transform-set TRANSFORM esp-des mode transport ! ! crypto map CRYPTO 10 ipsec-isakmp set peer 135.7.1.3 set transform-set TRANSFORM match address 132 clock timezone CST -6 clock summer-time CDT recurring ! ! ! interface Loopback100 no ip address no ip directed-broadcast ipx network 10 ! interface Tunnel100 no ip address no ip directed-broadcast ipx network 1000 tunnel source Serial0.1 tunnel destination 135.7.1.3 ! interface Ethernet0 ip address 135.7.5.5 255.255.255.0 no ip directed-broadcast ip ospf interface-retry 0 no keepalive ! interface Serial0 no ip address no ip directed-broadcast encapsulation frame-relay no ip route-cache no ip mroute-cache no fair-queue no frame-relay inverse-arp ! interface Serial0.1 multipoint ip address 135.7.1.5 255.255.255.0 no ip directed-broadcast no ip route-cache ip ospf network broadcast ip ospf interface-retry 0 ip ospf priority 200 no ip mroute-cache frame-relay map ip 135.7.1.1 501 broadcast frame-relay map ip 135.7.1.3 503 broadcast crypto map CRYPTO ! interface Serial1 no ip address no ip directed-broadcast shutdown ! router ospf 1 network 135.7.1.0 0.0.0.255 area 0 network 135.7.5.0 0.0.0.255 area 5 ! ip classless ! access-list 100 dynamic test permit tcp host 135.7.1.1 host 135.7.1.5 eq telnet access-list 100 permit tcp any host 135.7.1.5 eq telnet access-list 100 permit ip any any access-list 101 dynamic ping permit icmp host 135.7.1.1 host 135.7.5.5 log access-list 101 deny icmp host 135.7.1.1 host 135.7.5.5 log access-list 101 permit ip any any access-list 132 permit gre any any access-list 133 deny gre any any access-list 133 permit ip any any ! ! ! i
RE: gre/ipsec
It should work with the following access list for your crypto-map: access-list 101 permit gre host 135.7.1.3 host 135.7.1.5and vise versa for the other router, just as you had it. This will apply the crypto-map to traffic traversing the GRE tunnel. Take a look at the following CCO documentation on IPX over IPSec/GRE Tunnels: http://www.cisco.com/warp/public/707/33.shtml I don't have access to the working configurations, but this is what I have used for the same situation, including Appletalk and IP instead of IPX. Can you verify that it works with IP and not IPX traffic? If the IPX traffic works without the crypto-map statements applied, then the GRE tunnel is working. When you apply the crypto-map, if the IPX communication does not work properly, then I would imagine IP traffic would not work properly either. At this point, there is a problem with SA negotiation, and there is most likely one of the following occuring: 1. Crypto-map not applied to both the physical and tunnel interface 2. Conflicting information in the transform-sets on each router Can you provide us with the output of: show crypto engine connections active show crypto ipsec sa detail show crypto isakmp policy Ryan Moffett -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of vr4drvr . Sent: Wednesday, June 07, 2000 5:12 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: gre/ipsec not easily. here's the deal...i can use an access list such as... acc 132 per icmp ho 135.7.1.3 ho 135.7.1.5 log on the host 135.7.1.3 pointing to 135.7.1.5, and of course the mirror image on the other side. all works fine with the pings, in that the first 5 time-out while the SA is built. after that the pings are successful. but when i use the following... acc 132 per gre ho 135.7.1.3 ho 135.7.1.5 log the ipx pings never bring up the line. shouldn't the above acl cover gre encapsulated packets? >From: "Kenny Sallee" <[EMAIL PROTECTED]> >To: "vr4drvr ." <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> >Subject: Re: gre/ipsec >Date: Wed, 7 Jun 2000 13:59:57 -0700 > >Can you post your configs? > >Kenny > >- Original Message - >From: "vr4drvr ." <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Wednesday, June 07, 2000 11:32 AM >Subject: gre/ipsec > > > > i'm trying a simple GRE/IPSEC scenario that i can't seem to get to work. > > i've built a tunnel between 2 router to pass ipx traffic, and for >security >i > > would like to encrypt the tunnel traffic. my crypto map points to an >access > > list that allows gre traffic, but the crypto isakmp sa never builds. >any > > ideas? > > > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com > > > > ___ > > UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html > > FAQ, list archives, and subscription info: http://www.groupstudy.com > > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: gre/ipsec
I have done this a number of times, can you post "sanitized" versions of your configs? Ryan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of vr4drvr . Sent: Wednesday, June 07, 2000 2:33 PM To: [EMAIL PROTECTED] Subject: gre/ipsec i'm trying a simple GRE/IPSEC scenario that i can't seem to get to work. i've built a tunnel between 2 router to pass ipx traffic, and for security i would like to encrypt the tunnel traffic. my crypto map points to an access list that allows gre traffic, but the crypto isakmp sa never builds. any ideas? Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: firewall features
Justin, http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/secur _c/scprt3/index.htm Take a look at the Context Based Access Control and the various other firewall features. Ryan Moffett -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Justin Marcus Sent: Tuesday, June 06, 2000 8:13 PM To: [EMAIL PROTECTED] Subject: firewall features hello ppls :) if i have an ios with that special firewall thing in it.. how do i actualy use it.. i was using that cisco search function on there website to find info but like it always does for me it gave back unrelated topics :(.. like is there special commands built into the access-list commands ? or is it a special command all together. ? anyways could someone fill me in please :) thanks heaps :) Justin... ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Transparent Briding over Frame Relay Hub and Spoke
You can configure transparent bridging over Frame Relay point-multipoint interfaces. See: http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/wan_c /wcfrelay.htm#xtocid2427346 Basically, on the point-multipoint subinterface, you need to associate the DLCI's with a bridge group using the "frame-relay map bridge" command. An example is given here: http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/wan_r /wrfrelay.htm#xtocid18778220 Ryan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Yuen Me Sent: Sunday, May 28, 2000 7:17 PM To: [EMAIL PROTECTED] Subject: Transparent Briding over Frame Relay Hub and Spoke Hi all, I tend to conclude the following statement and pls confirm whether I'm right: "point to point" subinterface is the only option in the HUB to allow spoke to spoke packet forwarding happen in transparent bridging environment. I've tried physical interface and multipoint subinterface on hub. I've tried: - making the hub as the root bridge - extensive map statements in the hub and spoke with "broadcast" keyword All of them fail. I believe transparent bridge does not allow the packet received on one interface to be forwarded to the same interface again, even though the paths (DLCI) are different. Yuenme Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
CCIE Design Lab Format Released
For anyone wondering, Cisco has released the format of the design lab. You can get it here: http://www.cisco.com/warp/public/625/ccie/certifications/design.html#4 ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Backup interface never comes up.
You could also shut down the serial interface on the far end of the link so that the interface goes into a down/down state. Brad is right, administratively shutting down an interface will not trigger the backup link to come up. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Brad Ellis Sent: Thursday, May 25, 2000 7:13 PM To: [EMAIL PROTECTED] Subject: Re: Backup interface never comes up. the SHUT command on your primary interface will not bring the backup interface up. so what you are seeing is definitely normal. if your backup interface DID come up from a shut command on your primary interface, then I'd say you have a broken router! try using a floating static route instead...or pull the cable off the serial port -brad "James Xie" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Hi, > > I am doing a study on DDR. On my router, I configured the bri0 interface, and > it works fine. The router can place a call to the other end and traffic > passes through > perfectly. (It means all the isdn interface and dialer configuration are > correct). > > My problem is, once i placed the interface as a backup for another serial > interface > (frame relay ), the bri0 is placed in standby mode automatically and even > the layer 1 > and layer 2 for the bri0 are administratively shutdown automatically. I > tried to shutdown > the primary frame relay interface and the backup bri0 never comes up. > > I tried it on different routers with the same result. > > Is this behavior normal or I missed something? > > Thank you very much for advice. > > Jim. > > Attached is my configuration sample: > > int s0 > encapsulation frame-relay > ip address 10.1.1.1 255.255.255.0 > backup delay 10 30 > backup interface bri0 > no shut > > int bri0 > encapsulation ppp > ip address 10.1.2.1 255.255.255.0 > isdn switch-type basic-ni1 > isdn spid1 12345678 1234 > isdn spid2 23456789 2345 > dialer-group 1 > dialer map ip 10.1.2.2 broadcast 6789 > no shut > .. > > ___ > UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html > FAQ, list archives, and subscription info: http://www.groupstudy.com > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > --- ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
