From: Olopade Olorunloba (lolopade@ipnxnigeria.net)
Date: Tue Aug 08 2006 - 17:46:29 ART
Or so I thought. Please read the following thread, it comes from the SP
forum.
=========================================================================
OK, after having said all that, I found the solution... :)
One end:
interface Serial1/0:0
ip address 1.1.1.1 255.255.255.252
encapsulation ppp
peer default ip address 1.1.1.2
ppp ipcp mask 255.255.255.252
end
Other end:
ip dhcp pool IPCP-POOL
import all
origin ipcp
!
interface Serial1/0:0
ip address pool IPCP-POOL
encapsulation ppp
ppp ipcp mask request
I think this is a misuse of the ODAP feature
(http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_cha
pter09186a0080440089.html)
but it seems to work.
Got to love the CCIE lab! :)
Cheers,
Zsombor
At 07:37 PM 6/22/2006 +0100, Olopade Olorunloba wrote:
>Hello Scot, nice to read from you again.
>
>Unfortunately, the problem is not yet solved. The peer neighbour route
>will make the host known via that interface, but as far as the router
>is concerned, still not on the same subnet. Seems the check is for
>subnet, not for interface.
>
>Zsombor, I can not understand your point about IPCP and configuring the
>remote peer, can you explain further. And wondering why I'm this dumb
>and not just configuring ip unnumbered or ip address? It is because of
>the CCIE lab and hoping something this dumb does not come up in the lab.
>
>Bob, I do not get what you did to get around the problem, downgraded
>your IOS to Pre 12.1T?
>
>Thanks to all
>
>
>-----Original Message-----
>From: Scott Morris [mailto:swm@emanon.com]
>Sent: 22 June 2006 18:53
>To: 'Zsombor Papp'; 'Olopade Olorunloba'; 'Bob Sweet'
>Cc: comserv@groupstudy.com
>Subject: RE: OSPF across negotiated PPP
>
>And that would explain why the RFC doesn't mention it and why I recall
>having no problem back in 12.0 stuff when I did a lot of dial-based
>solutions using IPCP and OSPF! (grin)
>
>In that case though, if you did the peer neighbor route on both side
>then it would show up as a connected route and shouldn't be a problem per a
check?
>
>Unnumbered shouldn't be different:
>
>http://www.cisco.com/en/US/tech/tk365/technologies_configuration_exampl
>e0918
>6a00801ec9e0.shtml
>
>Scott
>
>-----Original Message-----
>From: Zsombor Papp [mailto:zpapp@cisco.com]
>Sent: Thursday, June 22, 2006 1:35 PM
>To: 'Olopade Olorunloba'; Bob Sweet; swm@emanon.com
>Cc: comserv@groupstudy.com
>Subject: RE: OSPF across negotiated PPP
>
>There is a check for the source IP address of the OSPF packet and it's
>dropped if it's not on the subnet of the interface where the packet was
>received. This is a feature introduced in January 2000 (into IOS
>12.0(25)S and 12.1T).
>
>Having said that, I'd have a (perhaps dumb) question for the folks
>facing this problem: why is it useful to negotiate the IP address via
>IPCP in your situation? Why don't you just configure the other end with a
/30 mask?
>
>Thanks,
>
>Zsombor
>
>At 01:15 PM 6/22/2006 -0400, Scott Morris wrote:
> >If you are running OSPF as a point-to-point network type on both
> >sides, then the mask is not required as a peer negotiating piece.
> >
> >I'm assuming you're assigning the address out of a pool, so that the
"hub"
> >is at least on a similar network there, but for OSPF point-to-point
> >it shouldn't matter.
> >
> >HTH,
> >
> >
> >Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713,
> >JNCIE #153, CISSP, et al.
> >CCSI/JNCI
> >IPExpert CCIE Program Manager
> >IPExpert Sr. Technical Instructor
> >smorris@ipexpert.com
> >http://www.ipexpert.com
> >
> >
> >
> >-----Original Message-----
> >From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> >Of Zsombor Papp
> >Sent: Thursday, June 22, 2006 12:59 PM
> >To: 'Olopade Olorunloba'; Robert McCallum
> >Cc: comserv@groupstudy.com
> >Subject: RE: OSPF across negotiated PPP
> >
> >Update: it seems IPCP will not configure anything but a /32 mask on
> >the related interface, and that's by design, not due to a bug. The
> >'ppp ipcp mask' command I mentioned is used to provide a pool of
> >addresses to the peer on the other end of the link, not to be used on
> >the link
>itself.
> >
> >Thanks,
> >
> >Zsombor
> >
> > >At 01:17 PM 6/22/2006 +0100, Robert McCallum wrote:
> > >>No peer-neighbor route ;-)
> > >
> > >How will this help?
> > >
> > >Yes, the problem is the /32 mask.
> > >
> > >There is a 5+ old feature request open to create a knob that would
> > >make OSPF ignore the source IP address. I am not sure why that
> > >would be a good idea (probably the OSPF folks are not sure either
> > >that's why it's still open... :). There are IPCP related commands
> > >that in theory allow the negotiation of a subnet mask other than
> > >/32, 'ppp ipcp
>mask <mask>'
> > >and 'ppp ipcp mask request', but they don't seem to work. I tried
> > >'no peer-neighbor route' as well and it doesn't make a difference
> > >(although I may not understand how it's supposed to be used).
> > >
> > >I couldn't find a DDTS for the inability to negotiate a non-/32 mask.
> > >I'd open a case with TAC if I were you.
> > >
> > >Thanks,
> > >
> > >Zsombor
> > >
> > >>Robert McCallum CCIE #8757
> > >>Senior Consultant
> > >>Mobile : +44(0)7818002241
> > >>
> > >> > -----Original Message-----
> > >> > From: Olopade Olorunloba [mailto:lolopade@ipnxnigeria.net]
> > >> > Sent: 22 June 2006 12:41
> > >> > To: 'Robert McCallum'; comserv@groupstudy.com
> > >> > Subject: RE: OSPF across negotiated PPP
> > >> >
> > >> > Oh yeah, there is IP connectivity. I think the problem lies in
> > >> > the fact that I get /32 mask from the PPP negotiation and
> > >> > therefore believes the other end is not on the same subnet. If
> > >> > I manually configure the IP address, with a non /32 mask, the
> > >> > OSPF adjacency is formed.
> > >> >
> > >> > So the question from my view is how to negotiate a non /32 mask
> > >> > with PPP or disable the subnet checking with OSPF.
> > >> >
> > >> > Can you help?
> > >> >
> > >> > -----Original Message-----
> > >> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> > >> > Behalf Of Robert McCallum
> > >> > Sent: 22 June 2006 11:16
> > >> > To: 'Olopade Olorunloba'; comserv@groupstudy.com
> > >> > Subject: RE: OSPF across negotiated PPP
> > >> >
> > >> > Ok first thing can you ping the other end?
> > >> >
> > >> > Robert McCallum CCIE #8757
> > >> > Senior Consultant
> > >> > > -----Original Message-----
> > >> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> > >> > > Behalf Of Olopade Olorunloba
> > >> > > Sent: 22 June 2006 10:29
> > >> > > To: comserv@groupstudy.com
> > >> > > Subject: RE: OSPF across negotiated PPP
> > >> > >
> > >> > > I need help, advice or suggestion here?
> > >> > >
> > >> > > Anybody there?
> > >> > >
> > >> > > -----Original Message-----
> > >> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> > >> > > Behalf Of Olopade Olorunloba
> > >> > > Sent: 19 June 2006 19:44
> > >> > > To: comserv@groupstudy.com
> > >> > > Subject: OSPF across negotiated PPP
> > >> > >
> > >> > > Hello, I'm trying to configure OSPF adjacency across a PPP link.
> > >> > > The IP address on one end is negotiated. I can not get the
> > >> > > adjacency up. Debug OSPF adjacency gives
> > >> > >
> > >> > > *Mar 3 14:30:27.610: OSPF: Rcv pkt from 1.1.1.1, Serial0/0,
> > >> > > area
> > >> > 0.0.0.0
> > >> > > :
> > >> > > src
> > >> > >
> > >> > > not on the same network
> > >> > >
> > >> > >
> > >> > >
> > >> > > These are the config
> > >> > >
> > >> > >
> > >> > >
> > >> > > Router 1
> > >> > >
> > >> > > interface Serial0/0
> > >> > >
> > >> > > ip address negotiated
> > >> > >
> > >> > > encapsulation ppp
> > >> > >
> > >> > > no fair-queue
> > >> > >
> > >> > > end
> > >> > >
> > >> > > !
> > >> > >
> > >> > > router ospf 1
> > >> > >
> > >> > > log-adjacency-changes
> > >> > >
> > >> > > network 1.0.0.0 0.255.255.255 area 0
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > Router 2
> > >> > >
> > >> > >
> > >> > >
> > >> > > interface Serial0/2
> > >> > >
> > >> > > ip address 1.1.1.1 255.255.255.252
> > >> > >
> > >> > > encapsulation ppp
> > >> > >
> > >> > > peer default ip address 1.1.1.2
> > >> > >
> > >> > > clock rate 64000
> > >> > >
> > >> > > !
> > >> > >
> > >> > > router ospf 1
> > >> > >
> > >> > > log-adjacency-changes
> > >> > >
> > >> > > network 1.0.0.0 0.255.255.255 area 0
> > >> > >
> > >> > >
> > >> > >
> > >> > > Does OSPF have a problem forming adjacencies like these?
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > Network Engineer
> > >> > > ipNX Nigeria Limited
> > >> > > No. 4, Balarabe Musa Crescent Victoria, Island, Lagos
> > >> > > Tel: 234 (01) 461 9943 - 6,
> > >> > > Fax: 234 (01) 261 4633,
> > >> > > Mobile: 234 (0) 803 333 5974
> > >> > >
> > >> > > _____________________________________________________________
> > >> > > __
> > >> > > __
> > >> > > ____ Subscription information:
> > >> > > http://www.groupstudy.com/list/comserv.html
> > >> > >
> > >> > > _____________________________________________________________
> > >> > > __
> > >> > > __
> > >> > > ____ Subscription information:
> > >> > > http://www.groupstudy.com/list/comserv.html
> > >> >
> > >> >
> > >> >
> > >> > Note:The information contained in this message may be
> > >> > privileged and confidential and protected from disclosure . If
> > >> > the reader of this message is not the intended recipient, or an
> > >> > employee or agent responsible for delivering this message to
> > >> > the intended recipient, you are hereby notified that any
> > >> > dissemination, distribution or copying of this communication is
> > >> > strictly prohibited. If you have received this communication in
> > >> > error, please notify us immediately by replying to the message
> > >> > and deleting
>it from your computer.
> > >> > Thankyou. ThruPoint Ltd.
> > >> >
> > >> > _______________________________________________________________
> > >> > __
> > >> > __
> > >> > __ Subscription information:
> > >> > http://www.groupstudy.com/list/comserv.html
> > >>
> > >>
> > >>
> > >>
> > >>Note:The information contained in this message may be privileged
> > >>and confidential and protected from disclosure . If the reader of
> > >>this message is not the intended recipient, or an employee or
> > >>agent responsible for delivering this message to the intended
> > >>recipient, you are hereby notified that any dissemination,
> > >>distribution or copying of this communication is strictly
> > >>prohibited. If you have received this communication in error,
> > >>please notify us immediately by replying to the message and deleting
it from your computer.
> > >>Thankyou. ThruPoint Ltd.
> > >>
> > >>__________________________________________________________________
> > >>__
> > >>_ Subscription information:
> > >>http://www.groupstudy.com/list/comserv.html
> >
> >_____________________________________________________________________
> >Subscription information: http://www.groupstudy.com/list/comserv.html
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Brian McGahan
Sent: 08 August 2006 18:53
To: Olopade Olorunloba; Schulz, Dave; Cisco certification
Subject: RE: Routing through a ppp ipcp negotiated interface
OSPF does not require devices to be on the same subnet to
establish adjacency, so it should work fine. In RIP this behavior can
be disabled with the "no validate-update-source" process level command.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Olopade Olorunloba
> Sent: Tuesday, August 08, 2006 12:37 PM
> To: 'Schulz, Dave'; 'Cisco certification'
> Subject: RE: Routing through a ppp ipcp negotiated interface
>
> OSPF does not form because the mask negotiated is a host route, and
> therefore the router believes that the remote end is not on the same
> subnet.
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Schulz, Dave
> Sent: 04 August 2006 21:41
> To: Cisco certification
> Subject: Routing through a ppp ipcp negotiated interface
>
> I discovered something interesting while setting up a network in my
lab
> with using ppp ipcp to negotiate the address across a serial link. In
> the following scenario, the address is negotiated fine. However, I am
> trying to run the various protocols across the link. EIGRP, but RIP
> will not allow the database to be received at the router with the
> negotiated interface. OSPF will not allow the adjacency to form.
> BTW....I can get the routes to be sent from the negotiated interface
to
> the remote (negotiating) interface of the remote router. I am just
> trying things and investigating ....so this may not be valid to do
this.
> Just wondering why EIGRP works in this way, but OSPF and RIP do not.
> Thoughts?
>
> On RIP...I get the following debug error.....(I tried this both
> multicast and unicast updates, with no difference).
>
> *Mar 16 11:07:12.927: RIP: ignored v2 update from bad source 25.5.5.5
on
> Serial0/1
>
> Here are the configs at the interface level......
>
> R3.....
>
> !
> interface Serial1
> ip address negotiated
> encapsulation ppp
> end
>
>
> R5......
> !
> interface Serial0/1
> ip address 35.5.5.5 255.255.255.0
> encapsulation ppp
> peer default ip address 35.5.5.3
> clock rate 2000000
> end
>
>
>
> Dave Schulz, CCDP, CCNP, CCSP
> Email: dschulz@dpsciences.com <mailto:dschulz@dpsciences.com >
>
>
This archive was generated by hypermail 2.1.4 : Fri Sep 01 2006 - 15:41:56 ART