But you should at least be learning the loopbacks from each side as a type-1 LSA. How are these routes showing on the PEs "show route protocol ospf table sham-link-test" ? I think I missed that output or sorry if it was already mentioned.
Message: 4 Date: Thu, 06 Dec 2007 15:04:03 +0000 From: Daniel Lete <[EMAIL PROTECTED]> Subject: Re: [j-nsp] OSPF Sham link question To: David Ball <[EMAIL PROTECTED]> Cc: juniper-nsp@puck.nether.net Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hello David, Your comment below: > (NB: is it normal that the routes PE2 is learning from the m10 are 'Extern' ?) may not be related at all with sham links or even with rfc2547/rfc4364. If you are injecting prefixes into OSPF (redistribute in Cisco or export in Juniper) in your CE, then those prefixes will appear as LSA Type-5 (external if you want). Daniel David Ball wrote: > Should have mentioned earlier (in case it's relevant), the reason > for sham-link requirement is that there 'will' be a slow backup link > between the cisco and the m10, but it'll be direct, so the cisco and > m10 will think that's the better link (due to intra-area). So, was > hoping to use sham-link across T640s to bring things closer to 'par' > and have those routes appear as intra-area and ultimately prefer the > sham-link. > I was, but am no longer, explicitly exporting routes from BGP into > OSPF on the PEs. As requested, more configs and show cmd output > included. I appreciate the feedback so far by the way....thanks > again. > > m10's loopback is 172.16.0.3 > cisco's loopback is 172.16.0.4 > > Pertinent configs from PE1 (T640 facing Cisco): > lo0 { > unit 800 { > description "sham-link testing"; > family inet { > filter { > input secure-router-shamlink-test; > } > address 172.16.0.2/32; > } > } > } > > ge-7/0/0 { <---- int facing Cisco > unit 0 { > family inet { > address 172.16.2.1/30; > } > } > } > > sham-link-test { > instance-type vrf; > interface ge-7/0/0.0; > interface lo0.800; > vrf-target target:25983:800; > vrf-table-label; > protocols { > ospf { > sham-link local 172.16.0.2; > area 0.0.0.0 { > sham-link-remote 172.16.0.1 metric 1; > interface ge-7/0/0.0 { > metric 1; > } > } > } > } > } > > > Pertinent configs from PE2 (T640 facing M10): > > lo0 { > unit 800 { > description "sham-link test"; > family inet { > filter { > input secure-router-shamlink-test; > } > address 172.16.0.1/32; > } > } > } > > ge-7/2/1 { <--------facing m10 > unit 0 { > family inet { > address 172.16.1.1/30; > } > } > } > > sham-link-test { > instance-type vrf; > interface ge-7/2/1.0; > interface lo0.800; > vrf-target target:25983:800; > vrf-table-label; > protocols { > ospf { > sham-link local 172.16.0.1; > area 0.0.0.0 { > sham-link-remote 172.16.0.2 metric 1; > interface ge-7/2/1.0 { > metric 1; > } > } > } > } > } > > OSPF neighbors as seen from PE1: >> show ospf neighbor instance sham-link-test > Address Interface State ID Pri Dead > 172.16.2.2 ge-7/0/0.0 Full 172.16.0.4 1 36 > > OSPF neighbors as seen from PE2: >> show ospf neighbor instance sham-link-test > Address Interface State ID Pri Dead > 172.16.1.2 ge-7/2/1.0 Full 172.16.0.3 128 31 > > Proof that PE1 is learning PE2's loopback via BGP: >> show route table sham-link-test > > sham-link-test.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) > + = Active Route, - = Last Active, * = Both > > 172.16.0.1/32 *[BGP/170] 12:43:03, localpref 100, from 1.7.1.43 > AS path: I > > to 1.7.2.18 via ge-0/2/0.0, label-switched-path > NCP-LSP-00819-005-043 > to 1.7.2.1 via ge-0/0/0.0, label-switched-path > NCP-LSP-00819-005-043 > 172.16.0.2/32 *[Direct/0] 20:29:55 > > via lo0.800 > > Proof that PE2 is learning PE1's loopback via BGP: >> show route table sham-link-test > > sham-link-test.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) > + = Active Route, - = Last Active, * = Both > > 172.16.0.1/32 *[Direct/0] 21:04:41 > > via lo0.800 > 172.16.0.2/32 *[BGP/170] 18:50:17, localpref 100, from 1.7.1.5 > AS path: I > > to 1.7.2.17 via ge-0/2/0.0, label-switched-path > NCP-LSP-00829-043-005 > to 1.7.2.5 via ge-0/0/0.0, label-switched-path > NCP-LSP-00829-043-005 > > OSPF database according to PE1 (Cisco isn't sending much/anything...my > current goal is for the Cisco to learn what the m10 sends, then I'll > move on): >> show ospf database instance sham-link-test > > OSPF link state database, Area 0.0.0.0 > Type ID Adv Rtr Seq Age Opt Cksum Len > Router *172.16.0.2 172.16.0.2 0x80000037 876 0x22 0xfdff 36 > Router 172.16.0.4 172.16.0.4 0x80000029 1111 0x22 0xa757 36 > Network 172.16.2.2 172.16.0.4 0x80000022 1372 0x22 0x9a80 32 > > > OSPF database according to PE2: >> show ospf database instance sham-link-test > > OSPF link state database, Area 0.0.0.0 > Type ID Adv Rtr Seq Age Opt Cksum Len > Router *172.16.0.1 172.16.0.1 0x80000024 1912 0x22 0x1ef6 36 > Router 172.16.0.3 172.16.0.3 0x80000425 735 0x22 0xc475 48 > Network 172.16.1.2 172.16.0.3 0x8000002e 435 0x22 0x7b97 32 > OpaqArea 1.0.0.1 172.16.0.3 0x80000413 1335 0x22 0xaeea 28 > OSPF AS SCOPE link state database > Type ID Adv Rtr Seq Age Opt Cksum Len > Extern 172.16.16.0 172.16.0.3 0x80000034 1035 0x22 0xbf33 36 > Extern 192.168.101.0 172.16.0.3 0x80000036 135 0x22 0xe40a 36 > > (NB: is it normal that the routes PE2 is learning from the m10 are 'Extern' ?) > > Here is Cisco's current routing table (learning nothing via OSPF): > lab-2651#sho ip route > Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP > D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area > N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 > E1 - OSPF external type 1, E2 - OSPF external type 2 > i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 > ia - IS-IS inter area, * - candidate default, U - per-user static route > o - ODR, P - periodic downloaded static route > > Gateway of last resort is not set > > C 172.17.0.0/16 is directly connected, FastEthernet0/1 > 172.16.0.0/30 is subnetted, 1 subnets > C 172.16.2.0 is directly connected, FastEthernet0/0 > C 208.98.239.0/24 is directly connected, FastEthernet0/1 > lab-2651# > > > Here is M10's inet.0 routing table: >> show route > > inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) > Restart Complete > + = Active Route, - = Last Active, * = Both > > 0.0.0.0/0 *[Static/5] 5w4d 23:37:59 > Reject > 172.16.0.3/32 *[Direct/0] 2w0d 19:06:21 > > via lo0.0 > 172.16.1.0/30 *[Direct/0] 21:05:30 > > via ge-0/1/0.0 > 172.16.1.2/32 *[Local/0] 21:05:30 > Local via ge-0/1/0.0 > 172.16.16.0/24 *[Static/5] 21:02:54 > Discard > 192.168.8.0/24 *[Static/5] 5w4d 23:37:59 > > to 192.168.101.252 via fxp0.0 > 192.168.9.0/24 *[Static/5] 5w4d 23:37:59 > > to 192.168.101.252 via fxp0.0 > 192.168.101.0/24 *[Direct/0] 5w4d 23:37:59 > > via fxp0.0 > 192.168.101.33/32 *[Local/0] 5w4d 23:37:59 > Local via fxp0.0 > 224.0.0.5/32 *[OSPF/10] 5w4d 23:38:00, metric 1 > MultiRecv > > > > On 05/12/2007, Peter E. Fry <[EMAIL PROTECTED]> wrote: >> ----- Original Message ----- >> From: Daniel Lete <[EMAIL PROTECTED]> >> >> [...] >>> In relation to your sham-link. You need a loopback IP >>> within your VRF to act as source/destination of the sham >>> link and these loopbacks are NOT to be announced to your >>> CE. >> I was going to make that point -- that is, I would not >> expect to see: >> >>> O IA 172.16.0.3/32 [110/11] via 172.16.2.1, 04:31:29, >> FastEthernet0/0 >> >> ...(although I could be wrong -- I don't get many looks into >> CPE). Also, I'd expect the sham-link neighbor to show up on >> the PE. You can see them on Cisco PEs, for instance: >> >> CiscoPE#show ip ospf [process] neighbor >> >> Neighbor ID Pri State Dead Time Address >> Interface >> [...] >> [Remote ID IP] 0 FULL/ - - [Remote LB >> IP] OSPF_SLn >> [...] >> CiscoPE# >> >> ...so there's no confusion as to the state of the sham link. >> I don't have a Juniper L3 VPN PE or a Cisco CE handy. >> >> Peter E. Fry >> >> >> >> _______________________________________________ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Daniel Lete Murugarren HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/ -- Sergio Danelli _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp