Re: BGP to OSPF Redistribution w/ Sham-Link

From: Marko Milivojevic <markom_at_ipexpert.com>
Date: Wed, 12 Oct 2011 14:07:07 -0700

I will repeat - there is no magic, you're just not seeing what I'm
trying to show you. The restriction is very clear - "Loopback must not
be present in OSPF" - with your configuration, it is (I don't even
have to look, as just by looking at the configuration I see it is
there and can explain why - therefore, no "magic"). Try what I told
you and see it work. Then try to work to reach the conclusion I'm
trying to teach you.

Now, if you don't want to do that, say the word and I'll gladly
explain, but IMNSHO, it's better this way...

--
Marko Milivojevic - CCIE #18427 (SP R&S)
Senior Technical Instructor - IPexpert
On Wed, Oct 12, 2011 at 13:18, Carlos G Mendioroz <tron_at_huapi.ba.ar> wrote:
> Have you tried this with the config I sent ?
> Cause it does not do the magic here.
>
> (And BTW, if this does not fit the "magic" label, I don't know what does
> it. I wonder what do you tell students to support that an internal BGP
> route is not good enough for some situations, and a redistributed one is).
>
> -Carlos
>
> Marko Milivojevic @ 12/10/2011 12:40 -0300 dixit:
>>
>> It's not stupid, just something not very often warned about in the
>> books and the documentation. Here's an exercise for you:
>>
>> Now try the same thing by redistributing the Loopback into BGP instead
>> of using the network statement and see if it changes... ;-)
>>
>> --
>> Marko Milivojevic - CCIE #18427 (SP R&S)
>> Senior Technical Instructor - IPexpert
>>
>> On Wed, Oct 12, 2011 at 03:50, Carlos G Mendioroz <tron_at_huapi.ba.ar>
>> wrote:
>>>
>>> I'm sure doing something relly stupid then :)
>>> I've just done it again, below the files to reproduce it.
>>> Just two PEs, serial link and a vrf. I configure it and SL (sham link)
>>> comes up fine. Bounce it and it does not.
>>> This config has some deviations from the standard template, like
>>> area 146 being an NSSA and BGP not being established from loopbacks,
>>> but that should not make a difference, I guess.
>>>
>>> -Carlos
>>>
>>> Sham.net:
>>> # Demo sham link
>>> [172.30.0.2]
>>>
>>> B  [[7200]]
>>> B  image = \var\c7200\ios\c7200-advipservicesk9-mz.124-15.T1.bin
>>> B  npe = npe-400
>>> B  ram = 160
>>>
>>> B  [[ROUTER PE-Piz]]
>>> B  console = 2001
>>> B  s1/0 = F1 1
>>>
>>> B  [[ROUTER PE-Lav]]
>>> B  console = 2002
>>> B  s1/0 = F1 2
>>>
>>> B  [[ROUTER CE-Piz]]
>>> B  console = 2003
>>> B  f0/0 = PE-Piz f0/0
>>>
>>> B  [[ROUTER CE-Lav]]
>>> B  console = 2004
>>> B  f0/0 = PE-Lav f0/0
>>>
>>> B  [[FRSW F1]]
>>> B  1:102 = 2:201
>>> B  2:201 = 1:102
>>>
>>> -----
>>> PE-Lav:
>>> hostname PE-Lav
>>> !
>>> ip vrf M
>>> B rd 100:100
>>> B route-target export 100:100
>>> B route-target import 100:100
>>> !
>>> interface Loopback100
>>> B ip vrf forwarding M
>>> B ip address 10.68.146.228 255.255.255.255
>>> !
>>> interface FastEthernet0/0
>>> B ip vrf forwarding M
>>> B ip address 10.68.146.6 255.255.255.252
>>> !
>>> interface Serial1/0
>>> B no ip address
>>> B encapsulation frame-relay
>>> B serial restart-delay 0
>>> !
>>> interface Serial1/0.201 point-to-point
>>> B ip address 172.16.12.2 255.255.255.252
>>> B mpls ip
>>> B frame-relay interface-dlci 201
>>> !
>>> router ospf 400 vrf M
>>> B log-adjacency-changes
>>> B area 146 nssa
>>> B area 146 sham-link 10.68.146.228 10.68.146.227 cost 1000
>>> B network 10.68.146.4 0.0.0.3 area 146
>>> !
>>> router bgp 100
>>> B no synchronization
>>> B bgp log-neighbor-changes
>>> B neighbor 172.16.12.1 remote-as 100
>>> B no auto-summary
>>> B !
>>> B address-family vpnv4
>>> B neighbor 172.16.12.1 activate
>>> B neighbor 172.16.12.1 send-community extended
>>> B exit-address-family
>>> B !
>>> B address-family ipv4 vrf M
>>> B no synchronization
>>> B network 10.68.146.228 mask 255.255.255.255
>>> B exit-address-family
>>>
>>> ------
>>> PE-Piz:
>>> hostname PE-Piz
>>> !
>>> ip vrf M
>>> B rd 100:100
>>> B route-target export 100:100
>>> B route-target import 100:100
>>> !
>>> interface Loopback100
>>> B ip vrf forwarding M
>>> B ip address 10.68.146.227 255.255.255.255
>>> !
>>> interface FastEthernet0/0
>>> B ip vrf forwarding M
>>> B ip address 10.68.146.2 255.255.255.252
>>> !
>>> interface Serial1/0
>>> B no ip address
>>> B encapsulation frame-relay
>>> B serial restart-delay 0
>>> !
>>> interface Serial1/0.102 point-to-point
>>> B ip address 172.16.12.1 255.255.255.252
>>> B mpls ip
>>> B frame-relay interface-dlci 102
>>> !
>>> router ospf 400 vrf M
>>> B log-adjacency-changes
>>> B area 146 nssa
>>> B area 146 sham-link 10.68.146.227 10.68.146.228 cost 1000
>>> B network 10.68.146.0 0.0.0.3 area 146
>>> !
>>> router bgp 100
>>> B no synchronization
>>> B bgp log-neighbor-changes
>>> B neighbor 172.16.12.2 remote-as 100
>>> B no auto-summary
>>> B !
>>> B address-family vpnv4
>>> B neighbor 172.16.12.2 activate
>>> B neighbor 172.16.12.2 send-community extended
>>> B exit-address-family
>>> B !
>>> B address-family ipv4 vrf M
>>> B no synchronization
>>> B network 10.68.146.227 mask 255.255.255.255
>>> B exit-address-family
>>>
>>> ------
>>>
>>> Narbik Kocharians @ 12/10/2011 02:17 -0300 dixit:
>>>>
>>>> *There's nothing really difficult with sham-links, if you follow the
>>>> steps for configuration.
>>>> *
>>>> I agree 1000 percent.
>>>>
>>>>
>>>>
>>>> On Tue, Oct 11, 2011 at 5:42 PM, Marko Milivojevic
>>>> <markom_at_ipexpert.com>wrote:
>>>>
>>>>> On Tue, Oct 11, 2011 at 16:22, Carlos G Mendioroz <tron_at_huapi.ba.ar>
>>>>> wrote:
>>>>>>
>>>>>> I said that I've just seen a test case where the link does not come
>>>>>> up, even with the loopback published in BGP and not in OSPF.
>>>>>> So I don't fit in your rule.
>>>>>
>>>>> ... if you have redistribution from BGP to OSPF, then you are very
>>>>> much advertising loopbacks in OSPF, unless you were filtering. If you
>>>>> were filtering, then you probably had an entirely different MPLS
>>>>> transport issue, which only manifested itself by sham-links not coming
>>>>> up.
>>>>>
>>>>> There's nothing really difficult with sham-links, if you follow the
>>>>> steps for configuration.
>>>>>
>>>>> --
>>>>> Marko Milivojevic - CCIE #18427 (SP R&S)
>>>>> Senior Technical Instructor - IPexpert
>>>>>
>>>>>
>>>>> B Blogs and organic groups at http://www.ccie.net
>>>>>
>>>>> _______________________________________________________________________
>>>>> Subscription information may be found at:
>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>> --
>>> Carlos G Mendioroz B <tron_at_huapi.ba.ar> B LW7 EQI B Argentina
>>>
>
> --
> Carlos G Mendioroz B <tron_at_huapi.ba.ar> B LW7 EQI B Argentina
Blogs and organic groups at http://www.ccie.net
Received on Wed Oct 12 2011 - 14:07:07 ART

This archive was generated by hypermail 2.2.0 : Tue Nov 15 2011 - 13:10:29 ART