From: Brown, Patrick (NSOC-OCF} (PBrown4@chartercom.com)
Date: Tue Aug 05 2003 - 14:56:10 GMT-3
If you are allowed, use OSPF network type point2multipoint. This will
generate /32 for all routers off the multipoint interface with OSPF. Then
you will not need the frame maps to each spoke.
-----Original Message-----
From: John Matijevic
To: Kademada, Preetham; 'ccie2be'; Group Study; Joe Martin
Sent: 8/5/2003 12:38 PM
Subject: Re: IBGP neighbors over F/R
Hello Team,
I think part of the problem is that since you cant have a map from one
spoke
to another (ie R3--R1) the ospf packet will never get from R3 to R1,
thats
becuase all ospf packets have a ttl set to 1. Since we dont have a full
mesh
IGP then I believe the solution would have to be a route reflector or
confederation in your case.
Sincerely,
Matijevic
----- Original Message -----
From: "Kademada, Preetham" <PKademada@NECBNS.com>
To: "'ccie2be'" <ccie2be@nyc.rr.com>; "Group Study"
<ccielab@groupstudy.com>; "Joe Martin" <jmartin@capitalpremium.net>
Sent: Tuesday, August 05, 2003 1:25 PM
Subject: RE: IBGP neighbors over F/R
> Hey Raj,
> Once the OSPF establishes adjacency you should be able to
ping
the
> spokes.
>
> Preetham
>
> -----Original Message-----
> From: ccie2be [mailto:ccie2be@nyc.rr.com]
> Sent: Tuesday, August 05, 2003 10:13 AM
> To: Group Study; Joe Martin
> Subject: Re: IBGP neighbors over F/R
>
>
> Hey Joe
>
> Thanks for getting back to me. Normally, I would have frame maps from
each
> spoke to the other spokes but the lab I'm doing only allowed me to
have 1
> frame map statement on each spoke pointing to the hub. So, by design,
the
> spokes can't ping each other.
>
> Which raises another issue. Forget about BGP for a moment - assume
BGP
> isn't running, shouldn't the spokes be able to ping each other once
OSPF
is
> configured and R2 (the hub) has formed an adjacency with R1 and R3?
>
> Both R1 and R3 show each others lo0 in their route table.
>
> Thanks, Raj
>
> ----- Original Message -----
> From: "Joe Martin" <jmartin@capitalpremium.net>
> To: "ccie2be" <ccie2be@nyc.rr.com>; "Group Study"
<ccielab@groupstudy.com>
> Sent: Tuesday, August 05, 2003 12:24 PM
> Subject: RE: IBGP neighbors over F/R
>
>
> > Don't see the full configs, but it sounds like you forgot
spoke-to-spoke
> FR
> > maps. Add maps on each of the spokes pointing to the other spokes
> ipaddress
> > and the hub DLCI without the broadcast keyword. Should come up.
> >
> > HTH,
> >
> > Joe Martin
> > CCIE #12035
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf
Of
> > ccie2be
> > Sent: August 05, 2003 10:13 AM
> > To: Group Study
> > Subject: IBGP neighbors over F/R
> >
> >
> > Hi,
> >
> > BGP wouldn't form peers between 2 spokes on a F/R hub and spoke
topology.
> >
> > Here are the details:
> >
> > R3---------R2----------R1
> > spoke hub spoke
> >
> >
> > All routers are running OSPF and the F/R is in subnet
172.16.100.0/24
and
> > the
> > f/r interfaces were all left at their default ospf network types -
> > non-broadcast. The neighbor command was configured on R2 to allow
it to
> > form
> > ospf adjacencies with R1 and R3. R1 can ping R2 but not R3 and R3
can
> ping
> > R2
> > but not R1.
> >
> > R1's loopback interface = 192.168.1.1 and R2's loopback =
192.168.2.2
and
> > R3's
> > loopback = 192.168.3.3
> >
> > The route table of each router shows all 3 loopbacks.
> >
> > R1's BGP config:
> >
> > router bgp 123
> > nei 192.168.2.2 remote-as 123
> > nei 192.168.2.2 update-source lo0
> > nei 192.168.3.3 remote-as 123
> > nei 192.168.3.3 update-source lo0
> >
> >
> > R2's config:
> >
> > router bgp 123
> > nei 192.168.1.1 remote-as 123
> > nei 192.168.1.1 update-source lo0
> > nei 192.168.3.3 remote-as 123
> > nei 192.168.3.3 update-source lo0
> >
> > R3's config:
> >
> > router bgp 123
> > nei 192.168.1.1 remote-as 123
> > nei 192.168.1.1 update-source lo0
> > nei 192.168.2.2 remote-as 123
> > nei 192.168.2.2 update-source lo0
> >
> >
> > R1 and R3 can both peer with R2 but they don't peer with each other.
I
> > thought that as long as there was a TCP path ( the ip addr was in
the
> route
> > table), R3 and R1 could peer. But this isn't working. Can someone
> explain
> > why not?
> >
> > Thanks, Raj
> >
> >
> >
This archive was generated by hypermail 2.1.4 : Tue Sep 02 2003 - 18:53:53 GMT-3