Re: OSPF_SL0 from FULL to DOWN, Neighbor Down: Interface down

Thanks everyone for providing your valuable inputs. The problem has been
resolved ; however, I am still confused. I noticed that SW1 connected to R6
was establishing the OSPF neighbourship on vrf VPN_A, but using 2.2.2.2 as a
router-id. As a OPSF rule, it was using the highest loopback IP address from
loopback 200 as it was only configured in vrf VPN_A. Even when I shutdown
the loopback 200 on R6, it was still establishing OSPF relationship with
loopback 200, pretty wierd. i cleared neighbour relationship many times, but
Sw1 was still establishing neighbourship with router-id 2.2.2.2.

I change the IP address to 3.3.3.3 and it worked as charm. As per logic, I
was thinking it was still use 3.3.3.3 as neighbour-id , but Sw1 is using
connected interface address.

R5

interface Loopback200
 ip vrf forwarding VPN_A
 ip address 1.1.1.1 255.255.255.255

router ospf 10 vrf VPN_A
 log-adjacency-changes
 area 1 sham-link 1.1.1.1 3.3.3.3
 redistribute bgp 100 subnets tag 667
 network 155.1.58.5 0.0.0.0 area 1

router bgp 100
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 150.1.4.4 remote-as 100
 neighbor 150.1.4.4 update-source Loopback0
 !
 address-family vpnv4
  neighbor 150.1.4.4 activate
  neighbor 150.1.4.4 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf VPN_B
  redistribute connected
  redistribute static
  no synchronization
 exit-address-family
 !
 address-family ipv4 vrf VPN_A
  redistribute connected metric 1
  redistribute static
  redistribute ospf 10 vrf VPN_A
  no synchronization
 exit-address-family

R6

interface Loopback200
 ip vrf forwarding VPN_A
 ip address 3.3.3.3 255.255.255.255

router ospf 10 vrf VPN_A
 log-adjacency-changes
 area 1 sham-link 3.3.3.3 1.1.1.1
 summary-address 172.16.0.0 255.255.0.0
 redistribute bgp 100 subnets tag 666
 network 155.1.67.6 0.0.0.0 area 1

router bgp 100
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 150.1.4.4 remote-as 100
 neighbor 150.1.4.4 update-source Loopback0
 !
 address-family vpnv4
  neighbor 150.1.4.4 activate
  neighbor 150.1.4.4 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf VPN_B
  redistribute connected
  redistribute static
  no synchronization
 exit-address-family
 !
 address-family ipv4 vrf VPN_A
  redistribute connected metric 1
  redistribute static
  redistribute ospf 10 vrf VPN_A
  no synchronization
 exit-address-family

Regards,

Bilal Hansrod

On Sat, Jul 2, 2011 at 10:04 AM, Marko Milivojevic <markom_at_ipexpert.com>wrote:

> On Fri, Jul 1, 2011 at 16:49, Bilal Hansrod <bilal.hansrod_at_gmail.com>
> wrote:
> > I have adverstised both loopbacks via BGP. I can see both /32's are
> learned
> > via BGP when tunnel is down and when sham-link is up for few seconds, I
> see
> > that routes are now advertised via OSPF.
> >
> > Am I missing something-
>
> Yes you are - my previous message, which would've covered this exact
> case you're experiencing. You need to prevent PE routers from learning
> about each others' sham-link endpoints in OSPF. They must be known
> only in BGP.
>
> --
> Marko Milivojevic - CCIE #18427
> Senior Technical Instructor - IPexpert
>
> FREE CCIE training: http://bit.ly/vLecture
>
> Mailto: markom_at_ipexpert.com
> Telephone: +1.810.326.1444
> Web: http://www.ipexpert.com/

Blogs and organic groups at http://www.ccie.net
Received on Sun Jul 03 2011 - 15:32:13 ART