Re: BGP to OSPF Redistribution w/ Sham-Link

Marko Milivojevic @ 12/10/2011 18:07 -0300 dixit:
> 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.

Marko,
your teaching method is not working with me. So just try by answering
the questions, if that's ok ?
In fact, I did what you told me to do AND IT DOES NOT WORK.
Man, I said that in plain english in the message I sent, or at least
that was what I intended by " it does not do the magic here".

Also, how can you say "I don't even have to look" and insist that
the Loopbacks are present in OSPF ? For granted that you did not look,
and are writing out of what you dream I was doing. In fact, the
configuration I sent does not have any redistribution and only has
OSPF enabled on VRFs FastEthernets.

It bothers me some, that you put so much energy in this argument that
the basic issue, e.g. what is needed for the SL to come up seems to fade
to a second plane.

-Carlos

>
> 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]
>>>>
>>>> [[7200]]
>>>> image = \var\c7200\ios\c7200-advipservicesk9-mz.124-15.T1.bin
>>>> npe = npe-400
>>>> ram = 160
>>>>
>>>> [[ROUTER PE-Piz]]
>>>> console = 2001
>>>> s1/0 = F1 1
>>>>
>>>> [[ROUTER PE-Lav]]
>>>> console = 2002
>>>> s1/0 = F1 2
>>>>
>>>> [[ROUTER CE-Piz]]
>>>> console = 2003
>>>> f0/0 = PE-Piz f0/0
>>>>
>>>> [[ROUTER CE-Lav]]
>>>> console = 2004
>>>> f0/0 = PE-Lav f0/0
>>>>
>>>> [[FRSW F1]]
>>>> 1:102 = 2:201
>>>> 2:201 = 1:102
>>>>
>>>> -----
>>>> PE-Lav:
>>>> hostname PE-Lav
>>>> !
>>>> ip vrf M
>>>> rd 100:100
>>>> route-target export 100:100
>>>> route-target import 100:100
>>>> !
>>>> interface Loopback100
>>>> ip vrf forwarding M
>>>> ip address 10.68.146.228 255.255.255.255
>>>> !
>>>> interface FastEthernet0/0
>>>> ip vrf forwarding M
>>>> ip address 10.68.146.6 255.255.255.252
>>>> !
>>>> interface Serial1/0
>>>> no ip address
>>>> encapsulation frame-relay
>>>> serial restart-delay 0
>>>> !
>>>> interface Serial1/0.201 point-to-point
>>>> ip address 172.16.12.2 255.255.255.252
>>>> mpls ip
>>>> frame-relay interface-dlci 201
>>>> !
>>>> router ospf 400 vrf M
>>>> log-adjacency-changes
>>>> area 146 nssa
>>>> area 146 sham-link 10.68.146.228 10.68.146.227 cost 1000
>>>> network 10.68.146.4 0.0.0.3 area 146
>>>> !
>>>> router bgp 100
>>>> no synchronization
>>>> bgp log-neighbor-changes
>>>> neighbor 172.16.12.1 remote-as 100
>>>> no auto-summary
>>>> !
>>>> address-family vpnv4
>>>> neighbor 172.16.12.1 activate
>>>> neighbor 172.16.12.1 send-community extended
>>>> exit-address-family
>>>> !
>>>> address-family ipv4 vrf M
>>>> no synchronization
>>>> network 10.68.146.228 mask 255.255.255.255
>>>> exit-address-family
>>>>
>>>> ------
>>>> PE-Piz:
>>>> hostname PE-Piz
>>>> !
>>>> ip vrf M
>>>> rd 100:100
>>>> route-target export 100:100
>>>> route-target import 100:100
>>>> !
>>>> interface Loopback100
>>>> ip vrf forwarding M
>>>> ip address 10.68.146.227 255.255.255.255
>>>> !
>>>> interface FastEthernet0/0
>>>> ip vrf forwarding M
>>>> ip address 10.68.146.2 255.255.255.252
>>>> !
>>>> interface Serial1/0
>>>> no ip address
>>>> encapsulation frame-relay
>>>> serial restart-delay 0
>>>> !
>>>> interface Serial1/0.102 point-to-point
>>>> ip address 172.16.12.1 255.255.255.252
>>>> mpls ip
>>>> frame-relay interface-dlci 102
>>>> !
>>>> router ospf 400 vrf M
>>>> log-adjacency-changes
>>>> area 146 nssa
>>>> area 146 sham-link 10.68.146.227 10.68.146.228 cost 1000
>>>> network 10.68.146.0 0.0.0.3 area 146
>>>> !
>>>> router bgp 100
>>>> no synchronization
>>>> bgp log-neighbor-changes
>>>> neighbor 172.16.12.2 remote-as 100
>>>> no auto-summary
>>>> !
>>>> address-family vpnv4
>>>> neighbor 172.16.12.2 activate
>>>> neighbor 172.16.12.2 send-community extended
>>>> exit-address-family
>>>> !
>>>> address-family ipv4 vrf M
>>>> no synchronization
>>>> network 10.68.146.227 mask 255.255.255.255
>>>> 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
>>>>>>
>>>>>>
>>>>>> 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 <tron_at_huapi.ba.ar> LW7 EQI Argentina
>>>>
>> --
>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>>

-- 
Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net