From: Muhamamd Durrani (dan_schaw@yahoo.com)
Date: Tue Feb 25 2003 - 01:28:08 GMT-3
Your third point is according to RFC implementation.
P2mp always creates extra /32 in the table to teh
interface u applied on . and through ospf you can
advertise it to HUB and than from HUB to spkes in case
u r restricted to use map statement on spokes to have
full ip rechibility to all spokes. I could see this is
the best way to go for if map ststements are not
allowed on spokes for reachibility except for Hub.
Regards,
--- Navin Jassi <nav_uk@hotmail.com> wrote:
> Hi,
>
> I don't beleive that OSPF has a split horizon rule
> in regards to your 3rd
> point. Correct me if I'm wrong.
>
> Keep the gotchas coming though!!!
>
>
> ----- Original Message -----
> From: <ray_gan74@hotmail.com>
> To: <ccielab@groupstudy.com>
> Sent: Thursday, February 20, 2003 8:10 PM
> Subject: CCIE Gotchas: Watch out!
>
>
> > Wanted to start a thread on some gotchas to look
> out for when configuring
> > protocols/redistribution. PLEASE contribute. Ill
> go first.
> >
> > 1. BGP-->OSPF redistribution
> >
> > What = Routes not advertised to ibgp peers.
> > Why? = Router ID's of ospf and bgp don't
> match.
> > Solution: Use BGP confederations which does not
> suffer from this issue.
> > Use another IGP instead of OSPF. Turn off BGP
> synchronization on each BGP
> > router within AS. Hardcode the OSPF
> and BGP router-id's to
> so
> > that they match.
> >
> >
> > 2. You can not configure a virtual link across a
> stub area
> >
> >
> > 3. If you set a p2p link as ip ospf
> point-to-multipoint then what you will
> see
> > is /32's being advertised for both your end points
> of the link breaking
> the
> > split horizon rule. I am not sure why the /32 sets
> sent.
> >
> > .
This archive was generated by hypermail 2.1.4 : Sat Mar 01 2003 - 11:06:34 GMT-3