[j-nsp] OSPF inside VRF - Cisco Juniper Interoperability
Junaid
junaid.x86 at gmail.com
Wed Aug 27 00:32:57 EDT 2008
Thank you Masood and David for your input. I'll surely try sham-links
option if this does not work. I just want to re-emphasize that when
Juniper PE2 sends the route-type, its seems that Cisco PE1 is unable
to decode it properly (0x306:0:393472):
Extended Community: RT:1:103 OSPF DOMAIN
ID:0x0105:0x010101010200 0x306:0:393472
Where as when Cisco PE2 sends the route-type, Cisco PE1 decodes the
fields just fine (OSPF RT:0.0.0.6:2:0):
Extended Community: RT:1:103 OSPF DOMAIN
ID:0x0005:0x010101010200 OSPF RT:0.0.0.6:2:0 OSPF ROUTER
ID:10.254.2.1:512
Anyone faced a similar problem/situation?
Regards,
Junaid
On Wed, Aug 27, 2008 at 9:04 AM, David Ball <davidtball at gmail.com> wrote:
> I used OSPF sham-links to rid myself of a seemingly similar LSA
> Type 5 issue in the VRF I created for a customer, as follows. My PEs
> and Ps were all T-series, while both CEs were Cisco 3750s.
>
> http://www.juniper.net/techpubs/software/junos/junos91/swconfig-vpns/configuringospf-sham-links.html#id-10983860
>
>> show configuration routing-instances blah
> instance-type vrf;
> interface lo0.27;
> interface ge-7/3/0.0;
> route-distinguisher 1.7.1.1:27;
> vrf-target target:25983:27;
> vrf-table-label;
> protocols {
> ospf {
> sham-link local 10.1.0.1;
> area 0.0.0.0 {
> authentication-type md5; ## Warning: 'authentication-type'
> is deprecated
> // These are the remote PEs that connect to various CEs
> sham-link-remote 10.5.0.1;
> sham-link-remote 10.22.0.1;
> sham-link-remote 10.34.0.1;
> sham-link-remote 10.43.0.1;
> interface ge-7/3/0.0 {
> metric 10;
> authentication {
> md5 1 key "blahhhhhh"; ## SECRET-DATA
> }
> }
> }
> }
> }
>
> HTH,
>
> David
>
> 2008/8/26 Masood Ahmad Shah <masood at nexlinx.net.pk>:
>> If Cisco to Cisco works fine than problem seems in interpreting domain id.
>> If the OSPF domain ID for the destination PE differs from the originating
>> PE, MP-BGP redistributes the route into OSPF as an OSPF type 5 external
>> route. There is another to preserve OSPF routes across the MPLS VPN "OSPF
>> route type extended community attribute", You can try this too.
>>
>> Regards,
>> Masood
>>
>> -----Original Message-----
>> From: juniper-nsp-bounces at puck.nether.net
>> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Junaid
>> Sent: Wednesday, August 27, 2008 12:44 AM
>> To: Juniper Puck
>> Subject: [j-nsp] OSPF inside VRF - Cisco Juniper Interoperability
>>
>> Hi,
>>
>> I am caught up in what seems to be a Juniper Cisco interoperability
>> issue. I am running OSPF with customer inside VRF. Topology is
>> something like the following:
>>
>> CE1 ---[Area 0]--- PE1 ---- P1 --- P2 --- PE2 ---[Area 6]--- CE2
>>
>> The two P routers are acting as route reflectors.
>>
>> CE1, CE2 and PE1 are Cisco devices while rest are Juniper M-series
>> routers. The problem I am facing is that CE1 routes received at CE2a
>> are Inter-area which is what is required (no redistribution into OSPF
>> is done on CE1 and CE2). However, CE2 routes received by CE1 are Type
>> 5 (E1). The documentation states that inorder to preserve the route
>> types, domain IDs should be same on both PE routers. I have set domain
>> ID to be 1.1.1.1:512, this was done on cisco via the command:
>> "domain-id type 0105 value 010101010200" and on juniper as: "domain-id
>> 1.1.1.1:512" in the OSPF configuration inside the VRF. Also on Juniper
>> the domain-id was added into the ospf routes when redistributing them
>> into MBGP.
>>
>> The problem seems to be with the Cisco PE1 router that can't seem to
>> interpret the route-type attribute generated by Juniper:
>>
>> PE1#sh ip bgp vpnv4 all 10.254.20.254
>> BGP routing table entry for 1:103:10.254.20.254/32, version 550
>> Paths: (1 available, best #1, table VPN_OSPF)
>> Not advertised to any peer
>> Local
>> <PE2_Loopback_IP> (metric 4) from <P1_Loopback_IP> (<P1_Loopback_IP>)
>> Origin IGP, metric 2, localpref 100, valid, internal, best
>> Extended Community: RT:1:103 OSPF DOMAIN
>> ID:0x0105:0x010101010200 0x306:0:393472
>>
>> 10.254.20.254/32 is advertised by CE2 (assigned on one of its loopback
>> interfaces). Now the domain ID is fine but it seems that Cisco is
>> unable to interpret the route-type attribute. 393472 translates to
>> 60100 where 6 is the area ID, 01 says that it is type 1 LSA and and
>> last two bytes are options are not used in this case. Upon receiving
>> this route via MBPG, PE1 injects a type 5 LSA towards CE1 (confirmed
>> on CE1 by enabling debugging) where it should inject have injected
>> type 3:
>>
>> OSPF: Ack Type 5, LSID 10.254.20.254, Adv rtr 10.254.1.1, age 5, seq
>> 0x80000001
>>
>>
>> If I replace the Juniper PE2 with a Cisco then on PE1 seems to
>> interpret the route-type attribute correctly and inject type 3 LSA
>> towards CE1 and CE1 receive the routes as inter-area:
>>
>> PE1#sh ip bgp vpnv4 all 10.254.20.254
>> BGP routing table entry for 1:103:10.254.20.254/32, version 676
>> Paths: (1 available, best #1, table VPN_OSPF)
>> Not advertised to any peer
>> Local
>> <PE2_Loopback_IP> (metric 2) from <P1_Loopback_IP> (<P1_Loopback_IP>)
>> Origin incomplete, metric 11112, localpref 100, valid, internal, best
>> Extended Community: RT:1:103 OSPF DOMAIN
>> ID:0x0005:0x010101010200 OSPF RT:0.0.0.6:2:0 OSPF ROUTER
>> ID:10.254.2.1:512
>>
>>
>> Debug output:
>>
>> OSPF: Ack Type 3, LSID 10.254.20.254, Adv rtr 10.254.1.1, age 1, seq
>> 0x80000001
>>
>> Any idea what is causing this behavior? Any solution? Will appreciate any
>> help.
>>
>> (The problem involves both Juniper and Cisco routers but I am posting
>> it here as I believe most guys here are have worked on both
>> platforms.)
>>
>>
>> Regards,
>> Junaid
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
More information about the juniper-nsp
mailing list