Well, looking at it with a fresh set of eyes at 06:30 helped me discover that the firewall filter applied to the VRF loopback interfaces had not been permitting OSPF packets from the VRF loopbacks themselves...only from the ge-* IP addresses. It was dropping them silently instead of logging to 'sh firewall log'. *sigh* Thanks to all who helped out with this. Appreciated as always.
David On 07/12/2007, Doug Marschke <[EMAIL PROTECTED]> wrote: > Hello David, > > I have admittedly not looked at all your output but sham links should > show up as normal point to Point links in OSPF. A few points: > > -Routes learned over sham links must still be learned over bgp as PE > routers user only BGP routes for forwarding > -Must ensure that the sham-link end points (unique loopback unit) is > also advertised via bgp to the remote PE > > For example: > [edit routing-instances vpn-a] > [EMAIL PROTECTED] show > instance-type vrf; > interface fe-0/0/0.0; > interface lo0.1; > vrf-target { > import target:65412:100; > export target:65412:100; > } > protocols { > ospf { > sham-link local 10.1.1.1; > area 0.0.0.0 { > sham-link-remote 10.2.2.2 metric 1; > interface fe-0/0/0.0; > interface lo0.1; > } > } > } > > [edit interfaces] > [EMAIL PROTECTED] show > lo0 { > unit 1 { > family inet { > address 10.1.1.1/32; > } > } > } > > Then you should see the sham-link in your ospf commands: > > [EMAIL PROTECTED]> show ospf interface instance vpn-a > Interface State Area DR ID BDR ID > Nbrs > fe-0/0/0.0 BDR 0.0.0.0 192.168.20.1 10.1.1.1 > 1 > lo0.1 DR 0.0.0.0 10.1.1.1 0.0.0.0 > 0 > shamlink.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 > 1 > > [EMAIL PROTECTED] show ospf neighbor instance vpn-a > Address Interface State ID Pri > Dead > 10.0.21.2 fe-0/0/0.0 Full 192.168.20.1 128 > 35 > 10.2.2.2 shamlink.0 Full 10.2.2.2 0 > 31 > > [EMAIL PROTECTED]> show ospf database instance vpn-a > > OSPF link state database, area 0.0.0.0 > Type ID Adv Rtr Seq Age Opt Cksum > Len > Router *10.1.1.1 10.1.1.1 0x80000081 631 0x2 0xa0f6 > 72 > Router 10.2.2.2 10.2.2.2 0x80000084 630 0x2 0x6918 > 72 > Router 192.168.20.1 192.168.20.1 0x800000ae 632 0x2 0x9641 > 48 > Router 192.168.28.1 192.168.28.1 0x800000b2 629 0x2 0x5754 > 48 > Network 10.0.21.2 192.168.20.1 0x800000ab 632 0x2 0xed96 > 32 > Network 10.0.29.2 192.168.28.1 0x800000ae 629 0x2 0xc69f > 32 > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of David Ball > Sent: Friday, December 07, 2007 8:14 AM > To: Sergio D. > Cc: juniper-nsp@puck.nether.net; [EMAIL PROTECTED] > Subject: Re: [j-nsp] OSPF Sham link question > > Sergio, > > In your tests, what indication did you see that the sham link was > up and working as expected? Did it appear as an OSPF neighbor in 'sh > ospf neigh instance <name>' ? did something specific occur in your > log file (if you enabled one) that indicated 'sham link up!'. I > suppose one of the difficulties I'm having is that I don't know what I > should expect to see from the sham link, nor can I tell if it's up or > down. > > David > > > On 07/12/2007, Sergio D. <[EMAIL PROTECTED]> wrote: > > If this becomes an inter-area type-3 LSA, the remote PE-CE will always > > prefer the on-demand back-up link. If this is correct, then I don't > see the > > point of a sham-link. > > >From my tests this has worked as designed, if all routers are > configured > > with the same area with a sham-link between PE-PE then the LSA stays > as a > > type-1. > > > > > http://www.juniper.net/techpubs/software/junos/junos84/swconfig84-vpns/i > d-10939238.html#id-10939238 > > > > On Dec 7, 2007 3:13 AM, Daniel Lete <[EMAIL PROTECTED]> wrote: > > > > > Hello Sergio, > > > In the PE where the CE is connected to, LSA Type-1 from CE should be > seen > > > as > > > LSA Type-1 > > > > > > In the remote PE, LSA Type-1 from that same CE should be seen as LSA > > > Type-3 > > > (inter-area) > > > > > > Daniel > > > > > > Sergio D. wrote: > > > > 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/ > > > > > > > > > > > > > > -- > > > 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 > > JNCIE #170 > > _______________________________________________ > > 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 > > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp